Next meeting: 9 October 14:00 UTC

[Daphne Preston-Kendal]

Dear all,

Alaric is still travelling and couldn’t answer the poll yet, but I’m calling the date of the next meeting:
14:00 UTC, 9 October.
Conversions: <https://www.worldtimebuddy.com/?qm=1&lid=2147714,1796236,1275004,264371,2950159,2643743,100,5128581,5391959,5856195&h=100&date=2025-10-9&sln=14-16&hf=0>
Agenda: <https://codeberg.org/scheme/r7rs/wiki/Agenda+2025-10-09.->

Apologies that there’s only a week’s notice this time.

Arthur can’t make it due to travelling to ICFP. Since it was basically a choice between whether Arthur could make it and whether Marc could make it, and I chose a time that disadvantages Marc already last time, I picked the time that works for Marc but not for Arthur this time.

Arthur, if you have any feelings on the issues on the agenda that you want to air ahead of time, please do so.


Daphne

[Marc Nieper-Wißkirchen]

I'm sorry, I forgot that I had to translate the UTC times into local
time. I will have to leave a bit early.

I would also like to discuss the three "not on topic" items prior to
those where they are mentioned.

Marc


Am Do., 2. Okt. 2025 um 12:45 Uhr schrieb Daphne Preston-Kendal
<d...@nonceword.org>:

> --
> You received this message because you are subscribed to the Google Groups "scheme-reports-wg2" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to scheme-reports-...@googlegroups.com.
> To view this discussion visit https://groups.google.com/d/msgid/scheme-reports-wg2/64491C70-9383-4157-B7BE-D22154F494A4%40nonceword.org.

[Zhu Zihao]

Thanks for the notice, Daphne.

Hope the meeting goes well.

Marc Nieper-Wißkirchen <marc....@gmail.com> 于2025年10月2日周四 05:51写道：

> To view this discussion visit https://groups.google.com/d/msgid/scheme-reports-wg2/CAEYrNrSHvq1LPuh31NKutjMhaBCZqcOt3vwyFpN3NDT3jx60fg%40mail.gmail.com.

--
Retrieve my PGP public key:
执行下列命令以获取我的 PGP 公有密钥：

gpg --recv-keys B3EBC086AB0EBC0F45E0B4D433DB374BCEE4D9DC

Zihao / 閱卜錄

[Marc Nieper-Wißkirchen]

In preparation for today's meeting, here are some comments from me:

# Agenda for Scheme WG2 meeting, 9 October 2025

- Initial arrangements for the SC election
- Pro forma: Set up mailing lists for voter registration and nominations
- Appoint independent overseer?
- dpk suggests Daniel Gruno, who runs elections for the ASF
- alternatives: someone better known in the Scheme community

Someone better known would be better, but better someone than no one.

We should briefly talk about our intended audience.

- Statement from the chair/WG on what we want from a new SC:
- Discussion about charter revision:
- Compatibility requirement
- Ratification procedure?

I think discussing and compiling a wishlist is one of the more important things.

More fundamental than "compatibility requirement" is the question of
abandonment of the label "R7RS-large" altogether and give the project
the name "R8RS". (I am very much in favour of that, both for political
and for technical reasons.) As we develop the Foundations within the
large language, we will automatically have a small subset of R8RS.

Very importantly, before installing the new charter, it must be sent
to Scheme implementers for comments and their comments/wishes must be
taken seriously and be taken up.

- A chair of the SC
- Marc Feeley’s suggestion to elect one
- MNW and dpk’s suggestion that the SC appoints its own chair

I think we should leave it to the future SC to organise itself.

Have we agreed about the number of members of the SC? 3? 5? 3-5? I
tend to the larger number because of the diversity of the Scheme
community.

- Quarterly status meetings with the chair
- Approximate timeline
- Pro forma: Approve announcing the election at the Scheme Workshop

- Quick-fire round:
- Residual issue from last time
- #186 What happens if neither unlimited tail calls nor an
`&implementation-restriction` violation upon stack overflow is
possible? Undefined, implementation-specified?

Has anyone read what I wrote about how to codify "unlimited" non-tail
calls meaningfully?

I don't think we do not have to say anything about the impossibility
of delivering an implementation restriction violation, because what
happens is already implicitly there. Not delivering a violation is
observationally the same as if a cascade of implementation
restrictions violations are raised during the delivering until
eventually the implementation-defined defined base exception handler
is called (which can simply exit the program with a message like
"stack overflow").

