Minutes, next meeting time+date+agenda

[Daphne Preston-Kendal]

Dear Schemers,

The minutes of the first meeting on Tuesday last week are online, with the log: <https://codeberg.org/scheme/r7rs/wiki/Minutes+2025-09-16.->

Following the resolution made there, I sent the message asking for new Steering Committee elections this morning.

The next meeting will be on Saturday, 27 September at 14:00 UTC. Conversions: <https://www.worldtimebuddy.com/?qm=1&lid=2147714,1796236,1275004,264371,2950159,2643743,100,5128581,5391959,5856195&h=100&date=2025-9-27&sln=14-16&hf=0>

The agenda can be found here: <https://codeberg.org/scheme/r7rs/wiki/Agenda+2025-09-27.->
The order might change a little, as Marc can only be there for the second half.
Marc, can you let me know if there are any issues you want moved later in the agenda, and if you have any comments on the issues you probably can’t be there for? Thanks!


Daphne

[Marc Nieper-Wißkirchen]

Dear Daphne,

Thanks for all your voluntary work on this.

> The agenda can be found here: <https://codeberg.org/scheme/r7rs/wiki/Agenda+2025-09-27.->
> The order might change a little, as Marc can only be there for the second half.
> Marc, can you let me know if there are any issues you want moved later in the agenda, and if you have any comments on the issues you probably can’t be there for? Thanks!

Here are my comments on the issues. During the time I won't be there,
I would like to delegate my vote to you, Daphne, so that you can vote
on my behalf.

- Quick-fire round: issues which can hopefully be accepted or rejected
without long discussion
- #31 Unicode alias for lambda
- Current draft includes `λ` and `case-λ` as aliases, but
these can be very easily removed if there is no consensus
- other Unicode aliases not on-topic at this meeting

I am (strongly) opposed to this for a number of reasons:
1. It is better if a programming language only supports one way of
writing things instead of two ways that are otherwise equivalent.
Programs are (or should be) more often read than written, and
uniformity helps a lot here, also across program bases.
2. This would needlessly create a precedent for non-ASCII printable
characters in the language specification.
3. If one really wants to be able to type "λ" and read "λ", the better
way would be to program their editor accordingly. Besides, everyone
can always write their own library exporting Greek letters.
4. The letter "λ" itself is a historical accident (and thus neither
worse nor better than any other term like "lambda"), see p. 182 of [1]
5. This could lead to a proliferation of identifiers if applied
consistently; we have already seen identifiers like "lambda*" and
"lambda/tag".
6. Introducing "λ" into the standard will alienate people, but won't
convince anyone of Scheme. It is therefore much cheaper to drop this
suggestion.
7. Code wrapped in a lambda behaves very differently from code not
wrapped; it should be hidden behind too-short identifiers.

I don't mind if this is discussed when I am not there, as I put my points here.

- #93 `independently` from [SRFI
236](https://srfi.schemers.org/srfi-236/srfi-236.html)
- Current draft includes this, can be easily removed if there
is no consensus
- If no immediate consensus for inclusion, we may return to
this issue when MNW arrives

If you have questions about this, please feel free to postpone this
point until I come online. It is cheap to implement (an implementation
can just use "begin"), but it can also be used well by optimizers and
fuzzers. It is somewhat to "begin" what "let" is to "let*". It helps
to convey the meaning of an algorithm better. I vote for including it.

In this context, I also want to propose making the Scheme language
more deterministic (Racket has gone in this direction) by default. In
times where reproducible builds have been understood to be important,
reducing randomness seems like a good idea. One should be explicit
about randomness in a program. For example, "map" could be specified
as "map-in-order" of SRFI 1, and a new procedure "map-independently"
(or with a similar name) could be added. Eventually, procedure
application could mean evaluating the operands from left to right.

- #203 `letrec-values` and `letrec*-values`
- Current draft includes these, can be easily removed if there
is no consensus

I don't mind having them or leaving them out; the number of binding
constructs is more complete with them, though. You can discuss this
without me.

- #205 Returning multiple values to a procedure call subform
- dpk doesn’t like what the current draft says, but is editorially a
bit hemmed in
- Vote on Stygian Blue was for status quo, so this issue is partly editorial

I am strongly in favour of leaving the way open for future standards
(if not this one) to make it a violation if, in a single-value
context, more than one value is received. If we can't agree on that,
we should at least make sure that such a decision would not be blocked
in the future.

From a purity point of view, the clear answer is that silently
dropping produced values would be analogous to dropping extra
procedure arguments (because in the case of values, the procedure in
question is the current continuation), and we don't do that. It may be
that some idioms can be slightly more brief when extra values are
dropped, but for such a minor feature, everyone would have to pay the
price of harder debuggability (which is especially important for a
non-statically typed programming language). Moreover, as code should
be easily understandable, it is better to be explicit than implicit.
If one really wants the extra values of some expression to be dropped,
it is easy to provide macros "(values-first <expr>)" and "(values-ref
<expr> 1)".

