
@zafar.huma has joined the channel

I’m working on a design for an easy-to-use, extensible way to have infix operators. The infix expressions are macro-rewritten into standard procedure call forms, following the rules for precedence and associativity. That part is straightforward enough, but I am stuck on a question: should there be a way to take into account procedures like +
, which normally can take arbitrarily many arguments?
For example, should the infix expression {a + b + c + d}
be rewritten as (+ (+ (+ a b) c) d)
or as (+ a b c d)
?

I prefer the latter

For the former, you will need to support left assoc and right assoc

And personally I don’t want to deal with that

So I prefer users to specify that explicitly

Another route is to support both :slightly_smiling_face:

For the former and “support both” options, they will require +
to contain compile time information about left assoc / right assoc / multi arity.

(or use an external compile-time id table)

That will also mean you can’t have a higher-order operator

I was already including left and right assoc, as well as precedence. I’m just wondering if the multi arity rule should also be included.

The way that I’m handling precedence and association is by having the user define an “operator family”, which is a nonextensible set of association and precedence rules for a fixed set of operators.

The idea is that you could go (define-operator-family arithmetic
[* #:left
/ #:left]
[+ #:left
- #:left])
then you could write infix arithmetic like {a * b + c / d}
which would be rewritten to (+ (* a b) (/ c d))

The important rule is that an infix expression can only use operators from the same family. And, since families cannot be extended, this means it’s easy to remember how to read an infix expression.

My intent is that operator families would be defined for things that have an established infix syntax, like arithmetic, boolean algebra, &c.