Report on the Yellow Ballot

[John Cowan]

First of all, the raw and processed data can be found at the Google spreadsheet http://tinyurl.com/yellow-docket-responses.

Raw data was lost on the last question, though the summary is available.  The data was cleaned as follows:

1) The ballots cast by "Sam", "Alice [sic] P. Hacker", and "" were discarded as anonymous.

2) Votes like "SRFI nnn" were changed to "Yes".

3) Write-in votes were interpreted by me as well as I could understand them.  Corrections welcome.

4) Mistaken references to SRFI 212 instead of SRFI 213 and vice versa were corrected.

The results were as follows:

a) Explicit renaming failed.  Sorry about that, Gauche, MIT, Chicken, Bigloo, SCM, STklos, Scheme 9, Foment, Picrin, and Owl Lisp fans.  One thing discovered during the ballot period is that if syntax-case has linear expansion, explicit renaming has quadratic expansion, and vice versa.

b) SRFI 5 (`let` with signatures and rest args) and SRFI 156 ((is a < b) rewritten as (< a b)) also failed.

c) All other ballot questions passed, namely:

R6RS-compatible syntax-case

R6RS identifier syntax

SRFI 139 syntax parameters

SRFI 188 splicing let(rec)-syntax

SRFI 212 identifier splicing

SRFI 213 identifier properties

SRFI 61 generalized `cond`

SRFI 8 `receive`

SRFI 31 `rec`

SRFI 26 `cut`

SRFI 219 nested `define`

SRFI 210 multiple-value library

[Vladimir Nikishkin]

The tinyurl link doesn't seem to work for me.

--
Yours sincerely, Vladimir Nikishkin
(Sent with Google mail mobile.)

John Cowan <co...@ccil.org> 于 2022年2月14日周一 09:08写道：

--
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 on the web visit https://groups.google.com/d/msgid/scheme-reports-wg2/CAD2gp_TzGDctU2FXiVgNE6HxL%2B39PDN%3DX-1%3Dw_LitCE639wGLQ%40mail.gmail.com.

[Daphne Preston-Kendal]

On 14 Feb 2022, at 2:08, John Cowan wrote:

> First of all, the raw and processed data can be found at the Google
> spreadsheet http://tinyurl.com/yellow-docket-responses.

Correction: http://tinyurl.com/yellow-ballot-responses
(You posted the right URL in #scheme.)

> The results were as follows:
>
> a) Explicit renaming failed. Sorry about that, Gauche, MIT, Chicken,
> Bigloo, SCM, STklos, Scheme 9, Foment, Picrin, and Owl Lisp fans. One
> thing discovered during the ballot period is that if syntax-case has linear
> expansion, explicit renaming has quadratic expansion, and vice versa.
>
> b) SRFI 5 (`let` with signatures and rest args) and SRFI 156 ((is a < b)
> rewritten as (< a b)) also failed.
>
> c) All other ballot questions passed, namely:
> R6RS-compatible syntax-case
> R6RS identifier syntax
> SRFI 139 syntax parameters
> SRFI 188 splicing let(rec)-syntax
> SRFI 212 identifier splicing
> SRFI 213 identifier properties
> SRFI 61 generalized `cond`
> SRFI 8 `receive`
> SRFI 31 `rec`
> SRFI 26 `cut`
> SRFI 219 nested `define`
> SRFI 210 multiple-value library

I am satisfied with these results. Here is a partial list of issues to consider now:

To do with syntax-case:
• What is the relationship between the procedure syntax-violation of R6RS syntax-case and the special form syntax-error of R7RS small? The former has only three irritants, of which two can probably automatically be supplied assuming syntax-error is implemented in terms of syntax-case, but how implementations are meant to fill the arbitrary number of miscellaneous irritants from syntax-error into a syntax-violation call is unclear.
• Have we implicitly adopted the reader notations #' #` #, and #,@?
• What identifiers within a module are available to be used by macro transformer procedures in that module? What do they refer to? Are they automatically also available to run-time code if they are available to compile-time code? (In other words, how does phasing work in R7RS Large?)
• If I return a value from a syntax transformer which can’t usually appear as a literal in code (a record or a procedure, mainly), what are the evaluation semantics in R7RS?
• Do we wish to provide low-level destructuring of syntax objects in addition to the high-level syntax-case pattern matcher? There are currently two options: the Racket/Gerbil/Chez style <https://gitlab.com/dpk/presrfis/-/blob/master/syntax-case-extensions.md> or the R4RS style <https://www.cs.cmu.edu/Groups/AI/html/r4rs/r4rs_12.html#SEC84>; the distinction is essentially in naming and more convenience procedures in the former.

