Fwd: extending expr with identifier properties

[John Cowan]

---------- Forwarded message ---------
From: jobol <jo...@nonadev.net>
Date: Wed, May 20, 2026, 2:53 AM
Subject: extending expr with identifier properties
To: <srfi...@srfi.schemers.org>

I am thinking now to allow extending 'expr' syntax using identifier
properties. The current implementation of 'expr' syntax [1] allows
extension through table defining the operation. But using identifier
properties look promising and much more flexible.

However, while looking at SRFI-213, it seems that 'define-property'
isn't widely implemented: Unsyntax and Chez Scheme. So I wonder if it
is wasting time to work on that? Though?

====== end forward=====

I was going to reply that define-property will be in the large language. But now I wonder if that's justified, given that it is not portably implementable and does not meet N=3. Have we abandoned this criterion now in favor of pure ad hoc decisions?

[Peter McGoron]

On 5/20/26 04:39, John Cowan wrote:
> I was going to reply that define-property will be in the large language.
> But now I wonder if that's justified, given that it is not portably
> implementable and does not meet N=3. Have we abandoned this criterion
> now in favor of pure ad hoc decisions?

It seems to have been balloted:
https://codeberg.org/scheme/r7rs/src/branch/main/ballot-results/jcowan/edition/2022-02-yellow-edition-report.txt#L6

So it's there until we ballot it's removal. There was some previous
discussion about alternatives
<https://codeberg.org/scheme/r7rs/issues/178#issuecomment-2557329>. One
benefit of identifier properties is that one (should be able to) write
the syntax-case set of syntactic forms on an procedural base. A
replacement would have to be able to accomplish the same thing.

________________________

As an aside that doesn't apply to identifier properties, I would relax
the N=3 rule-of-thumb for features that have strong support in multiple
other languages, but not as much support in Scheme implementations (raw
strings, hex floats, spacers in numbers, etc.)

-- Peter McGoron

[John Cowan]

Fair enough. I agree that the presence of a feature in other languages should be given some (but not full) weight.

[Wolfgang Corcoran-Mathe]

On 2026-05-20 04:39 -0400, John Cowan wrote:
> But now I wonder if that's justified, given that it is not portably
> implementable and does not meet N=3. Have we abandoned this criterion now
> in favor of pure ad hoc decisions?

I was also wondering about this. We've had IRC votes on some big
changes recently, and the N=3 rule / guideline was not brought up.
I don't remember how this rule was adopted in the first place, but
we should take some kind of formal position on whether we're still
following it.

--
Wolfgang Corcoran-Mathe <w...@sigwinch.xyz>

[Peter McGoron]

The major decisions are:

* Bitvector literal syntax: N=2 (MIT-Scheme and Gauche for #*)
* Raw strings: N=2+ (CHICKEN and Gambit for heredoc-style strings, Guile
(external library) for SRFI 267). Popular in other languages.
* Underscores in numbers: N=1: Gauche. Popular in other languages.

The other formal decisions, as far as I can tell, are things that are
portably implementable (like extended list-copy, bytevector=?, etc.)
AFAIK, the N=3 doesn't apply to such things.

https://codeberg.org/scheme/r7rs/wiki/Process-document#the-n-3-rule

-- Peter McGoron

[Wolfgang Corcoran-Mathe]

On 2026-05-20 16:58 -0400, 'Peter McGoron' via scheme-reports-wg2 wrote:
> The major decisions are:
>
> * Bitvector literal syntax: N=2 (MIT-Scheme and Gauche for #*)
> * Raw strings: N=2+ (CHICKEN and Gambit for heredoc-style strings,
> Guile (external library) for SRFI 267). Popular in other languages.
> * Underscores in numbers: N=1: Gauche. Popular in other languages.

Thanks for looking into this. For transparency I would not count SRFI
267 in Guile, since 267 was finalized less than a month ago and is
probably not yet in use by anyone outside of WG2. (Not to slight your
work!)

I'll note that, by the rationale given in dpk's wiki page, several other
features (identifier properties, ephemerons, & guardians) were dropped
for not meeting N=3. By the same token, all the features listed above
would be out. What do we want to do about this?

> The other formal decisions, as far as I can tell, are things that
> are portably implementable (like extended list-copy, bytevector=?,
> etc.) AFAIK, the N=3 doesn't apply to such things.

I don't see that distinction in the current text, except with regard
to the Batteries. Every "idea" in the Foundations is supposed to be
in the "core distribution" of at least three implementations. Maybe
that's a bit Procrustean, when we're talking about something as
unobtrusive (and idea-free?) as 'bytevector=?'.

If we decide to waive the rule for portable changes, I'd still like to
get feedback from implementers (e.g. via the "house of implementers"
ballot responses) on the bigger issues.

--
Wolfgang Corcoran-Mathe <w...@sigwinch.xyz>

[John Cowan]

On Wed, May 20, 2026, 5:48 PM Wolfgang Corcoran-Mathe <w...@sigwinch.xyz> wrote:

> The other formal decisions, as far as I can tell, are things that
> are portably implementable (like extended list-copy, bytevector=?,
> etc.) AFAIK, the N=3 doesn't apply to such things.

I think that was never clear.

Every "idea" in the Foundations is supposed to be
in the "core distribution" of at least three implementations.  Maybe
that's a bit Procrustean, when we're talking about something as
unobtrusive (and idea-free?) as 'bytevector=?'.

There is no definition of "core distribution" that is valid across all Schemes.

In any case, N=3 was imposed by the former SC: the WG as such never adopted it.