- #186 Practically unbounded non-tail recursion
- [Currently in draft as a
‘should’](https://codeberg.org/scheme/r7rs/src/commit/edc445915443eed1cef16d29be88cc05a8411328/fascicles/procedural-fascicle.txt#L539),
can be removed, can be changed to ‘must’

I don't think that the language is precise enough; this should be left
out for the moment. A specification should be written and discussed
outside the draft, and only be integrated when it is ready. Specifying
the PTC guarantee of Scheme needed a paper by Will Clinger, for
example.

We can talk about it briefly during the meeting, but maybe we can use
the time better.

- #104 Allowing mixing definitions and expressions in any order
- Current draft includes [an attempt by dpk to reunify the
semantics of SRFIs 245 and
251](https://codeberg.org/scheme/r7rs/src/commit/edc445915443eed1cef16d29be88cc05a8411328/fascicles/procedural-fascicle.txt#L362)
in a way that preserves full optimizability of `letrec`
- No forward reference of variables to the next definition group
are allowed, but forward reference of syntax is always allowed
- Practical effect: no mutually recursive procedure
definitions in different variable groups – this restriction also
applies in Racket’s implementation of mixing orders

Let us use the time of the meeting to explain and discuss this, but
let us postpone any votes on this. This will need some thinking by
everyone. If we can't find a unanimous solution, we should be
conservative here.

We should also note that there are other solutions than changing the
semantics of internal defines to achieve what people want, e.g.,
lexical or syntactic solutions.

I would like to be there when this is discussed.

- #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)

I vote for the removal of this concept and following R6RS here,
especially when we have procedures with actual tags (as true Scheme
objects) in the new standard. One never gets a satisfying equivalence
relation for procedures for two reasons: the compiler is free to merge
two identical lambda objects into one, and it is undecidable whether
two procedures behave equivalently.

In any case, the definition of "eqv?" is circular, so its meaning is
unclear. The definition is circular because it refers to the
behavioural equivalence of procedures, but for the latter, the meaning
of "eqv?" must be known because "eqv?" can be used in procedures.

This touches the core of the Scheme programming language, so precision
is more important here than elsewhere. At least we should know how we
could formalise this in mathematical terms (or in a formal
specification) if we had the time to.

I think we should also reserve enough time at the end of the meeting
so that everyone can raise points they want to be discussed/resolved
in a future meeting.

Cheers,

Marc

--

[1] https://repository.ubn.ru.nl/bitstream/handle/2066/17274/13362.pdf
>

[Arthur A. Gleckler]

On Tue, Sep 23, 2025 at 9:43 AM Marc Nieper-Wißkirchen <marc....@gmail.com> wrote:

I hope to attend the whole meeting, but I'm going to respond to Marc's comments now rather than trying to think through everything on the fly during the meeting.

  

    - #31 Unicode alias for lambda
        - Current draft includes `λ` and `case-λ` as aliases, but these can be very easily removed if there is no consensus
        - other Unicode aliases not on-topic at this meeting

I am (strongly) opposed to this for a number of reasons:

I also oppose this.  Marc gives good reasons.  I'm happy to read other people's code that uses λ, but I'd rather that its use be explicitly declared in imports rather than implicit because it is part of the standard.

  

    - #93 `independently` from [SRFI 236](https://srfi.schemers.org/srfi-236/srfi-236.html) 

I am weakly in favor of including independently.

  

    -  #203 `letrec-values` and `letrec*-values`
        - Current draft includes these, can be easily removed if there is no consensus

I am in favor of including these forms.

  

- #205 Returning multiple values to a procedure call subform
  - dpk doesn’t like what the current draft says, but is editorially a bit hemmed in
  - Vote on Stygian Blue was for status quo, so this issue is partly editorial

I am strongly in favour of leaving the way open for future standards (if not this one) to make it a violation if, in a single-value context, more than one value is received. If we can't agree on that, we should at least make sure that such a decision would not be blocked in the future.

From a purity point of view, the clear answer is that silently dropping produced values would be analogous to dropping extra procedure arguments (because in the case of values, the procedure in question is the current continuation), and we don't do that.

Unless someone can show that it's impossible to make efficient, and perhaps even then, I'd like to see us require checking that the number of return values matches the context.  If we don't do that, I agree with Marc that we should leave the way open to requiring it in the future, although postponing the decision makes it less likely that we will, in fact, do that in the future.

 

- #186 Practically unbounded non-tail recursion
  - [Currently in draft as a ‘should’](https://codeberg.org/scheme/r7rs/src/commit/edc445915443eed1cef16d29be88cc05a8411328/fascicles/procedural-fascicle.txt#L539), can be removed, can be changed to ‘must’

I don't think that the language is precise enough; this should be left out for the moment. A specification should be written and discussed outside the draft, and only be integrated when it is ready. Specifying the PTC guarantee of Scheme needed a paper by Will Clinger, for example.

I'd like to see us incorporate some version of this proposal, at least as a SHOULD, in the final R7RS Large.

  

- #104 Allowing mixing definitions and expressions in any order

 

Let us use the time of the meeting to explain and discuss this, but let us postpone any votes on this. This will need some thinking by everyone. If we can't find a unanimous solution, we should be conservative here.

That sounds reasonable.

  

- #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)

I vote for the removal of this concept and following R6RS here, especially when we have procedures with actual tags (as true Scheme objects) in the new standard. One never gets a satisfying equivalence relation for procedures for two reasons: the compiler is free to merge two identical lambda objects into one, and it is undecidable whether two procedures behave equivalently.

I'm not sure what I believe here.  The argument that we have procedures with tags now (SRFI 229) is persuasive.  On the other hand, I remember that this decision was the one part of R7RS Small that made Jerry Sussman unhappy when we discussed it.  He said that he uses procedures as keys all the time.  I should ask him about SRFI 229 now.

[John Cowan]

I won't be there, but here's my feedback:

\#31 Flush this for Marc's reasons.

\#93 Agree with Marc except for his last sentence (which is dictum) about eventually mandating LTR order. RTL order goes back to the Rabbit compiler and should not be made illegal.

\#203 Keep.

\#205 Status quo, given that the number of values returned is in general undecidable. I would like to bring up an idea I had many years ago: the ability to statically declare the number of values returned. It is an error if this is wrong. The syntax I favored was an exact integer literal after the syntax keyword: e.g. (lambda 2 (x) (values x x)) or equivalently (define 2 (foo x) (values x x)).

\#186 Good in spirit, but the wording is a problem. This is analogous to making the length of an exact integer bounded only by memory, which means that it can gobble up all of memory, leaving none for lists or vectors.

\#104 I still think thus is a misfeature. I believe it will rarely be needed, and nested block-containing expressions will serve the same purpose.

\#154 I agree with Sussman. If you want to map procedures to values using an alist, procedure tags will require an extra overhead: you need to attach a unique object K to each such procedure using a tag and then map each K to a value using the alist, requiring two searches, one through the tags of the procedure and one through the alist. The reason for using an alist is so that n associations can be pushed on the alist and then all popped in O(1) time by keeping a pointer to the original alist.

[Arthur A. Gleckler]

On Wed, Sep 24, 2025 at 6:26 PM John Cowan <co...@ccil.org> wrote:

 

\#154 I agree with Sussman. If you want to map procedures to values using an alist, procedure tags will require an extra overhead: you need to attach a unique object K to each such procedure using a tag and then map each K to a value using the alist, requiring two searches, one through the tags of the procedure and one through the alist. The reason for using an alist is so that n associations can be pushed on the alist and then all popped in O(1) time by keeping a pointer to the original alist.

Alex pointed out privately that R7RS Small does, in fact, require that eq? return true when comparing a procedure against itself.  I clearly remember talking with Jerry about this, and a big debate about it afterwards, but I must have misremembered the decision.  Sorry about that.  I should look over the email archives to see what I'm missing.

[Dr. Arne Babenhauserheide]

John Cowan <co...@ccil.org> writes:

> \#205 Status quo, given that the number of values returned is in general undecidable. I would like to bring up an idea I had many years ago:
> the ability to statically declare the number of values returned. It is an error if this is wrong. The syntax I favored was an exact integer literal
> after the syntax keyword: e.g. (lambda 2 (x) (values x x)) or equivalently (define 2 (foo x) (values x x)).

This would complicate the common pattern in Guile of (lambda _ ...),
meaning to ignore the input. The compiler will be able to figure it out,
but it would be harder to read for humans.

I wrote a syntax-rule that allows restricting arguments and return
values which enter/leave the body,¹ so I do not think that this
restriction needs to be a feature of the language.

The syntax currently is²

(define-typed (proc args ...) ((ret-valid? ...) arg-valid? ...) body ...)

For example:

(define-typed (proc x y) ((float? float?) float? float?)
(values x y))

Best wishes,
Arne

¹ more details on https://www.draketo.de/software/guile-define-typed

² I got feedback that using the common types -> ret syntax would be
nicer (and after sleeping on that for a month, I agree, specifically
because of multiple return values, and plan to do that), but the main
point is that it’s already possible with existing core features to add
a verified declaration of the number of return values, so it need not
be an added language feature.

--
Unpolitisch sein
heißt politisch sein,
ohne es zu merken.
draketo.de

[Daphne Preston-Kendal]

It was changed at the last minute to restore (a version of) the R5RS semantics.

See the examples (let ((p (lambda (x) x))) (eqv? p p)) and the same with eq? in the respective entries for eqv? and eq? in the final report: <https://standards.scheme.org/official/r7rs.pdf#page=31>
vs. the draft submitted for the ratification vote: <https://small.r7rs.org/attachment/r7rs-draft-9.pdf#page=31>

(Disclosure: I was one of two who made their vote in favour of ratification conditional on this change, though I now regret this.)


Daphne

[Daphne Preston-Kendal]

On 25 Sep 2025, at 03:26, John Cowan <co...@ccil.org> wrote:

> \#205 Status quo, given that the number of values returned is in general undecidable. I would like to bring up an idea I had many years ago:
> the ability to statically declare the number of values returned. It is an error if this is wrong.

In some contexts (admittedly not public APIs) I have used procedures that return differing numbers of values as a cheap-and-cheerful option type. (0 values for nowt, 1 or more values for summat.)

Perhaps it could work with a ‘coarity mask’ like the arity masks of Chez and SRFI 191. (In fact, the arity of expressions is one of the few cases I have favoured introducing static ‘type’ checking to Scheme.) But this is rather radical.

On 25 Sep 2025, at 07:25, Dr. Arne Babenhauserheide <arne...@web.de> wrote:

> This would complicate the common pattern in Guile of (lambda _ ...),
> meaning to ignore the input

This ‘pattern’ is a very bad idea because it rebinds the auxiliary syntax keyword _.

((lambda _ _) 1 2 3) => (1 2 3) in Guile 3.0.10, as I’d expect, but if you use syntax-rules or syntax-case or (ice-9 match) or some other pattern matching syntax inside that lambda, you might be in for a bad time …



Daphne

[Dr. Arne Babenhauserheide]

Daphne Preston-Kendal <d...@nonceword.org> writes:
> Perhaps it could work with a ‘coarity mask’ like the arity masks of Chez and SRFI 191. (In fact, the arity of expressions is one of the few cases I have favoured introducing static ‘type’ checking to Scheme.) But this is rather radical.

Guile gives a warning during byte-compilation when the arity of a
procedure does not match how it is called. That has saved me from bugs
several times.

Providing a linter for this would already catch most errors, though.

> On 25 Sep 2025, at 07:25, Dr. Arne Babenhauserheide <arne...@web.de> wrote:
>
>> This would complicate the common pattern in Guile of (lambda _ ...),
>> meaning to ignore the input
>
> This ‘pattern’ is a very bad idea because it rebinds the auxiliary syntax keyword _.
>
> ((lambda _ _) 1 2 3) => (1 2 3) in Guile 3.0.10, as I’d expect, but if you use syntax-rules or syntax-case or (ice-9 match) or some other pattern matching syntax inside that lambda, you might be in for a bad time …

Thank you for the warning! Testing it shows me that the pattern already
breaks error reporting that’s usually given in Guile when using _:
((λ args _) 1 2 3)
=>
While compiling expression:
Syntax error:
unknown file:3:6: _: bad use of '_' syntactic keyword in subform _ of _

I’ll be more careful with _ and rather use another letter.

Best wishes,
Arne

[Daphne Preston-Kendal]

On 23 Sep 2025, at 18:43, Marc Nieper-Wißkirchen <marc....@gmail.com> wrote:

> - Quick-fire round: issues which can hopefully be accepted or rejected
> without long discussion
> - #31 Unicode alias for lambda
> - Current draft includes `λ` and `case-λ` as aliases, but
> these can be very easily removed if there is no consensus
> - other Unicode aliases not on-topic at this meeting

I see I am probably in the losing side on this one, but (perhaps because of that) here are my objections to these arguments:

> I am (strongly) opposed to this for a number of reasons:
> 1. It is better if a programming language only supports one way of
> writing things instead of two ways that are otherwise equivalent.
> Programs are (or should be) more often read than written, and
> uniformity helps a lot here, also across program bases.

This argument would have stopped us standardizing the alias call/cc for call-with-current-continuation. Admittedly, that was, I think, in somewhat wider use before R6RS made it official than λ is now (but I don’t know, because I wasn’t yet Schemeing in 2005), but the arguments against the alias were very similar. Racket, Guile, and Stklos do give us a precedent for λ, though.

Are there really any Schemers out there who don’t know what λ means? It’s used in papers all the time, and in SRFIs like 43/133. Those authors don’t stop to explain what it means.

> 2. This would needlessly create a precedent for non-ASCII printable
> characters in the language specification.

I strongly oppose sticking with the technology of the 1960s for the sake of sticking with the technology of the 1960s. Programmers have been dragged, kicking and screaming, to accepting that writing code which only works on ASCII text is no longer acceptable. (Please go and look at some of the ignorant horsecrap that was said about Unicode during the R6RS ratification if you want a reminder of just how painful this transition was.) I would like to drag them the rest of the way to not restricting themselves to expressing themselves exclusively in a one-dimensional stream of 7-bit characters. (Yes, this is a somewhat more radical programme even than introducing a few non-ASCII characters here and there, and one whose full execution will have to take place in some future language after Scheme …)

> 3. If one really wants to be able to type "λ" and read "λ", the better
> way would be to program their editor accordingly. Besides, everyone
> can always write their own library exporting Greek letters.

Neither entirely satisfactory. Editor hacks are always fragile. While I want to support alternative preludes, I don’t necessarily want to encourage them, since they eventually amount to little more than extra dependencies.

> 4. The letter "λ" itself is a historical accident (and thus neither
> worse nor better than any other term like "lambda"), see p. 182 of [1]

One could object to any notation on similar grounds. All mathematical notation consists of arbitrary signifiants.

Indeed, you say it is neither worse nor better, so I don’t understand the point of this argument: I could understand if you argued that it were worse.

> 5. This could lead to a proliferation of identifiers if applied
> consistently; we have already seen identifiers like "lambda*" and
> "lambda/tag".

Racket gets along perfectly well with providing aliases for each of its variants of lambda.

> 6. Introducing "λ" into the standard will alienate people, but won't
> convince anyone of Scheme. It is therefore much cheaper to drop this
> suggestion.

Do you have any evidence it will alienate people?

Racket is the most popular implementation of (a) Scheme(-like language) at the moment and the λ identifiers are very popular in actual use. According to the GitHub result counts around a quarter of uses of ‘lambda’ like forms in Racket are the λ forms.
34.9k files for /λ/: <https://github.com/search?q=language%3ARacket%20%2F%CE%BB%2F&type=code>
98.3k files for /lambda/: <https://github.com/search?q=language%3ARacket+%2Flambda%2F&type=code>
Of the objections I’ve seen to Racket, this has not been one of them.

Haskell has achieved huge success with a strong Algol-like tradition of printing code in a different and richer character set for publication than for machine representation.

> 7. Code wrapped in a lambda behaves very differently from code not
> wrapped; it should be hidden behind too-short identifiers.

The Lisps which have come after Scheme have pretty uniformly chosen shorter identifiers than ‘lambda’ for their procedure creation forms, usually ‘fn’. I don’t think anyone is in danger of missing the presence of a lambda because the identifier is too short.

Indeed, this argument is inconsistent with established practice, as in language in general, the most commonly used forms tend to be abbreviated regardless of the extent of the difference they make in semantics. (This has been the argument for ‘fn’, which is also shorter than ‘function’ which is what one would naturally choose if the argument were merely that ‘lambda’ is too obscure.)

> - #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)
>
> I vote for the removal of this concept and following R6RS here

Once again we are running up against the question of what compatibility guarantee we want :-) Sigh. I don’t have a good answer here. I think my suggestion is that: in our publications, which will (in, I hope, not more than a few weeks) include the first public draft of the Procedural Fascicle, we continue to assume we can’t break R7RS small compatibility; we keep a list of things we may want to change from R7RS small, so that if we have a new SC, and if we also have a charter revision allowing us to revisit those decisions, we can revisit those questions later.

In other words, we keep the discussion for now at ‘assuming we want to keep the R7RS small semantics, does the current draft sufficiently improve the clarity of their definition?’

However, again, for disclosure, while I think SRFIs 229/259 offer an acceptable substitute for procedure identity in some cases, I am still reluctant to delete it entirely for non-tagged procedures. Not all of the use cases noted by Alex Shinn can be accommodated by this approach: <https://groups.google.com/g/scheme-reports-wg1/c/9fAFeaT1yAU/m/wdfwBF9PFlwJ>

> In any case, the definition of "eqv?" is circular,

A few months ago I found someone (I think Will Clinger) acknowledging back in the 1980s or 1990s that this was the case. Unfortunately I can’t find any more where it was. But they didn’t think it was important then, and I don’t think it matters now. In any standard written in prose, the canons of interpretation apply. In particular, everyone knows what eqv? means.

I know you have argued before that the normative part of the specification should be in formal semantics rather than just English prose. To this I say: first, again, that nobody qualified to create normative semantics for every individual form has stepped forward; second, that since I spent some part of this year trying to understand The Definition of Standard ML which is in the form you suggest, that such a specification would be much harder to understand and apply in practice; third, that such a specification would be more alienating to most working programmers than any Unicode character in an identifier ;-).


Daphne

[Marc Nieper-Wißkirchen]

Am Do., 25. Sept. 2025 um 09:58 Uhr schrieb Daphne Preston-Kendal
<d...@nonceword.org>:

>
> On 23 Sep 2025, at 18:43, Marc Nieper-Wißkirchen <marc....@gmail.com> wrote:
>
> > - Quick-fire round: issues which can hopefully be accepted or rejected
> > without long discussion
> > - #31 Unicode alias for lambda
> > - Current draft includes `λ` and `case-λ` as aliases, but
> > these can be very easily removed if there is no consensus
> > - other Unicode aliases not on-topic at this meeting
>
> I see I am probably in the losing side on this one, but (perhaps because of that) here are my objections to these arguments:
>
> > I am (strongly) opposed to this for a number of reasons:
> > 1. It is better if a programming language only supports one way of
> > writing things instead of two ways that are otherwise equivalent.
> > Programs are (or should be) more often read than written, and
> > uniformity helps a lot here, also across program bases.
>
> This argument would have stopped us standardizing the alias call/cc for call-with-current-continuation. Admittedly, that was, I think, in somewhat wider use before R6RS made it official than λ is now (but I don’t know, because I wasn’t yet Schemeing in 2005), but the arguments against the alias were very similar. Racket, Guile, and Stklos do give us a precedent for λ, though.

Indeed, adding call/cc as an alias to call-with-current-continuation
can be seen as having been an error. But if something is seen as an
error, it makes no sense to repeat the mistake.

That said, the case of call/cc is a bit different:

(1) call/cc is does not introduce fancy Unicode characters (this is a
point for some of use).
(2) If one wants to deprecate a particular name in favour of a new
one, one has to add an alias in the next standard so that the
deprecated name can be removed in a standard farther in the future. I
don't know whether deprecation of call-with-current-continuation was
ever on the table, but we certainly do not want to deprecate "lambda".

> Are there really any Schemers out there who don’t know what λ means? It’s used in papers all the time, and in SRFIs like 43/133. Those authors don’t stop to explain what it means.
>
> > 2. This would needlessly create a precedent for non-ASCII printable
> > characters in the language specification.
>
> I strongly oppose sticking with the technology of the 1960s for the sake of sticking with the technology of the 1960s. Programmers have been dragged, kicking and screaming, to accepting that writing code which only works on ASCII text is no longer acceptable. (Please go and look at some of the ignorant horsecrap that was said about Unicode during the R6RS ratification if you want a reminder of just how painful this transition was.) I would like to drag them the rest of the way to not restricting themselves to expressing themselves exclusively in a one-dimensional stream of 7-bit characters. (Yes, this is a somewhat more radical programme even than introducing a few non-ASCII characters here and there, and one whose full execution will have to take place in some future language after Scheme …)

I never said that we should stick to 1960 technology, so I don't
understand your rant here. I just said that the identifiers exported
by the standard library should only be built from the printable ASCII
subset of Unicode. In fact, the set of identifiers we have chosen from
is even more limited (for good reason), namely we do not use uppercase
letters. Libraries outside the standard can export whatever names they
want and programs can use whatever names they want.

The computers that we target do have good Unicode support. However,
entering non-ASCII characters and displaying them nicely with the
local font installed is not granted.

> > 3. If one really wants to be able to type "λ" and read "λ", the better
> > way would be to program their editor accordingly. Besides, everyone
> > can always write their own library exporting Greek letters.
>
> Neither entirely satisfactory. Editor hacks are always fragile. While I want to support alternative preludes, I don’t necessarily want to encourage them, since they eventually amount to little more than extra dependencies.

By adding it to the standard, you would make everyone pay for this
"little more" overhead. This is worse.

> > 4. The letter "λ" itself is a historical accident (and thus neither
> > worse nor better than any other term like "lambda"), see p. 182 of [1]
>
> One could object to any notation on similar grounds. All mathematical notation consists of arbitrary signifiants.
>
> Indeed, you say it is neither worse nor better, so I don’t understand the point of this argument: I could understand if you argued that it were worse.

My point is that it does not make sense to add an alias if the
original name is not worse.

> > 5. This could lead to a proliferation of identifiers if applied
> > consistently; we have already seen identifiers like "lambda*" and
> > "lambda/tag".
>
> Racket gets along perfectly well with providing aliases for each of its variants of lambda.

Even more aliases only strengthen the point of those who are against
providing aliases to make code look more uniform.

> > 6. Introducing "λ" into the standard will alienate people, but won't
> > convince anyone of Scheme. It is therefore much cheaper to drop this
> > suggestion.
>
> Do you have any evidence it will alienate people?

It would, at least, alienate me.

> Racket is the most popular implementation of (a) Scheme(-like language) at the moment and the λ identifiers are very popular in actual use. According to the GitHub result counts around a quarter of uses of ‘lambda’ like forms in Racket are the λ forms.
> 34.9k files for /λ/: <https://github.com/search?q=language%3ARacket%20%2F%CE%BB%2F&type=code>
> 98.3k files for /lambda/: <https://github.com/search?q=language%3ARacket+%2Flambda%2F&type=code>
> Of the objections I’ve seen to Racket, this has not been one of them.
>
> Haskell has achieved huge success with a strong Algol-like tradition of printing code in a different and richer character set for publication than for machine representation.

What do you mean by "huge success"?

Personally, I find Haskell code hard to read.

Scheme uses much more text and it is somewhat part of the
characteristic of the existing Scheme. I like it and others like it
too. There are people who don't like and would like to have more of
Haskell-/Agda-experience. But a single language cannot cater everyone.
We should stick to Scheme's tradition.

> > 7. Code wrapped in a lambda behaves very differently from code not
> > wrapped; it should be hidden behind too-short identifiers.
>
> The Lisps which have come after Scheme have pretty uniformly chosen shorter identifiers than ‘lambda’ for their procedure creation forms, usually ‘fn’. I don’t think anyone is in danger of missing the presence of a lambda because the identifier is too short.
>
> Indeed, this argument is inconsistent with established practice, as in language in general, the most commonly used forms tend to be abbreviated regardless of the extent of the difference they make in semantics. (This has been the argument for ‘fn’, which is also shorter than ‘function’ which is what one would naturally choose if the argument were merely that ‘lambda’ is too obscure.)

Maybe I don't understand why you actually want the Greek letter.

In any case, we should leave single-letter identifiers for the user
(so there is no danger of shadowing pre-defined ones). Say, if I want
to implement some technical/physical formula where Greek and some
other fancy letters appear, I don't want to make a difference between
the letter Lambda and the rest.

> > - #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)
> >
> > I vote for the removal of this concept and following R6RS here
>
> Once again we are running up against the question of what compatibility guarantee we want :-) Sigh. I don’t have a good answer here. I think my suggestion is that: in our publications, which will (in, I hope, not more than a few weeks) include the first public draft of the Procedural Fascicle, we continue to assume we can’t break R7RS small compatibility; we keep a list of things we may want to change from R7RS small, so that if we have a new SC, and if we also have a charter revision allowing us to revisit those decisions, we can revisit those questions later.
>
> In other words, we keep the discussion for now at ‘assuming we want to keep the R7RS small semantics, does the current draft sufficiently improve the clarity of their definition?’