Other things:
• Does SRFI 61’s cond now extend the cond in (scheme base) or is it a distinct library? (I would be for the latter, and for giving it a distinct name).
• I am not happy about the name of ‘cut’ and ‘cute’, nor the auxiliary syntax. In the former case, even the official explanation given in the SRFI doesn’t make sense: why ‘curry *upon* this’ and not just ‘curry this’ (ct)? Furthermore, this clearly isn’t currying anyway, as the title of the SRFI even admits. (Is it meant to be ironic? A taunt to Haskell programmers?) In the latter, _ for <> would match the conventions of syntax-rules and also other language’s similar features (I believe Scala uses the underscore for something like this). Actually if I had my way I’d use curly braces for this, but lexical notation is probably very much out of the question ;-) ‘pat’ for pattern (as this is a pattern-based way to create a procedure) is one suggestion off the top of my head. Or pat-lambda/pattern-lambda, if that’s too obscure.
• I would still prefer define-alias to just alias. As John said, I consider the ‘establishes a new name’ part of define-* names to be more significant than the ‘establishes a new binding location’ part. (Note Emacs Lisp has defalias and not just alias, for example, and Gerbil and Kawa both call this define-alias.)


Daphne

[Linas Vepstas]

On Sun, Feb 13, 2022 at 7:08 PM John Cowan <co...@ccil.org> wrote:

One thing discovered during the ballot period is that if syntax-case has linear expansion, explicit renaming has quadratic expansion, and vice versa.

This is an intriguing statement. Could there be some short synopsis of what this means, and why it is so?

SRFI 26 `cut`

Cut is a reserved word in prolog and in proof theory in general (assorted cut theorems) Calling something a cut that is not actually a cut seems awkward to me. Ripe for confusion.

--linas

[Daphne Preston-Kendal]

On 14 Feb 2022, at 21:38, Linas Vepstas wrote:

> On Sun, Feb 13, 2022 at 7:08 PM John Cowan <co...@ccil.org> wrote:
>
>>
>> One thing discovered during the ballot period is that if syntax-case has
>> linear expansion, explicit renaming has quadratic expansion, and vice versa.
>>
>
> This is an intriguing statement. Could there be some short synopsis of what this means, and why it is so?

Explicit-renaming stores hygiene information only at the leaves of syntax trees — in the identifiers — and use regular car and cdr operations to destructure expressions. R4RS-style syntax transformer procedures (including ones defined with the R6RS syntax-case pattern matcher) stores hygiene information at potentially any level of an expression.

In order for an R4RS-style syntax object to be completely unwrapped into a structure with only hygienic identifier names, the whole input expression to a macro needs to be walked over at each stage of macro expansion.

If you only store hygiene information at the leaves of an expression, you get different marks on syntax objects created outside of a macro transformer to inside, violating R6RS semantics and making syntax objects less useful as a means of abstraction. (John seems to imply that this could be worked around with another walk over the tree at each macro expansion step, but I don’t see how.)

There are deeper issues, but that’s the core of it. See also SRFI 211.


Daphne

[Daphne Preston-Kendal]

On 14 Feb 2022, at 22:05, Daphne Preston-Kendal wrote:

> On 14 Feb 2022, at 21:38, Linas Vepstas wrote:
>
>> On Sun, Feb 13, 2022 at 7:08 PM John Cowan <co...@ccil.org> wrote:
>>
>>>
>>> One thing discovered during the ballot period is that if syntax-case has
>>> linear expansion, explicit renaming has quadratic expansion, and vice versa.
>>>
>>
>> This is an intriguing statement. Could there be some short synopsis of what this means, and why it is so?

I would like to just briefly add that the fact that a voter on the Yellow Ballot was unaware of this rather crucial fact about what was being voted on until after the ballot was closed speaks volumes about how bad the mechanisms for information sharing among WG2 members are. I won’t dwell on that now, as I intend to make a more detailed, but also hopefully constructive, criticism of it soon.

