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 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 Marc Nieper-Wißkirchen (04 Sep 2026 19:46 UTC)
Re: New draft (#6) and last call for comments on SRFI 266: The expr syntax jobol (01 Sep 2026 22:02 UTC)

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

Le Tue, 1 Sep 2026 08:29:17 -0400,
Peter McGoron <xxxxxx@mcgoron.com> a écrit :

>  > 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)).
>
> You don't have to do this with hygienic matching: (srfi 266) could
> just export all identifiers, and then raise an error if operation fl+
> or whatever is used but not supported.

What stopped me in fact is that Chez Scheme can't test that a library
is available or not in cond-expand
(https://github.com/cisco/ChezScheme/issues/91).

>  > 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...
>
> This is relevant for hygienic-matching+extensibility. If you go for
> hygienic matching, I would just cut out the extensibility section in
> this SRFI. Then the whole thing could be implement in syntax-rules.

The first implementation was using syntax-rules. It was complex. I'm
cautious on the feasibility.

The good news is that it is perhaps not very difficult to change
current implementation in order to be hygienic. I should check. But it
will need cond-expand.

> (I'm not telling you to rewrite the whole implementation to do that!)
> Then later on, if identifier properties are more widely implemented,
> then you (or someone else) can backwards-compatibly extend the syntax
> with extensibility.

At the moment details of implementation are hidden. So it could be
warned that the implementation has a serious drawback regarding
extensibility.

I asked Marc about the below snipped propositions of rewriting.

[snip]

> I really like this proposal and I hope it is finalized.

thank you for that and for your help