Then let us postpone the discussion.

> However, again, for disclosure, while I think SRFIs 229/259 offer an acceptable substitute for procedure identity in some cases, I am still reluctant to delete it entirely for non-tagged procedures. Not all of the use cases noted by Alex Shinn can be accommodated by this approach: <https://groups.google.com/g/scheme-reports-wg1/c/9fAFeaT1yAU/m/wdfwBF9PFlwJ>
>
> > In any case, the definition of "eqv?" is circular,
>
>
> A few months ago I found someone (I think Will Clinger) acknowledging back in the 1980s or 1990s that this was the case. Unfortunately I can’t find any more where it was. But they didn’t think it was important then, and I don’t think it matters now. In any standard written in prose, the canons of interpretation apply. In particular, everyone knows what eqv? means.

No, I don't know what it means what's written.

> I know you have argued before that the normative part of the specification should be in formal semantics rather than just English prose. To this I say: first, again, that nobody qualified to create normative semantics for every individual form has stepped forward; second, that since I spent some part of this year trying to understand The Definition of Standard ML which is in the form you suggest, that such a specification would be much harder to understand and apply in practice; third, that such a specification would be more alienating to most working programmers than any Unicode character in an identifier ;-).

The point I raised in this thread is a different one. Whatever we
write in prose, it must be clear how it could be expressed in
formal/mathematically correct terms in principle. It doesn't mean that
such a formal specification has to be in the report, but if we can't
explain the meaning without hand-waving*, we have a serious problem.