(To be explicit: I don’t blame Linas for being unaware of this. It’s so hard to find out key facts about the proposals on dockets that I don’t think anyone is able to keep track, myself included.)


Daphne

[Marc Nieper-Wißkirchen]

It should be added that some basic premises for the various syntactic
extensions that have been voted in haven't been discussed yet:
https://groups.google.com/g/scheme-reports-wg2/c/cp7Jh8lv2Dg

Am Di., 15. Feb. 2022 um 10:12 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 on the web visit https://groups.google.com/d/msgid/scheme-reports-wg2/071D63F7-1B18-452A-9494-C920A69BD672%40nonceword.org.

[Linas Vepstas]

Hi Daphne,

On Tue, Feb 15, 2022 at 3:12 AM Daphne Preston-Kendal <d...@nonceword.org> wrote:

On 14 Feb 2022, at 22:05, Daphne Preston-Kendal wrote:

> On 14 Feb 2022, at 21:38, Linas Vepstas wrote:
>
>> On Sun, Feb 13, 2022 at 7:08 PM John Cowan <co...@ccil.org> wrote:
>>
>>>
>>> One thing discovered during the ballot period is that if syntax-case has
>>> linear expansion, explicit renaming has quadratic expansion, and vice versa.
>>>
>>
>> This is an intriguing statement. Could there be some short synopsis of what this means, and why it is so?

I would like to just briefly add that the fact that a voter on the Yellow Ballot was unaware of this rather crucial fact about what was being voted on until after the ballot was closed speaks volumes about how bad the mechanisms for information sharing among WG2 members are. I won’t dwell on that now, as I intend to make a more detailed, but also hopefully constructive, criticism of it soon.

John's message states (and I quote) "discovered during the ballot period" and as I was not the one doing the discovering.  I don't know where that discovery was made; I don't recall seeing emails on this list.

