Le Sun, 30 Aug 2026 19:42:39 +0200,
Marc Nieper-Wißkirchen <xxxxxx@gmail.com> a écrit :

> The SRFI still lists an issue about some ambiguity.  I guess this
> should be resolved and the issue removed before the SRFI is finalised.
>
> The issue is probably related to the following remark in the document:
> "*CAUTION:
> because of this rule, a potential clash may occur when the same
> symbol is used for an operator and a variable.*"
>
> This really needs to be fixed before finalisation.  If there were the
> Ten Commandments of Scheme programming, one of them would enforce
> that, at a given position, it is uniquely determined whether an
> identifier is matched hygienically or symbolically.
>
> There are two possible ways to fix it.  Either you match all
> identifiers symbolically, or you introduce a special escape syntax.

Hi Marc,

In my mind, the match is symbolically and I tried to explain why. So I
have to improve that part.

I asked the mailing list before about that aspect and I'm still hoping
some kind of approval about it. If symbolic matching is approved and
clearly stated, the caution part could probably be removed.

> Another point that should be made is that the specification section
> does not follow the conventions of RnRS and seemingly mixes lexical
> and datum syntax.

I am sorry about that but to be honest, I don't really understand. Does
it mean that the table of predefined operators must be in a specific
section?

> Finally, a statement about the implementation requirements is
> missing.  The SRFI remarks that SRFI 105 is not implementable in
> standard Scheme. However, SRFI 266 likely is not implementable in a
> satisfactory way.  It is certainly not implementable in R7RS.  And
> for R6RS, the current implementation of the defining/redefining
> operators has phasing issues, and even if this is corrected somehow,
> the operator table may be instantiated more than once in phase 1.

I agree. It is not implementable in R7RS-small. It can be implemented
in R6RS and probably in future R7RS-large.

What you call phasing issues is probably the 'set!' of the list of
operators. I'm not proud of that but didn't find an elegant solution.

It can be solved by documenting 'define-expr-syntax' of the
implementation. That meta-syntax allows to define a syntax like 'expr'
that use specific list of operator definitions. It is used to define
'expr':

   (define-expr-syntax expr stdops)

I did not include it and then used 'set!' because I preferred to hide
implementation details for two reasons: being short and letting
implementer decide on their internals.

Thank you for reviewing.
José

>
> Marc
>
>
> Am So., 30. Aug. 2026 um 18:04 Uhr schrieb Arthur A. Gleckler <
> xxxxxx@speechcode.com>:
>
> > I've just published draft #6 of SRFI 266
> > <https://srfi.schemers.org/srfi-266/>. It was submitted by José
> > Bollo, author of the SRFI.
> >
> > Here are José's comments on the draft:
> >
> > minor rewritings, minor fixes in implementation
> >
> > Here is the commit summary:
> >
> >
> >    - Add syntax exemple for ternaries
> >    - Fix after re-reading
> >    - Reorder sections
> >    - copy edits
> >    - Add table of contents.
> >    - Publish sixth draft.
> >
> > Here's the diff:
> >
> >
> > https://github.com/scheme-requests-for-implementation/srfi-266/compare/draft-5..draft-6
> >
> > José has asked me to announce *last call* for this SRFI. He
> > believes that it is ready for finalization, but would like to give
> > reviewers one last chance to submit corrections and feedback before
> > we finalize it.
> >
> > In particular, I appeal to anyone reading this to try the sample
> > implementation, run the tests, and send feedback about your results.
> >
> > If you're interested in this SRFI, please give your feedback via
> > the SRFI 266 mailing list before *2026-09-14*. After that, assuming
> > that no major revisions are required, we will declare it final. It
> > is important that we get your feedback before 2026-09-14. *If that
> > deadline is too soon for you, but you would like to contribute,
> > please let me know so that I can extend the last-call period.*
> >
> > Regards,
> >
> > SRFI Editor
> >