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.

[Zhu Zihao]

In my view, the main objections to identifier properties are purely technical,
N=3 criterion have little to do here.

1) Identifier properties complicate the semantic of an identifier.
Traditionally, the same (wrt free-identifier?) identifiers can be
exported from different libraries, and being imported multiple-times in
the same libraries. Many SRFI implementations import the binding of
'=>', '...' from (rnrs base) or (scheme base), and re-export these
bindings. These libraries can be togetherly imported with (rnrs base) or
(scheme base), implementation will not complain about conflicts because
they are the same. free-identifier=? thus formed an intuitive criterion
on the sameness of identifiers imported from different libraries.

Introducing dentifier properties would break the intuition, if the same
identifier in same library was imported multiple-times, and each import
attempted to attach different properties on it. These identifiers will
be different (see the last Note of
<https://r7rs.org/large/fascicles/macro/1/syntax-transformation.html#identifier-properties>).

1) Current identifier properties proposal allows user to define
properties on "foreign" identifiers. At first glance, this seems to be
the original intent of properties -- SRFI-262 utilizes it to attach
pattern expander for identifiers in different libraries, thus avoids the
"ugly" ~pattern convention used in SRFI-257.

However, current proposal also allows user to define properties on
"foreign" identifier with "foreign" keys. For example

(import (rnrs) (srfi :213))

;; both cons and car are not under the fully control of current library
(define-property cons car 20)

This is somewhat similar to the issue that "orphan rules" [orphan] of
typeclass/trait in Haskell/Rust aim to address. Macrological fascicles
claim that "If two properties with the same key are imported on the same
identifier, and the values of the properties are not the same in the
sense of eqv?, it is an import error". The solution remains open to
debate (for example, introduce rules like "orphan rules")

3) <https://codeberg.org/scheme/r7rs/issues/243> showed a critical issue
that identifier properties lacks of access control.

4) Currently identifier properties are expand-time (or phase 1) value.
In Chez Scheme and SRFI-213 use, though Macrological Fascicle introduced
a dedicated procedure 'identifier-property', but it still assume that it
was invoked in the dynamic extent of a macro expansion. Using identifier
properties as docstring or other similar purposes, its semantics under
run-time (phase 0), and the its interoperability between library system
must be considered.

If a certain Scheme implementation with a significant community dare to
take the challenge described above, it would clearly boost out
confidence in the standardization of identifier properties. Currently,
only Chez Scheme and Unsyntax support such feature, I had hoped that
Guile would implement identifier properties and address the outstanding
issues mentioned above, but as things stand, Andy Wingo seems to be busy
with hoot (Guile’s WASM variant, it has its own expander which is
different from the original one of Guile).

[orphan]: https://doc.rust-lang.org/reference/items/implementations.html#r-items.impl.trait.orphan-rule
--
Retrieve my PGP public key:
执行下列命令以获取我的 PGP 公有密钥：

gpg --recv-keys B3EBC086AB0EBC0F45E0B4D433DB374BCEE4D9DC

Zihao / 閱卜錄