On 1/21/26 02:30, jobol wrote:
> 1. the specific operators are used. ex: fx+
>
> 2. the standard operators are mapped to specialized operators. ex: +
> becomes fl+
>
> So the question is "is it valuable to specialize (option 2) expr?". I
> think so because mixing arithmetic is no the main use.
I would lean towards option 1, for two reasons:
1. It makes visually apparent what the operation is, as opposed to
using, say, `fx-expr`.
2. There are very useful situations involving mixing types. For
instance, testing an index into a vector, and then operating on an
element in the vector:
(expr i fx< len and i @ my-vector fl< 100.0)
I personally care more about the bitwise operations than the
fixnum/flonum operations, mostly because I use the bitwise operations more.
As to your statements in a previous email:
> I wanted to implement expr using the "basic" syntax-rule feature. It enforces to import the library that will be used.
Perhaps there could be two libraries specified by this SRFI, (srfi
srfi-266) and (srfi srfi-266 plus). The first library has only the stuff
that can be implemented with R7RS-small. The "plus" library would have
fixnum, flonum, and bitwise arithmetic, and would be available on R6RS,
R7RS-large impls, or systems that implement the fixnum, flonum, and
bitwise SRFIs. Users can test for its existence using `(cond-expand
((library (srfi srfi-266 plus)) ...) (else ...)`.
> 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.
I think that's a good reason. I'll retract my statement on it.
> 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.
"!" is used for boolean "not" so that might not be a good idea. I don't
have any good symbolic candidates for `|` without going to Unicode.
Perhaps the quotient operator can be changed (Python does integer
division with //) and ":" can be used for bitwise inclusive or.
-- Peter McGoron