- #154 Clearer definition of a procedure location tag
- Is the current definition satisfactory? [Definition as part of the
description of procedures](https://codeberg.org/scheme/r7rs/src/commit/edc445915443eed1cef16d29be88cc05a8411328/fascicles/procedural-fascicle.txt#L200),
[`lambda` and by implication
`case-lambda`](https://codeberg.org/scheme/r7rs/src/commit/edc445915443eed1cef16d29be88cc05a8411328/fascicles/procedural-fascicle.txt#L742),
[`eq?`/`eqv?`/`equal?`](https://codeberg.org/scheme/r7rs/src/commit/edc445915443eed1cef16d29be88cc05a8411328/fascicles/procedural-fascicle.txt#L1991)

We already talked about it on IRC that the R[57]RS definition is
circular and that one runs into the issue of Tarski's undefinability
theorem.

- Not on topic: whether procedure equivalence should be defined at all

I am serious when I say I want to talk about this first (because #154
becomes moot, depending on the resolution of that). Procedure
equivalence has a number of problems:

* No one has yet written down a sound definition.
* If I try to maintain a map whose keys are procedures and I do not
control the creation of all keys, unexpected things can happen:
Procedures created in too different parts of the program and added to
the map independently may be merged by the compiler to one because
they happen to be observationally equivalent. (The only way to make
them unique is to make sure to include a closed over unique location
that actually changes the procedure's behaviour, but then we can get
something equivalent (also in efficiency) to properly tagged
procedures.
* While too coarse in some areas (unrelated procedures may happen to
be "eq?"), procedure equivalence is too fine in other areas (e.g.,
checking by an implementation of a data structure whether an
equivalence predicate is, say, "eqv?" won't give reliable results
because, conceptually, "eqv?" should be equivalent ot any other
observationally equivalent predicate).
* The concept of procedure location tags has already been understood
in the 90s as a wart in the Scheme programming language. R6RS
corrected it. We shouldn't reverse this correction.

- #124 Allow bodies in more places
- Replace `<<expression_1>> <<expression_2>> ...` everywhere in the
syntax (notably, `cond` and `case`, also `when`, `unless`) with
`<<body>>` ?
- excluding/including non-splicing `begin`?

What do implementers say? Changing this will mean that they will have
to change all their syntactic forms. I would like to have a clear
"yes" from major implementers on this.

- #232 `cond` and `case` with no clauses
- Not on topic: whether `cond` and `case` should signal an error
when they run out of clauses instead of returning unspecified

As discussed on Codeberg, "no clauses" is not independent from the
"not on topic". In order not to block future improvements, leave
"cond" and "case" as is (at least one clause).

- If time, final quick-fire round:
- Residual issues with the macrological fascicle:
- #142 Ban patterns more complex than a single identifier in the
right-hand side of the `set!` clause of `identifier-syntax`

More complex patterns than a single identifier are not fundamentally
problematic; there is no strong reason to ban them that gives reason
to introduce a new version of `identifier-syntax` incompatible with
R6RS.

- #149 Circular syntax
- Approve or disapprove of the resolution that `syntax->datum`
must recreate cycles?
- Not on topic: whether datum labels and circular literals are a good idea

Seriously, discussing the proposed item doesn't make sense before
coming to an agreement about the "not-on-topic".

There are a number of issues about circular literals. One can
distinguish between circular structure in source files and circular
structure in data files in general.

* No other language I know has abstract syntax graphs (with cycles);
languages have abstract syntax trees for good reasons.
* At least one of the R7RS-small editors assumed erroneously that
circular source code structure could be meaningfully confined to
literals (on the right hand side of "quote").
* Syntax objects would no longer be data and could no longer be
defined inductively. Every existing syntax transformer would be
weakened. In order to make it fool-proof when it processes possibly
circular syntax, macro writers would always have to check for cycles
in recursive macros. Moreover, checking this is far from simple to
code.
* There is no implementation experience with recreating cycles in syntax->datum.
* There is hardly any program (existing or conceivable) that actually
needs circular source code. This is a blatant case of where everyone
would have to pay for a feature that has no convincing use case.

But also allowing circular data as input to the "read" procedure has its issues:
* If, at some later point, the language removes mutable pairs,
circular list structures need to be removed as well (as, otherwise, a
main reason why mutability is dropped, would become moot).
* R6RS has a clear inductive definition of what a Scheme datum is. In
R7RS-small, this is no longer the case; datums are no longer data but
codata. Procedures that process datum values (recursively) can
suddenly diverge (by looping).
* In R6RS, code has the guarantee that when calling
"read"/"get-datum", a finite tree structure is returned. In
R7RS-small, code has to check for cycles when the file contents come
from an untrusted source.
* There is no compelling use case of making Scheme datums from
data/trees to codata/graphs.

- #216 `identifier-property` should raise an exception rather than
returning `#f` when no default is given and no property available

What kind of exception would this be? The R6RS condition system does
not really include appropriate conditions. Returning `#f` would be the
conservative approach.

- #247 Rename `identifier-property` to `property-value`

Yes! This is semantically more correct and also follows the
established naming scheme found in Chez from where identifier
properties come.

Am Do., 2. Okt. 2025 um 12:45 Uhr schrieb Daphne Preston-Kendal
<d...@nonceword.org>:
>