Re: New draft (#6) and last call for comments on SRFI 266: The expr syntax Marc Nieper-Wißkirchen (30 Aug 2026 17:42 UTC)
Re: New draft (#6) and last call for comments on SRFI 266: The expr syntax Marc Nieper-Wißkirchen (31 Aug 2026 07:01 UTC)
Re: New draft (#6) and last call for comments on SRFI 266: The expr syntax Marc Nieper-Wißkirchen (01 Sep 2026 08:28 UTC)
Re: New draft (#6) and last call for comments on SRFI 266: The expr syntax jobol (01 Sep 2026 10:05 UTC)
Re: New draft (#6) and last call for comments on SRFI 266: The expr syntax Marc Nieper-Wißkirchen (01 Sep 2026 10:09 UTC)
Re: New draft (#6) and last call for comments on SRFI 266: The expr syntax Marc Nieper-Wißkirchen (01 Sep 2026 12:47 UTC)
Re: New draft (#6) and last call for comments on SRFI 266: The expr syntax Marc Nieper-Wißkirchen (01 Sep 2026 12:14 UTC)
Re: New draft (#6) and last call for comments on SRFI 266: The expr syntax Marc Nieper-Wißkirchen (01 Sep 2026 14:42 UTC)

Re: New draft (#6) and last call for comments on SRFI 266: The expr syntax jobol 01 Sep 2026 10:05 UTC

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

> Reusing Scheme's lexical syntax to form Algol-like arithmetic
> expressions as SRFI 266 does is an ingenious hack, but it still feels
> like a hack because all possible extensions to the expression syntax
> will be limited by what Scheme's reader allows (for example, `4*5`
> won't be parsable).

very true

> As SRFI 266 does not rely on hygiene, a string instead of an
> S-expression would be more natural anyway.  So what do you think of
> the following syntax:
>
> `(expr <string>)`

I'm thinking that it is a funny idea! But I will not buy it for serious
purpose. I don't know if I should explain...

> where `string` is parsed as an Algol-like formula.  Unknowns (like
> `x`, `dx`, `deriv` in your examples) will be referred to in the same
> lexical context as `expr` (implementable with `datum->syntax`).
>
> Another advantage of the string approach is that it won't confuse
> syntax highlighters.
>
> Cheers,
>
> Marc
>
> Am Di., 1. Sept. 2026 um 08:59 Uhr schrieb jobol <xxxxxx@nonadev.net>:
>
> > Hi all,
> >
> > I'm starting a new thread in order to compact the debate.
> >
> > First of all thank you to Marc and Peter for taking time for the
> > review. I applied all the remarks of Peter, thanks for the english
> > and, alas, typos. I also replaced \ by //.
> >
> > The main remark is about using symbolic versus hygienic matching. I
> > agree with Marc that it must be fixed before finalization.
> >
> > The current proposal is not perfect but it is simple. It also has
> > one advantage: using symbolic matching avoids to thinking on the
> > context, it is univocal. It also avoids splitting predefined
> > operators in many sub-libraries (ex: (srfi 266 flonum)) that I
> > failed to imagine how it can be composed (ex: (import (srfi 266
> > flonum) (srfi 266 fixnum)).
> >
> > Mark suggested unquoting: (expr ,x + ,(* 4 12)). I understand the
> > idea but it looks awkward and probably no one wants of it if a
> > cleaner solution exists.
> >
> > In an other place he wrote:
> >
> >   The `expr` form receives a parsed syntax object. Parsing has
> >   happened at a higher level than lexical analysis. Things like
> >   individual parentheses (as in your grammar) make no sense at this
> >   level.
> >
> > It implies that part of the specification is to be rewritten. I
> > have to check. It will take time...
> >
> > I checked identifier-property and it looked promising on the paper
> > but I noticed that there is very few implementations. Peter points
> > Capy scheme and srfi 262. I have to check. It will take time...
> >
> > I was thinking I used R6RS macro facilities, but Marc tells I don't,
> > so I have to check. It will take time...
> >
> > Arthur, should we make a 7th draft including Peter's improvements?
> > should we remove the final call status? should we wait?
> >
> > To be honest, I'm also thinking about withdrawing because I'm not
> > sure to have much time in the next months for it and it may wait
> > R7RS-large finalization and more srfi-213 identifier properties)
> > implementations.
> >
> > regards
> > José
> >