Le Tue, 1 Sep 2026 16:42:28 +0200,
Marc Nieper-Wißkirchen <xxxxxx@gmail.com> a écrit :

[snip]
> >
> > It will allow further operators like `|`.  It will remove the
> > ingenious but still ugly hack.  It will allow to use brackets and
> > underscores for index notation (think of arrays), etc.

It is true that | can't be used. Brackets are not needed in my opinion.

> > More importantly, it allows you to use commas in function calls.
> > The current specification of function calls is brittle and not
> > intuitive.
>
> After going through the SRFI 266 spec, this point is even more
> crucial than I thought.  Infix notation really needs commas for
> procedure arguments. Otherwise, one gets ambiguous expressions of the
> form:
>
> (expr f(a - b))
>
> Does it mean `(f (- a b))` or `(f a (- b))`?  Of course, the SRFI or
> the implementation can add some ad-hoc rule, but this will only
> whitewash the fact that S-expression syntax is ill-suited to
> express/mimick Algol-like syntax.

The specification states that it means (f (- a b)). If the
specification is ambiguous it have to be improved.

The question of how to separate arguments is important and your remark
matters. I found that using spaces was smart. And I admit that it can be
difficult to read and maintain on complex expression.

A simple solution would be, when it improves readability, to enclose
each argument in brackets as in '(expr f((a - b) (u + v)))'. But it
doesn't seem to solve that issue.

An other simple solution is to use big spaces as in
 '(expr f(a - b    u + v))' perhaps a bit better but not really good
 too.

So adding a separator is an option, a symbol that will be ignored
and removed at the end. Alas, except in strings (-_o), the comma is
trapped in scheme the semi-colon can't be used, dot is impossible, many
symbolic characters are used for expr, of the few remaining on my
keyboard § is the best candidate.

> The string approach does not have these problems and is "the right
> thing" (meaning the correct Scheme idiom) here.

Hum, perhaps but I am not enthusiast of that.

> Marc
>
> P.S.: The SRFI seemingly does not allow the syntax `f()` to call a
> zero-argument function.

Good catch! It is missing. From the spec, it could be written '((f))'
but that has implication on 'f' and is not regular.

It suggest a possible improvement: enforcing calls to have a list of
arguments, possibly empty.

> P.P.S.: Even if the implementation issues with the `expr-set-...`
> forms are resolved, the fundamental issue of global state change
> remains.  If two libraries both make use of SRFI 266 internally and
> both happen to define the same operator with different semantics for
> their internal use, one of them will cease to work.

That is a real issue (even if in many cases it will work).