(FWIW I abstained from almost all parts of the ballot, only making token gestures on a few minor points. I'm coming at this as an interested user,  not a maintainer of a  scheme variant.)

-- linas

[Marc Nieper-Wißkirchen]

Am Di., 15. Feb. 2022 um 14:29 Uhr schrieb Linas Vepstas
<linasv...@gmail.com>:

>
> Hi Daphne,
>
> On Tue, Feb 15, 2022 at 3:12 AM Daphne Preston-Kendal <d...@nonceword.org> wrote:
>>
>> On 14 Feb 2022, at 22:05, Daphne Preston-Kendal wrote:
>>
>> > On 14 Feb 2022, at 21:38, Linas Vepstas wrote:
>> >
>> >> On Sun, Feb 13, 2022 at 7:08 PM John Cowan <co...@ccil.org> wrote:
>> >>
>> >>>
>> >>> One thing discovered during the ballot period is that if syntax-case has
>> >>> linear expansion, explicit renaming has quadratic expansion, and vice versa.
>> >>>
>> >>
>> >> This is an intriguing statement. Could there be some short synopsis of what this means, and why it is so?
>>
>> I would like to just briefly add that the fact that a voter on the Yellow Ballot was unaware of this rather crucial fact about what was being voted on until after the ballot was closed speaks volumes about how bad the mechanisms for information sharing among WG2 members are. I won’t dwell on that now, as I intend to make a more detailed, but also hopefully constructive, criticism of it soon.
>
>
> John's message states (and I quote) "discovered during the ballot period" and as I was not the one doing the discovering. I don't know where that discovery was made; I don't recall seeing emails on this list.

It was a private correspondence initiated by me when I noticed that
Larceny actually does not implement R6RS syntax-case. The discovery
also questions Will Clinger's statement in [1] that syntax-case can be
implemented (linearly) in ER or vice versa.

--

[1] https://dl.acm.org/doi/10.1145/3386330

[John Cowan]

On Mon, Feb 14, 2022 at 3:32 AM Daphne Preston-Kendal <d...@nonceword.org> wrote:

 

To do with syntax-case:
• What is the relationship between the procedure syntax-violation of R6RS syntax-case and the special form syntax-error of R7RS small? The former has only three irritants, of which two can probably automatically be supplied assuming syntax-error is implemented in terms of syntax-case, but how implementations are meant to fill the arbitrary number of miscellaneous irritants from syntax-error into a syntax-violation call is unclear.

This is a question about the unification of R6RS condition objects with R7RS-Large condition objects, which is a very large issue that I have been ducking so far.  

• Have we implicitly adopted the reader notations #' #` #, and #,@?

No.  Voting for a SRFI is not a vote for any lexical syntax it introduces, because some SRFIs may have conflicting lexical syntaxes.  LexicalDocket is my attempt to create a list of such lexical syntaxes.

• What identifiers within a module are available to be used by macro transformer procedures in that module? What do they refer to? Are they automatically also available to run-time code if they are available to compile-time code? (In other words, how does phasing work in R7RS Large?)

I am assuming that nobody wants R6RS explicit phasing: it is currently used by Larceny, but Clinger has said that Larceny will eventually be changed.  There have been some requests for Racket-style isolated phasing, but no other implementations I know of.  (The difference is that in R6RS explicit, all phases in which an identifier is defined share the same definition, whereas in Racket each phase may have its own definition (or lack thereof).

• If I return a value from a syntax transformer which can’t usually appear as a literal in code (a record or a procedure, mainly), what are the evaluation semantics in R7RS?

It is an error, for the same reason that (eval + (interaction-environment)) is an error.  There are a few Lisps in which the latter expression evaluates to +, but no Schemes as far as I know.

• Do we wish to provide low-level destructuring of syntax objects in addition to the high-level syntax-case pattern matcher? There are currently two options: the Racket/Gerbil/Chez style <https://gitlab.com/dpk/presrfis/-/blob/master/syntax-case-extensions.md> or the R4RS style <https://www.cs.cmu.edu/Groups/AI/html/r4rs/r4rs_12.html#SEC84>; the distinction is essentially in naming and more convenience procedures in the former.

I would say no, but it could certainly be added to the foundation docket.

Other things:

• Does SRFI 61’s cond now extend the cond in (scheme base) or is it a distinct library? (I would be for the latter, and for giving it a distinct name).

Can you say why you think it should be distinct?  Making them the same may make the underlying `cond` macro run slightly more slowly, but there is no backward compatibility issue.

• I am not happy about the name of ‘cut’ and ‘cute’, nor the auxiliary syntax. In the former case, even the official explanation given in the SRFI doesn’t make sense: why ‘curry *upon* this’ and not just ‘curry this’ (ct)? Furthermore, this clearly isn’t currying anyway, as the title of the SRFI even admits. (Is it meant to be ironic? A taunt to Haskell programmers?)

If you look at the mailing list archives, it is clear that Egner was convinced by the arguments of Winkelmann and others that `section` is the logically correct name as well as being Haskell-compatible, but there was also pressure from other members of the mailing list to use a short name.  `Cut` is short and is synonymous in some of its senses with `section`.  The other interpretations are strictly mnemonic and humoris causa.

The fact that `cut` collides with Prolog meta-language is just unfortunate: in any case, `cut` is *not* part of Prolog itself, where it is spelled `!`.  Given `cut`, `cut-e` would have been better to avoid collision with the English word and is a legitimate cleanup issue.

In the latter, _ for <> would match the conventions of syntax-rules and also other language’s similar features (I believe Scala uses the underscore for something like this). Actually if I had my way I’d use curly braces for this, but lexical notation is probably very much out of the question ;-) ‘pat’ for pattern (as this is a pattern-based way to create a procedure) is one suggestion off the top of my head. Or pat-lambda/pattern-lambda, if that’s too obscure.

This is a legitimate cleanup issue.

[Per Bothner]

On 3/12/22 09:34, John Cowan wrote:

>
>
> On Mon, Feb 14, 2022 at 3:32 AM Daphne Preston-Kendal <d...@nonceword.org <mailto:d...@nonceword.org>> wrote:
> • If I return a value from a syntax transformer which can’t usually appear as a literal in code (a record or a procedure, mainly), what are the evaluation semantics in R7RS?
>
>
> It is an error, for the same reason that (eval + (interaction-environment)) is an error.  There are a few Lisps in which the latter expression evaluates to +, but no Schemes as far as I know.

I admit I don't understand why it should be an error.
It certainly "works" in Kawa:

$ kawa
#|kawa:1|# (eval + (interaction-environment))
#<procedure +>

If nothing else, I guess it's a reasonably extension,
due to the way Kawa implements macro hygiene.
--
--Per Bothner
p...@bothner.com http://per.bothner.com/

[Marc Nieper-Wißkirchen]

Am Sa., 12. März 2022 um 18:34 Uhr schrieb John Cowan <co...@ccil.org>:
>
>
>
> On Mon, Feb 14, 2022 at 3:32 AM Daphne Preston-Kendal <d...@nonceword.org> wrote:
>
>>
>> To do with syntax-case:
>> • What is the relationship between the procedure syntax-violation of R6RS syntax-case and the special form syntax-error of R7RS small? The former has only three irritants, of which two can probably automatically be supplied assuming syntax-error is implemented in terms of syntax-case, but how implementations are meant to fill the arbitrary number of miscellaneous irritants from syntax-error into a syntax-violation call is unclear.

I will try to address this question in my forthcoming proposal on how
to unify R6RS and R7RS.

> No. Voting for a SRFI is not a vote for any lexical syntax it introduces, because some SRFIs may have conflicting lexical syntaxes. LexicalDocket is my attempt to create a list of such lexical syntaxes.

I would suggest an intermediate vote on that as it is probably a
no-brainer. No one would want to write (quasisyntax (unsyntax-splicing
bla) bla)...

>> • If I return a value from a syntax transformer which can’t usually appear as a literal in code (a record or a procedure, mainly), what are the evaluation semantics in R7RS?
>
>
> It is an error, for the same reason that (eval + (interaction-environment)) is an error. There are a few Lisps in which the latter expression evaluates to +, but no Schemes as far as I know.

That this is an error is crucial for AOT compilation (see the recent
SRFI 211 discussion).

>>
>> • Do we wish to provide low-level destructuring of syntax objects in addition to the high-level syntax-case pattern matcher? There are currently two options: the Racket/Gerbil/Chez style <https://gitlab.com/dpk/presrfis/-/blob/master/syntax-case-extensions.md> or the R4RS style <https://www.cs.cmu.edu/Groups/AI/html/r4rs/r4rs_12.html#SEC84>; the distinction is essentially in naming and more convenience procedures in the former.
>
>
> I would say no, but it could certainly be added to the foundation docket.

I would rather add it to a large docket because it is not really a
foundation thing.

>> In the latter, _ for <> would match the conventions of syntax-rules and also other language’s similar features (I believe Scala uses the underscore for something like this). Actually if I had my way I’d use curly braces for this, but lexical notation is probably very much out of the question ;-) ‘pat’ for pattern (as this is a pattern-based way to create a procedure) is one suggestion off the top of my head. Or pat-lambda/pattern-lambda, if that’s too obscure.
>
>
> This is a legitimate cleanup issue.