Marc

--

(*) in the sense of when used in mathematics

>
>
> Daphne
>

[Alaric Snell-Pym]

On 25/09/2025 02:26, John Cowan wrote:

> \#205 Status quo, given that the number of values returned is in general
> undecidable. I would like to bring up an idea I had many years ago: the
> ability to statically declare the number of values returned. It is an error
> if this is wrong. The syntax I favored was an exact integer literal after
> the syntax keyword: e.g. (lambda 2 (x) (values x x)) or equivalently
> (define 2 (foo x) (values x x)).

I am enthusiastic about statically declaring more things about
procedures, but I worry about how this syntax would interact with other
extensions to declare return types, and maybe other properties of the
procedure - in other words, I think we should have a good think about
general extensibility of lambda (and syntactic sugars thereof) before
leaping into this... However, that discussion is probably way out of
scope here, alas!

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

[Linas Vepstas]

On Thu, Sep 25, 2025 at 2:58 AM Daphne Preston-Kendal <d...@nonceword.org> wrote:
>
>  I would like to drag them the rest of the way to not restricting themselves to expressing themselves exclusively in a one-dimensional stream of 7-bit characters. (Yes, this is a somewhat more radical programme even than introducing a few non-ASCII characters here and there, and one whose full execution will have to take place in some future language after Scheme …)

