Le Tue, 1 Sep 2026 12:08:51 +0200, Marc Nieper-Wißkirchen <xxxxxx@gmail.com> a écrit : > Am Di., 1. Sept. 2026 um 12:05 Uhr schrieb jobol <xxxxxx@nonadev.net>: > > > 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... > > > > I think you need to explain because I don't see what's funny about it. From an implementer view, it implies writing a parser of strings that mimic scheme parser. That is not impossible but I really prefer avoid it. Readers will be confused because it introduce a new kind of strings, a meaningful parsed string, and the basic syntax highlighter shows it as strings. Except that it allows to write '1+1' instead of '1 + 1' (but many coding style -i.e. Linux- expect spaces around operators), it brings nothing to the current current implementation because it will still resolve by symbol identity not binding. > > 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é > > > > > > > >
