Le Fri, 16 Jan 2026 23:27:10 -0500,
Peter McGoron <xxxxxx@mcgoron.com> a écrit :

Hi Peter,

> I like it!
>
> I think it is a good idea to have bitwise operators in the grammar.
> Perhaps they can exist in the grammar and raise errors if the
> implementation does not support bitwise arithmetic. Similar comment
> for fixnum and flonum arithmetic.

I wanted to implement expr using the "basic" syntax-rule feature. It
enforces to import the library that will be used. That is the reason
why I didn't include bitwise operations. That is the same for fixnum
and flonum but the case is a litlle bit different. For these the
semantic is implemented with standard operators, it is only
optimisation. But for bitwise operations, there is no equivalent in
base library, only in fixnum.

> I will note that `||` *is* a valid identifier, it is the empty symbol
> equivalent to (string->symbol ""). It could be used for bitwise or.

I think that it is not a good idea for the below reasons:
- || is not the "bitwise or" in C
- it is confusing to use the empty symbol for a symbol (but okay it
  works)
- my first idea was to implement 'abs' using |, a disaster

For using bitwise operator, using reference to C, & is and, ~ is not, ^
is xor, | is ior.  So I see two issues: I chose ^ as power operator. It
can be changed '**' like in some language (fortran and basic maybe).
Remains the case of inclusive or. The character ! is graphically very
near to | and immediately available on keyboard, it could be candidate.

> I think customization would be cool (like with Artyom). One way to do
> it would be to make a macro-generating macro that takes the custom
> infix operators (and possibly prefix operators, like maybe `sin` in
> `(expr sin (2 + 2))`) and outputs a new `expr` macro. Or in a future
> R7RS-large version it could be extensible with syntax-case and
> identifier properties like in SRFI-262.

I agree that adding custom operators could be useful. That one of the
good quality of scheme to allow defining symbols like H, ⛒ or ∇ and
to use it.

Allowing custom operators in expr has deep implications. It maybe
not avoid using only "basic" syntax-rule but it makes it so complicated
that an other implementation must be used.

The idea of using identifier properties seems interesting. Thank you
for the suggestion.

> If you mention SRFI-261 you should give the library a name for
> SRFI-261/97 style named imports. I recommend "expr".

yes.

> I find the grammar to be pretty straight-forward, although it might
> be better to re-write like how the R4RS did expression
> transformations (https://standards.scheme.org/official/r4rs.pdf §7.3).

Maybe the grammar will not be the final representation. If custom
operator are introduced, priority and type will be more synthetic and
useful. But thank you for the reference.

> Some changes I think would be good:
>
> * "implies" becomes "->".
> * "not" becomes "!".
> * "<>" then becomes "!=" and "not eqv" becomes "!eqv"
> * "eqv" becomes "eqv?"

I really would like to keep 'and', 'or' and 'not' because it is
directly connected to standard scheme syntax and procedure. For this
reason, I also prefer to keep 'implies'.

This has the advantage that is can not be confused with bitwise
operators.

For '<>' or '!=' I have no preference, as well as for 'eqv' or 'eqv?',
and 'not eqv' or '!eqv?'.