This appears to work in guile:

(define (☺ n) (+ n 1))
(format #t "The answer? Obviously ~A\n"  (☺ 41))

> Racket is the most popular implementation of (a) Scheme(-like language) at the moment and the λ identifiers are very popular in actual use. According to the GitHub result counts around a quarter of uses of ‘lambda’ like forms in Racket are the λ forms.
> 34.9k files for /λ/: <https://github.com/search?q=language%3ARacket%20%2F%CE%BB%2F&type=code>
> 98.3k files for /lambda/: <https://github.com/search?q=language%3ARacket+%2Flambda%2F&type=code>

> Of the objections I’ve seen to Racket, this has not been one of them.

Fascinating!

I would like to suggest that the issue is not UTF-8, not really, but that my keyboard does not have emojis on it, and neither does Marc's. When I write scheme code, I use a plain-old text editor, and it does NOT offer any way of composing utf-8 chars. There's no ctrl-blah, alt-escape-foo sequence I can type at the keyboard to compose emojis. That's the root of the problem.  That's the source of the resistance: its not utf8 per se, its the text editors.

To put it differently: "lambda" is six keystrokes at the keyboard, and I can do that quickly.  Everything else is longer: move hand from keyboard to mouse, move mouse, click on something, select something from menu, return hand to keyboard.  Its a hassle.  Maybe I'm more kinesthetic than others (I swim, row, dance, gymnastics) and hand-movement hassles like these really irk me.  And probably Marc too.  Were it not for that, I can see how it would be fun to write scheme code using emojis.  Visually eye-catching, if nothing else. The colors alone are meaningful; I could use red for catching  exceptions, and orange for debug prints ....

-- linas

[Vincent Manis (he/him)]

I would point out that λ is being proposed as a synonym, not a
replacement. For me, I press Compose+*+l, and I get λ. I can do this on
a Mac, on Windows, and on Linux. If people don't want a Compose key (I
haven't yet found a good solution on ChromeOS), they can still type
`lambda'. -- vincent

[Linas Vepstas]

On Thu, Sep 25, 2025 at 12:25 AM 'Dr. Arne Babenhauserheide' via scheme-reports-wg2 <scheme-re...@googlegroups.com> wrote:

I wrote a syntax-rule that allows restricting arguments and return
values which enter/leave the body,¹ so I do not think that this
restriction needs to be a feature of the language.

The syntax currently is²

(define-typed (proc args ...) ((ret-valid? ...) arg-valid? ...) body ...)

For example:

(define-typed (proc x y) ((float? float?) float? float?)
  (values x y))

I like this.

 

¹ more details on https://www.draketo.de/software/guile-define-typed

² I got feedback that using the common types -> ret syntax would be
  nicer (and after sleeping on that for a month, I agree, specifically
  because of multiple return values, and plan to do that), but the main
  point is that it’s already possible with existing core features to add
  a verified declaration of the number of return values, so it need not
  be an added language feature.

Multi-value returns give me the willies.  But the defined-type example above seems to be clear enough that I could get to liking them.  Yes, it is almost always better to "do it with existing core features" than to add a new language feature. Thus, making defined-type as accessible as possible, as popular and easy and common-pace as possible, seems like the right thing to do.

--linas

 

--

Patrick: Are they laughing at us?

Sponge Bob: No, Patrick, they are laughing next to us.

 

[Linas Vepstas]

By "Compose" I think you mean the apple keyboard curly-queue thing at the bottom left. My Mom has one of those.  But apple products are very uncommon; you won't find them anywhere in "the real world".   Standard keyboards have ctrl, fn, windows, alt on the lower left, alt menu ctrl on lower right, and maybe it is possible to map one of those to "compose". And, in this day and age, maybe it should be done, because having to select a language input method from a mouse menu sucks. But until it becomes common-place accepted practice, we're stuck with keyboards that don't have compose keys. This is, in part, a manufacturing problem: the keyboard makers in China have to stop putting that damned useless windows key on everything. It's a linux distro problem: Debian and Ubuntu don't map the windows key to compose.

This is off-topic-ish for the present discussion about scheme, but points at the actual practical barriers that remain that prevent more wide-spread adoption of utf-8 : manufacturing ... distros ...

-- Linas

[Dr. Arne Babenhauserheide]

Linas Vepstas <linasv...@gmail.com> writes:

> On Thu, Sep 25, 2025 at 12:25 AM 'Dr. Arne Babenhauserheide' via scheme-reports-wg2 <scheme-re...@googlegroups.com> wrote:

> (define-typed (proc x y) ((float? float?) float? float?)
> (values x y))
>
> I like this.

I’m glad to hear that!

It’s already the most complex version ☺

The implementation is geared to also help the guile JIT compiler create
faster code by restricting runtime types, and tested to actually work
for guile, so it may not be optimal for other implementations. When not
checking the return type, it even sped up a small function in a hot code
path by factor 3.

An alternative that was proposed would be used as

(define-typed (proc x y) (float? float? -> float? float?)
(values x y))

That would have the advantage of making the simple version without
return type check simpler (currently that needs #f as return type) and
to make multiple value returns easier to read. It would also be nicer
for lambda-typed: same number of type-checks as arguments.

On the other hand, this version only uses structure for identification
to avoid using up -> as syntax element. I don’t like adding special
characters to Scheme.

I didn’t yet get to implementing the alternate version.

> ¹ more details on https://www.draketo.de/software/guile-define-typed

> Multi-value returns give me the willies. But the defined-type example above seems to be clear enough that I could get to liking them. Yes, it is
> almost always better to "do it with existing core features" than to add a new language feature. Thus, making defined-type as accessible as
> possible, as popular and easy and common-pace as possible, seems like the right thing to do.

If people want to spread it, I’d also provide it under a laxer license.
Currently it’s LGPL like Guile.

If you want to provide it in other schemes (or write a SRFI?), just say
so.

Best wishes,
Arne

[Vincent Manis (he/him)]

On 2025-09-25 13:11, Linas Vepstas wrote:

On Thu, Sep 25, 2025 at 2:47 PM Vincent Manis (he/him) <vman...@gmail.com> wrote:

I would point out that λ is being proposed as a synonym, not a
replacement. For me, I press Compose+*+l, and I get λ. I can do this on
a Mac, on Windows, and on Linux. If people don't want a Compose key (I
haven't yet found a good solution on ChromeOS), they can still type
`lambda'. -- vincent

By "Compose" I think you mean the apple keyboard curly-queue thing at the bottom left. My Mom has one of those.  But apple products are very uncommon; you won't find them anywhere in "the real world".   Standard keyboards have ctrl, fn, windows, alt on the lower left, alt menu ctrl on lower right, and maybe it is possible to map one of those to "compose". And, in this day and age, maybe it should be done, because having to select a language input method from a mouse menu sucks. But until it becomes common-place accepted practice, we're stuck with keyboards that don't have compose keys. This is, in part, a manufacturing problem: the keyboard makers in China have to stop putting that damned useless windows key on everything. It's a linux distro problem: Debian and Ubuntu don't map the windows key to compose.

No, you remap a key of your choice. Right Alt is an excellent choice; or Right Option on a Mac keyboard. I have been using Caps Lock for years for this purpose, though I'm switching to Right Alt. As I said, this is practical on Mac, Windows, and Linux. And you need an OTF or TTF editor font, again supported on all those systems.  

This is off-topic-ish for the present discussion about scheme, but points at the actual practical barriers that remain that prevent more wide-spread adoption of utf-8 : manufacturing ... distros ... 

I haven't seen any of these obstacles. -- vincent

-- Linas

[Linas Vepstas]

On Thu, Sep 25, 2025 at 3:15 PM Dr. Arne Babenhauserheide <arne...@web.de> wrote:

An alternative that was proposed would be used as

  (define-typed (proc x y) (float? float? -> float? float?)
    (values x y))

On the other hand, this version only uses structure for identification
to avoid using up -> as syntax element. I don’t like adding special
characters to Scheme.

Using the arrow is absolutely the right thing to do.  In computing, it's in ML and CaML and I believe also in Haskell, for this purpose. In math, its standard notation, even at freshman undergraduate levels and maybe even highschool, I dunno. I don't know the historical origins, I suspect in part because its standard notation in category theory, and when type theory emerged to clarify the idea of "what it is for something to be a type", arrows are what you use to map types. This is entirely implicit in e.g. wikipedia articles, where no one stops to explain "arrow means a map from type to type". It's just "obvious" and "everyone knows that" notation and no one ever complains about it.

-- Linas

[Linas Vepstas]

Let me start with an apology: the topic below is surely off-topic for this mailing list; however, all the right people are reading it, and I don't know quite where else to express these ideas.

On Thu, Sep 25, 2025 at 3:15 PM Dr. Arne Babenhauserheide <arne...@web.de> wrote:
>
>

> >  ¹ more details on https://www.draketo.de/software/guile-define-typed

 

I triggered on the words "scheme to C compiler" in the above.

Over the last twenty years, I have accidentally invented a language that accidentally looks more and more lisp/scheme-like. I am interested in finding a route to "go all the way".

This is all accidental, because it started with the idea of doing inference, deduction and logic. But we (many were involved) wanted fuzzy logic, probabilistic logic, so ProLog was not a choice. Anyway, no one involved had the technical chops to hack ProLog and add fuzzy probabilities to it.

So we created an ad-hoc system that represented logical statements as trees: abstract syntax trees: is-a, has-a, made-out-of, has-parts become the abstract syntax trees:  (made-out-of (bowl) (clay))

Graphs are made from two types: vertices and edges, and making the type explicit is convenient. So instead, we write:

(Evaluation (Predicate "made out of") (List (Concept "bowl") (Concept "clay")))

which evaluates to not to crisp true/false, but a float pt probability and a confidence, or, these days, a long vector of floats (neural net embedding)

These rules -- trees -- graphs - appear in no particular order, and so are stored as graphs in a graph database. To accomplish this, "Evaluation", "Predicate" "Concept" and "List" are actually C++ classes that "do the right thing" So the above s-expression, when it is evaluated, turns into a bunch of calls to methods in C++ objects.

Over time, a rich series of new types were added: Plus, Minus, Times, Divide, Sine ... but also Variable and Lambda, there are almost 200 of these beasts. I want to give one longer example, before I pop the question. This example is used to compute a certain probability, returning a vector of floats (so, kind-of-like a multi-value return in scheme, and related to Arne's defined-type commentary)

 (Lambda
      (VariableList (Variable "$X") (Variable "$Y"))
 
      ; Compute TV = (1-sA*sB, cA*cB)
      (FloatColumn
         (Minus
            (Number 1)
            (Times
               (strength-of (Variable "$X"))
               (strength-of (Variable "$Y"))))
         (Times
            (confidence-of (Variable "$X"))
            (confidence-of (Variable "$Y")))))

The above is an abstract syntax tree. It is stored as a tree,  a graph, in a (network-distributed) database (Uses RocksDB  for disk store, but also a stale/slow obsolete Postgres backend works.)

As you can see, it is rather verbose, and writing it feels like coding in assembly language. But that's OK, it is not meant for humans, it's meant for automated theorem provers, which will read these trees and apply re-write and logical reasoning rules to them. Well, easy to say, harder to do; the path is littered with failed attempts. One current attempt is to write some JIT compilery-thing for converting the above into OpenCL or CUDA code that will run on GPU's. It's a mess, it's confusing.

Well, presumably it's now obvious why I thought I should send this email to this mailing list. I keep having this vague daydream of allowing this language to "actually be" some dialect of scheme/lisp, except that it's always a bridge too far.  Everything in Atomese is declarative: nothing "runs" until you explicitly call it to make it run. Everything is a graph, parsed and stored in a database. (Of course, you can store it in files, but that misses the point). The declarations are order-independent: they just float in the cloud out there. So turning this into a dialect of scheme is, in the end, kind of absurd and far-fetched and pointless and useless .... except like a nagging pebble in the shoe, a splinter in the knuckle, it just won't go away ....

And so I'm no longer sure of what I'm asking from this mailing list. I'm hoping for a reply like "well, you could do xyz and get pqr, and that would solve problem abc" but .. well, that would be nice.

--linas

[Wolfgang Corcoran-Mathe]

Clearly "λ vs. lambda" is an unproductive bike shed issue. I agree with Daphne's points, but I suggest leaving things as they are in order to cut off more (fairly silly) debate.

Marc's points are pedantic nonsense (I write this with affection). His comment about avoiding syntactically different but semantically equivalent notation is especially rich--I'm familiar with Marc's code and it's clear he loves his R6RS square brackets.

Let's table this and focus on more productive topics.

Wolfgang

[Marc Nieper-Wißkirchen]

Am Fr., 26. Sept. 2025 um 19:11 Uhr schrieb Wolfgang Corcoran-Mathe
<w...@sigwinch.xyz>:

>
> Clearly "λ vs. lambda" is an unproductive bike shed issue. I agree with Daphne's points, but I suggest leaving things as they are in order to cut off more (fairly silly) debate.
>
> Marc's points are pedantic nonsense (I write this with affection).

What do you mean by this?

> His comment about avoiding syntactically different but semantically equivalent notation is especially rich--I'm familiar with Marc's code and it's clear he loves his R6RS square brackets.

That's quite a different thing. In R6RS, there is an established
scheme for when to write () and when to write []. In other words,
there is a canonical way of writing R6RS code, and I am just following
this way. For the same reason that correct orthography helps in
reading texts, always having the same way in which code is written
helps.

What would be the equivalent canonical way of choosing between
"lambda" and the Greek letter? What would be the semantic difference
between choosing one or the other?

Marc

[Daphne Preston-Kendal]

On 26 Sep 2025, at 21:12, Marc Nieper-Wißkirchen <marc....@gmail.com> wrote:

>> His comment about avoiding syntactically different but semantically equivalent notation is especially rich--I'm familiar with Marc's code and it's clear he loves his R6RS square brackets.
>
> That's quite a different thing. In R6RS, there is an established
> scheme for when to write () and when to write []. In other words,
> there is a canonical way of writing R6RS code, and I am just following
> this way.

Actually, I think Wolfgang is correct.

Some R6RS authors consistently use [] as recommended in the non-normative appendix. Some never use []. Some have their own convention: Riastradh claims in style.txt to have seen three different variants of square bracket use for ‘let’. https://mumble.net/~campbell/scheme/style.txt#:~:text=**%20Round%20and%20Square%20Brackets

With a λ alias, some would always use it, and some would never use it. This is already the case in Racket. Unlike square brackets, there would be no need to establish a convention for what contexts to use it in, because people would probably either consistently use it or consistently not use it, according to their personal preference.

Moreover, square brackets are actually worse than λ because they occupy the space of lexical syntax and not only library exports. I have already extensively bewailed that R6RS robbed us of the opportunity to use square brackets for something more useful – like persistent vector literals, to name only one possibility.

As such, I think your point about wanting to use λ as a variable name for wavelengths or whatever is the only actually good point you’ve made :-) I have indeed used Greek letters directly when translating some formulas into code. Shadowing of identifiers works fine in Scheme, though …


Daphne

[Wolfgang Corcoran-Mathe]

On 2025-09-26 21:12 +0200, Marc Nieper-Wißkirchen wrote:
> Am Fr., 26. Sept. 2025 um 19:11 Uhr schrieb Wolfgang Corcoran-Mathe
> <w...@sigwinch.xyz>:
> >
> > Clearly "λ vs. lambda" is an unproductive bike shed issue. I agree
> > with Daphne's points, but I suggest leaving things as they are in
> > order to cut off more (fairly silly) debate.
> >
> > Marc's points are pedantic nonsense (I write this with affection).
>
> What do you mean by this?

I think debating the meaningfulness of λ versus some other notation,
the difficulty of typing λ, the propriety of Unicode in the standard
parts of a programming language, etc., is rather silly, at least
compared to the more difficult problems we have to face.
classic example of debating bike-shed colors.

As for the last sentence, I meant that while your points _are_
pedantic nonsense, they are an example of the classic Marc
Nieper-Wißkirchen pedantic nonsense that I know and love. :-)

