Am Di., 1. Sept. 2026 um 23:39 Uhr schrieb jobol <xxxxxx@nonadev.net>:
>
> 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.

It remains ambiguous for someone who expects the usual infix rules to
work without ad-hoc additions.

My main point here is that S-expressions were never made for
supporting infix notation, which includes procedure calls and
different precedences, and that, in fact, the emulation model breaks
down at some point.

> 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.

This also goes against the idea that extra parentheses should not
matter in infix syntax.

> 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.

You could think of remapping the colon.

> > 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.

Why not when it solves all problems?

In the future, we might even see string literals like `#<custom>"..."`
that could expand into something like `(<derived-from-custom> "...")`.
Here, we would want `expr` for the derived datum

> > 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.

That's probably better.

>
> > 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).

I hope this can be solved.