And "_ ..." instead of "<...>" please. The former wasn't possible when
SRFI 26 was written.

[Marc Nieper-Wißkirchen]

Am Sa., 12. März 2022 um 18:47 Uhr schrieb Per Bothner <p...@bothner.com>:
>
>
>
> On 3/12/22 09:34, John Cowan wrote:
> >
> >
> > On Mon, Feb 14, 2022 at 3:32 AM Daphne Preston-Kendal <d...@nonceword.org <mailto:d...@nonceword.org>> wrote:
> > • If I return a value from a syntax transformer which can’t usually appear as a literal in code (a record or a procedure, mainly), what are the evaluation semantics in R7RS?
> >
> >
> > It is an error, for the same reason that (eval + (interaction-environment)) is an error. There are a few Lisps in which the latter expression evaluates to +, but no Schemes as far as I know.
>
> I admit I don't understand why it should be an error.

Being an error does not necessarily mean that an error has to be signaled.

> It certainly "works" in Kawa:
>
> $ kawa
> #|kawa:1|# (eval + (interaction-environment))
> #<procedure +>
>
> If nothing else, I guess it's a reasonably extension,
> due to the way Kawa implements macro hygiene.

Extending eval in this way in R7RS Large should be possible in
principle and should be discussed I think. This is far less
problematic than macro transformers producing non-literals.