> > His comment about avoiding syntactically different but
> > semantically equivalent notation is especially rich--I'm
> > familiar with Marc's code and it's clear he loves his R6RS
> > square brackets.
>
> That's quite a different thing. In R6RS, there is an established
> scheme for when to write () and when to write []. In other words,
> there is a canonical way of writing R6RS code, and I am just following
> this way. For the same reason that correct orthography helps in
> reading texts, always having the same way in which code is written
> helps.

Sorry, I shouldn't have implied that there was anything improper going
on between you and those brackets. Perhaps it's just convention.
But you can certainly argue that λ has become a convention for some
Scheme (and Racket) programmers.

Again, I think it's not an issue that's worth wasting time on. I am
perfectly happy with 'lambda'.

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

[Marc Nieper-Wißkirchen]

Am Sa., 27. Sept. 2025 um 00:37 Uhr schrieb Wolfgang Corcoran-Mathe

<w...@sigwinch.xyz>:
>
> On 2025-09-26 21:12 +0200, Marc Nieper-Wißkirchen wrote:
> > Am Fr., 26. Sept. 2025 um 19:11 Uhr schrieb Wolfgang Corcoran-Mathe
> > <w...@sigwinch.xyz>:
> > >
> > > Clearly "λ vs. lambda" is an unproductive bike shed issue. I agree
> > > with Daphne's points, but I suggest leaving things as they are in
> > > order to cut off more (fairly silly) debate.
> > >
> > > Marc's points are pedantic nonsense (I write this with affection).
> >
> > What do you mean by this?
>
> I think debating the meaningfulness of λ versus some other notation,
> the difficulty of typing λ, the propriety of Unicode in the standard
> parts of a programming language, etc., is rather silly, at least
> compared to the more difficult problems we have to face.
> classic example of debating bike-shed colors.

