Reminder: Meeting tomorrow, 28 October, 20:00 UTC

[Daphne Preston-Kendal]

Since it feels like much longer between meetings than the last times (in fact it is, the last few meetings were slightly less than 14 days apart, this one is slightly more), I just want to remind everyone about the meeting tomorrow, 28 October, 20:00 UTC.

<https://www.worldtimebuddy.com/?qm=1&lid=1796236,2950159,2643743,100,5128581,5391959&h=100&date=2025-10-28&sln=20-22&hf=0>
(Remember the clocks have changed in Europe but not yet in the US.)

The agenda is mostly the same topics that had to be postponed last time: <https://codeberg.org/scheme/r7rs/wiki/Agenda+2025-10-28.->

Marc and Chaw can’t make it.

If either of you have comments in advance, please let us know here.
Also, if anyone else’s plans have changed so they can’t make it any more, likewise.

We can take note of Marc’s notes from the last time, too, since most of them concern issues which ended up delayed to this time: <https://groups.google.com/g/scheme-reports-wg2/c/oWsLwrxzWXU/m/ZSLrPl6lBAAJ>


Daphne

[Alaric Snell-Pym]

On 27/10/2025 11:39, Daphne Preston-Kendal wrote:

> If either of you have comments in advance, please let us know here.
> Also, if anyone else’s plans have changed so they can’t make it any more, likewise.

My attendance is "at risk" (my wife's poorly) so I'll take a look at the
agenda and see if I can contribute anything by email... At the 11th hour!

#154: I agree with Marc that the whole issue of procedure equality is
thorny and deserves discussion in its own right, but if that's out of
scope... My main concern would be that, to avoid user confusion, lambda
(or anything that wraps a lambda, eg a define) should have a similar
notion of identity to cons: eg, it's a data constructor. If users want
to test equality of procedures, that's probably what they'd expect. But
I'm worried about inhibiting useful optimisations in implementations;
being able to fiddle around with closures is useful to them, maybe in
ways we don't know about yet because they've not been invented yet.

#124: I feel that anywhere we allow a sequence of expressions with the
values they evaluate to discarded (except maybe the last one), they
should work the same way, to avoid user confusion. So, yeah, why not
bodies everywhere? Marc's point about implementer woes is valid, but I
still imagine it won't be TOO big a job.

#232: I think zero clauses should behave like nonzero clauses none of
which match, for the reason Zipheir states. I like Marc's point about
making an error if no cases match, but that's not what cond/case are,
and we can't make such a major change. We can have a new "complete"
cond/case/etc that signal the programmer expects them to be exhaustive,
where failure to match anything is a bug and should be signalled. I'd
gladly use it as it would help catch bugs, but turning existing
cond/case into this would just create bugs!

#93: I still like this. Implementers may say they can't make much use of
it right now, but perhaps that will change with time; perhaps their
optimisers can't make use of it because they've been built in a world
without it... But (more importantly) it's also useful to make Scheme a
more precise language for expressing the programmer's intent, giving
them a tool to not over-specify the ordering.

I'll be there if I can, nonetheless!

--
Alaric Snell-Pym (M0KTN neé M7KIT)
http://www.snell-pym.org.uk/alaric/