It is on the agenda. If it were up to me, I wouldn't even have
considered it because it just adds noise, both to the discussion and
to the language. And it solves no problem.

Actually, I think it will be great if we can agree (or, at least,
decide) on the following much more important principle first:

"Do we want to leave out of the standard all those things that can
easily be delivered by third-party libraries and instead focus on
those things that produce a coherent language compatible with its
predecessors (to the extent that it is reasonable) and enabling users
to write powerful abstractions and libraries that are on par with the
standard libraries?"

> As for the last sentence, I meant that while your points _are_
> pedantic nonsense, they are an example of the classic Marc
> Nieper-Wißkirchen pedantic nonsense that I know and love. :-)

If you mean "nonsense" in "pedantic nonsense" in the way "nonsense" is
meant in "abstract nonsense", I could see this as a point in favour of
the nonsense, couldn't I?

> > > His comment about avoiding syntactically different but
> > > semantically equivalent notation is especially rich--I'm
> > > familiar with Marc's code and it's clear he loves his R6RS
> > > square brackets.
> >
> > That's quite a different thing. In R6RS, there is an established
> > scheme for when to write () and when to write []. In other words,
> > there is a canonical way of writing R6RS code, and I am just following
> > this way. For the same reason that correct orthography helps in
> > reading texts, always having the same way in which code is written
> > helps.

[...]

Marc

[Marc Nieper-Wißkirchen]

Am Fr., 26. Sept. 2025 um 23:49 Uhr schrieb Daphne Preston-Kendal
<d...@nonceword.org>:
>

> On 26 Sep 2025, at 21:12, Marc Nieper-Wißkirchen <marc....@gmail.com> wrote:
>
> >> His comment about avoiding syntactically different but semantically equivalent notation is especially rich--I'm familiar with Marc's code and it's clear he loves his R6RS square brackets.
> >
> > That's quite a different thing. In R6RS, there is an established
> > scheme for when to write () and when to write []. In other words,
> > there is a canonical way of writing R6RS code, and I am just following
> > this way.
>
> Actually, I think Wolfgang is correct.
>
> Some R6RS authors consistently use [] as recommended in the non-normative appendix. Some never use []. Some have their own convention: Riastradh claims in style.txt to have seen three different variants of square bracket use for ‘let’. https://mumble.net/~campbell/scheme/style.txt#:~:text=**%20Round%20and%20Square%20Brackets
>
> With a λ alias, some would always use it, and some would never use it. This is already the case in Racket. Unlike square brackets, there would be no need to establish a convention for what contexts to use it in, because people would probably either consistently use it or consistently not use it, according to their personal preference.
>
> Moreover, square brackets are actually worse than λ because they occupy the space of lexical syntax and not only library exports. I have already extensively bewailed that R6RS robbed us of the opportunity to use square brackets for something more useful – like persistent vector literals, to name only one possibility.

Your points miss the point. They would apply if we were about to
standardize R6RS and both square brackets and lambda were on the
table, and I would be arguing for the first but not the second, with
contradicting arguments.

In the actual world, in which I write R6RS programs, however, square
brackets are part of the language, so all I can do is to do my best to
follow the intended convention (which is distributed together with the
R6RS), and which seems self-consistent and meaningful.

Let me make three other points: Firstly, with "lambda", we would not
even be able to formulate a standard convention (except for not using
one of the options, which would be silly). Secondly, the points you
make against square brackets are partly also points against
introducing a Greek letter lambda. Thirdly, if one really wants square
brackets/lambda, one has to have the first baked into the language, but
not the second. So even if there is a need for square brackets/lambdas,
the standard would have no choice but to deliver the first, but could
leave the second to user libraries.

> As such, I think your point about wanting to use λ as a variable name for wavelengths or whatever is the only actually good point you’ve made :-) I have indeed used Greek letters directly when translating some formulas into code. Shadowing of identifiers works fine in Scheme, though …

It is not nice, though*. (And not completely problem-free; as we have
no local imports, we cannot reintroduce a shadowed binding later.)

Marc

PS: You still haven't answered the problem that the addition of the
Greek letter would actually solve.

PPS: One more general point: I wouldn't cite Racket as a good example
here for introducing the Greek letter. While Racket has a beautiful
core language (probably better than core Scheme - but easier for them
to provide because there is basically just one implementation -, the
whole system is a big ball of mud. If Racket code bases are split
between those using "lambda" and those using the Greek letter, that
actually underlines one of my points very well.

Big balls of mud can be great; Guile is another example. But the
standard shouldn't be one, so one has to be careful with such
comparisons.

--

*Some of the more recent programming languages even forbid it for the
sake of reducing errors and making programs easier to understand.