Scheme WG2 Yellow/Kronos Edition ballot

[johnw...@gmail.com]

Having trouble viewing or submitting this form?

Fill out in Google Forms

I've invited you to fill out a form (alternatively, reply to this mailing list):

Scheme WG2 Yellow/Kronos Edition ballot

Dedicated to the memory of John Shutt

0. What is your name? * 1. [non-portable macro system] Should R7RS provide R6RS syntax-case? * No vote No Yes Other: 2. [non-portable macro system] Should R7RS provide explicit renaming? * There is no formal definition of explicit renaming: see https://www.gnu.org/software/mit-scheme/documentation/stable/mit-scheme-ref/Explicit-Renaming.html for the MIT Scheme description No vote No Yes Other: 3. [non-portable macro system] Should R7RS provide the R6RS identifier-syntax macro transformer? * No vote No Yes Other: 4. [non-portable macro feature] Should R7RS provide syntax parameters (hygiene bending)? * This feature allows macros to do more than syntax-rules permits without introducing unhygienic binding. Instead, an identifier is bound once, but its value can be adjusted for successive macro calls. No vote No SRFI 139 Other: 5. [non-portable macro feature] Should R7RS provide R6RS-style splicing versions of let-syntax and letrec-syntax? * When used in a definition context, let-syntax and letrec-syntax provide a new lexical contour, but splicing-let-syntax and splicing-letrec-syntax do not; definitions are spliced into the outer lexical contour. No vote No SRFI 188 Other: 6. [non-portable macro feature] Should R7RS provide identifier aliasing? * Identifier aliasing allows a new variable or syntactic keyword to have the same binding as an existing one. No vote No SRFI 212 Other: 7. [non-portable macro feature] Should R7RS allow arbitrary properties to be attached to an identifier? * No vote No SRFI 212 Other: 8. [portable syntax-rules] Should R7RS provide a generalization of cond to allow different kinds of falsy value or multiple values? * No vote No SRFI 61 Other: 9. [portable syntax-rules] Should R7RS provide syntax for binding a single multiple-valued expression to local variables? * No vote No SRFI 8 Other: 10. [portable syntax-rules] Should R7RS provide syntax for binding a local variable to its body for recursive use? * No vote No SRFI 31 Other: 11. [portable syntax-rules] Should R7RS provide syntax for specializing parameters? * No vote No SRFI 26 Other: 12. [portable syntax-rules] Should R7RS provide named let with rest arguments? * No vote No SRFI 5 Other: 13. [portable syntax-rules] Should R7RS provide syntax (not lexical syntax) for infix notation? * No vote No SRFI 156 Other: 14. [portable syntax-rules] Should R7RS allow definitions like (define ((foo a b) d e f), where foo accepts arguments a and b and returns a procedure that accepts arguments d, e, and f? * No vote No SRFI 219 Other: 15. Should R7RS provide a library of portable syntax-rules macros and procedures for handling multiple values? * No vote No SRFI 210 Other: Never submit passwords through Google Forms. Powered by This content is neither created nor endorsed by Google. Report Abuse - Terms of Service - Additional Terms

Create your own Google Form

[Arthur A. Gleckler]

Question 7 should refer to SRFI 213, not SRFI 212.

Thanks for putting this together, John.

[John Cowan]

The Yellow (also known as Kronos) ballot is about macro systems, macro features, and (syntax-rules) macros.  You can vote for a specific SRFI or equivalent, or vote No to exclude it, or No Answer not to vote, or Other to vote for something else.

[Marc Nieper-Wißkirchen]

Thanks for this compilation, John.

But, as announced earlier, I will abstain.

I still firmly believe that this voting process, while well-intentioned, does not lead to a coherent good language standard. There haven't been any discussions (as far as I can tell) about many proposals to be voted on. The results of the voting will just be a snapshot of who is active at that time (regardless of their function, background, or views) and is not very much related to earlier or future votings on different ballots. Finally, such voting easily leads to feature creep about features that would be probably better included in portable libraries outside the standard.

Cheers,

Marc

Am Sa., 16. Okt. 2021 um 04:09 Uhr schrieb John Cowan <co...@ccil.org>:

The Yellow (also known as Kronos) ballot is about macro systems, macro features, and (syntax-rules) macros.  You can vote for a specific SRFI or equivalent, or vote No to exclude it, or No Answer not to vote, or Other to vote for something else.

--
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_R3tg-aM5zEAWbe7%2Bc26VwwJBGR%3DLWTg%2BWdBC11fkTRrQ%40mail.gmail.com.

[Vladimir Nikishkin]

Sorry for the negligence, but would it be possible to remind the difference between the Yellow and the Kronos editions? 

How did the colour names turn into deities?

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

Marc Nieper-Wißkirchen <marc....@gmail.com> 于 2021年10月16日周六 14:55写道：

To view this discussion on the web visit https://groups.google.com/d/msgid/scheme-reports-wg2/CAEYrNrRAtDnf2PU5S3mF4zYOZ7_%2ByuWwWS9J7zDjsupw7%2BrjOQ%40mail.gmail.com.

[Daphne Preston-Kendal]

Thank you, John.

I agree in substance with Marc’s objections to the current voting process, but I will not abstain from the ballot.

In the interests of promoting discussion and hopefully producing a more informed result, I would urge participants to read SRFI 211 thoroughly before casting their votes. (Yes, it's not finalized yet, but the only truly unfinished part of it is on syntactic closures, which aren’t on the ballot anyway.) Also the discussion around it which has happened here and on the srfi-discuss mailing list. Also, if you have time for it, Will Clinger and Mitchell Wand's extensive paper on the history of Scheme macros: <https://dl.acm.org/doi/10.1145/3386330>

And, for completeness and for those who don’t wish to plough through old discussions, allow me to summarize (as an admittedly biased observer, albeit one who has previously been on the other side of this debate):

syntax-case is the close descendant of the low-level macro system suggested as an implementation mechanism for syntax-rules in the appendix to the R4RS, adding only the syntax-rules pattern matcher and the feature that the right-hand side of each syntax-case clause is arbitrary Scheme code and not merely a pattern. Both syntax-rules and consequently syntax-case are carefully designed to enable computationally efficient compilation of Scheme code, by avoiding the need for quadratic-time macro expansion which plagued early hygienic macro systems. (This situation arises in systems which require the expander to walk over the whole syntax tree at each step of the expansion process, rather than being able to simply copy parts of the tree during expansion without recursing into them.)

Explicit renaming was later proposed as an alternative, simpler primitive on which syntax-rules could be implemented. For the purpose of implementing syntax-rules, it is acceptable, but as a low-level macro system exposed to programmers, it lacks adequate means of parsing input (provided in syntax-case by the pattern matcher), requires verbose manual renaming of every identifier used, and most especially, it has incorrect semantics when deliberately violating hygiene by injecting symbols. The lack of input parsing makes means that most ‘naive’ explicit renaming macros will produce unhelpful nonsense error messages when given incorrect input, whereas syntax-case’s pattern matcher can automatically provide fairly helpful error messages. The implicit renaming variant provides a solution to the verbosity of renaming all symbols, but introduces quadratic expansion time as mentioned above. SRFI 211 proposes a solution to the incorrect semantics when injecting symbols, but likewise requires expansion to take quadratic time (and, I would note, the proposal works by adopting the relevant part of syntax-case, which has this problem solved all along).

As such, although syntax-case has more ‘moving parts’ than explicit renaming, they aren’t there for nothing: they enable correct semantics and performant expansion of all macros.

Lastly, syntax-case (and its close relative identifier-syntax) provide the ability to expand syntax keywords even when they don’t appear in first position of an expression. The examples of doing this in the R6RS spec are fairly useless, but this enables you to write optimizations similar to Common Lisp’s compiler macros, where a procedure can remain first-class but also get optimizations, specified by the procedure(/macro) author, at its call site. This is an important feature when we consider how we’re doing to do things such as keyword arguments. (Whether macros can do this is a feature that is, strictly speaking, orthogonal to the whole question of syntax-case vs explicit renaming, but at present only syntax-case systems actually support this feature. identifier-syntax alone isn’t enough to enable it, since that *only* works on syntax keywords outside of first position.)

Thus I find syntax-case the superior system. I appreciate that it can appear daunting at first, but it is really a small collection of primitives from R4RS, a few conveniences like the pattern matcher and the related with-syntax.

Finally, I would like to remind participants of the WG2 charter’s requirement that ‘When deciding which features to include in the language, working group 2 should consider all features provided by R6RS Scheme, and all criticisms of those features. Insofar as practical, the language should be backwards compatible with an appropriate subset of the R6RS standard.’ To me, this likewise strongly suggests that we should adopt syntax-case. While identifier-syntax has been debated, syntax-case itself (which we could adopt without the identifier syntax feature) is a robust system and I don’t think it has been seriously criticized other than on the basis of its apparent complexity. However, this complexity, as we’ve seen, serves the need for correctness; Scheme has a long-standing and well-deserved reputation for doing the correct thing, even in the face of complexity.

Note that syntax-case and explicit renaming are presented on the ballot paper as two different questions. If we want, we can adopt both. I think this would be inadvisable for reasons of language bloat, but I would accept it if that’s what comes out of this process.


Daphne

[Daphne Preston-Kendal]

On 16 Oct 2021, at 09:46, Daphne Preston-Kendal <d...@nonceword.org> wrote:

> While identifier-syntax has been debated, syntax-case itself (which we could adopt without the identifier syntax feature) is a robust system and I don’t think it has been seriously criticized other than on the basis of its apparent complexity.

For fairness and balance, I will point out one of the more thorough criticisms of syntax-case, by Alex Shinn: <https://lists.gnu.org/archive/html/chicken-users/2008-04/msg00013.html>

To the five points he makes against it (summarized just above the heading ‘--- Macros in Chicken ---’, I would answer:

1. Whether it really is ‘large’, at 13 exported identifiers (of which two are auxiliary syntax keywords), is debatable. But as I wrote in my previous mail, I think the size is justified.

2. There are extensions such as syntax-e, syntax->list, etc. in Gerbil and Racket which can be used to destructure syntax objects without the pattern matcher — I didn’t realize it at the time, but these are actually portable to any syntax-case system (albeit by using the pattern matcher to get back to the underlying primitive).

3. I have proposed elsewhere that we should introduce an additional ‘syntax-transformer’ wrapper around the lambda of a syntax-case macro to resolve this issue — it could be a no-op on existing syntax-case systems.

4. I think the interaction between (syntax …) and the pattern variables established by syntax-case (or the arguably more primitive with-syntax) is well-defined and not implicitly unhygienic — it merely introduces a second lexical variable namespace (which itself might not be a great idea, but it’s what makes syntax-rules implementation in terms of syntax-case so trivial)

5. We can adopt syntax-case without identifier syntax. (Though my own preference would be to include it to enable the features mentioned in my first mail.) If we decide against identifier syntax, I intend to propose a SRFI for compiler macros with vaguely CL-like semantics instead (without introducing CL’s distinction between compiler and interpreter which is foreign to Scheme specifications).


Daphne

[Marc Nieper-Wißkirchen]

Am Sa., 16. Okt. 2021 um 10:03 Uhr schrieb Daphne Preston-Kendal <d...@nonceword.org>:

On 16 Oct 2021, at 09:46, Daphne Preston-Kendal <d...@nonceword.org> wrote:

> While identifier-syntax has been debated, syntax-case itself (which we could adopt without the identifier syntax feature) is a robust system and I don’t think it has been seriously criticized other than on the basis of its apparent complexity.

For fairness and balance, I will point out one of the more thorough criticisms of syntax-case, by Alex Shinn: <https://lists.gnu.org/archive/html/chicken-users/2008-04/msg00013.html>

To the five points he makes against it (summarized just above the heading ‘--- Macros in Chicken ---’, I would answer:

1. Whether it really is ‘large’, at 13 exported identifiers (of which two are auxiliary syntax keywords), is debatable. But as I wrote in my previous mail, I think the size is justified.

Moreover, things like `with-syntax' or `quasi-syntax' are just for convenience. No one would say that Lisp is 'large' because it provides quasiquotation when all you need is 'cons'.

 

2. There are extensions such as syntax-e, syntax->list, etc. in Gerbil and Racket which can be used to destructure syntax objects without the pattern matcher — I didn’t realize it at the time, but these are actually portable to any syntax-case system (albeit by using the pattern matcher to get back to the underlying primitive).

Whether it is actually sensible to use these extensions is a different kettle of fish. For a reason, most modern programming languages, especially the functional ones, tend to declarative pattern matching facilities.

 

3. I have proposed elsewhere that we should introduce an additional ‘syntax-transformer’ wrapper around the lambda of a syntax-case macro to resolve this issue — it could be a no-op on existing syntax-case systems.

Breaking R6RS compatibility for no actual gain. (I had a long discussion with Alex about this; technically, it is not a problem to make it a no-op in systems newly adopting syntax-case; it seems to be a political issue, which is just silly.)

4. I think the interaction between (syntax …) and the pattern variables established by syntax-case (or the arguably more primitive with-syntax) is well-defined and not implicitly unhygienic — it merely introduces a second lexical variable namespace (which itself might not be a great idea, but it’s what makes syntax-rules implementation in terms of syntax-case so trivial)

That's not quite right. Syntax-case does not change Scheme's single-namespace property. What it does, instead, is to define a third type of binding besides variables and keywords, namely pattern variables. But this is nothing revolutionary; the record name in R7RS can also be bound to something neither being a variable nor a keyword. With the identifier properties of SRFI 213, one can write down `syntax-case' and `syntax-case' as a macro in terms of the R4RS low-level primitives, so absolutely nothing magic is going on.

5. We can adopt syntax-case without identifier syntax. (Though my own preference would be to include it to enable the features mentioned in my first mail.) If we decide against identifier syntax, I intend to propose a SRFI for compiler macros with vaguely CL-like semantics instead (without introducing CL’s distinction between compiler and interpreter which is foreign to Scheme specifications).

The arguments that were given against identifier macros aren't convincing.

[Marc Nieper-Wißkirchen]

Am Sa., 16. Okt. 2021 um 10:23 Uhr schrieb Marc Nieper-Wißkirchen <marc....@gmail.com>:

5. We can adopt syntax-case without identifier syntax. (Though my own preference would be to include it to enable the features mentioned in my first mail.) If we decide against identifier syntax, I intend to propose a SRFI for compiler macros with vaguely CL-like semantics instead (without introducing CL’s distinction between compiler and interpreter which is foreign to Scheme specifications).

The arguments that were given against identifier macros aren't convincing.

PS: It just occurred to me that it may be helpful if I explain that a bit more.

1. One argument against identifier macros was that it just provides syntactic sugar that can be abused but which doesn't increase the expressiveness of the language. For sure, identifier macros can be abused in a way to obfuscate the meaning of a piece of code. But so can macros and even (higher-order) procedures. A hammer is not bad per se, although I can use it to hit my fingers and not the nail.

2. As examples like expand-time keyword systems, fluid variables, expand-time SRFI 17-like setters, controlled inlining of procedures, SRFI 190-like coroutine generators, etc. show, identifier macros are far from not increasing the expressiveness of the language. (Expressiveness is increased if one gets new local effects without the need of global transformations.)

3. It was said that the introduction of identifier macros weakened the language because an identifier appearing as syntax may be more than a variable reference and that would make some macros impossible. The answer is to be given here is that a macro that tries to interpret its arguments as Scheme code is doomed to fail sooner or later anyway. Such a macro would no longer work in the context of (future) language extensions and all but the most trivial such macros already break down in the presence of forms like R7RS's `include'. The parts of a form that are interpreted by a macro transformer must always be viewed as an instance of a very particular DSL (defined by the macro's specification), and must not be parsed as general Scheme code. Any well thought out macro will also behave well in the presence of identifier macros. And even the broken ones will only break in the presence of identifier macros when the identifier macro facility is being abused. So, saying that identifier macros weaken the language is like saying that first-class continuations weaken the language (and the impact of first-class continuation on higher-order procedures is much higher!).

[Lassi Kortela]

> a macro that tries to interpret its arguments as Scheme code is doomed
> to fail sooner or later anyway. Such a macro would no longer work in the
> context of (future) language extensions and all but the most trivial
> such macros already break down in the presence of forms like R7RS's
> `include'. The parts of a form that are interpreted by a macro
> transformer must always be viewed as an instance of a very particular
> DSL (defined by the macro's specification), and must not be parsed as
> general Scheme code.

Yes, interpretation of general code requires a code walker. GNU CLISP
comes with one: https://clisp.sourceforge.io/impnotes/code-walk.html

It might be worth standardizing one for Scheme, but it will be a very
complex undertaking. Possibly worth doing as part of RnRS.

[Marc Nieper-Wißkirchen]

In case someone cares about my opinion:

1. SRFI 61 looks very good to me. It is the best approach to multiple values/failure recognition, I have seen so far and could serve to set a good example. (The approach to multiple values/failure recognition of SRFI 202, which is not on the ballot, is, on the other hand, leaves much to be desired and should not be standardized.)

2. I recommend to postpone a final decision on SRFI 26 (and also SRFI 156). Depending on what macro facilities are being voted into R7RS-large, better versions with a bit more bells and whistles may be possible.

3. I would postpone a decision on SRFI 219 until we have collected all extensions to `define` that are desirable and then vote on the final syntax.

4. It's not clear to me what a positive answer to the first question entails. Does it entail the full chapter 12 of the R6RS Standard Libraries and section 9.2 of the R6RS base document?

5. I fully agree with Daphne that having both ER and syntax-case in the same standard causes more trouble than that it helps as ER wouldn't add anything to what can (even more simpler) be expressed using the syntax-case system. Moreover, the current ballot is silent on how to make both systems work together and how to deal with the deficiencies of the bare ER system.

6. If both SRFI 26 and SRFI 156 are voted into R7RS-large, they should agree whether to use "_" or "<>" for the placeholder.

7. While I encourage everyone to use SRFI 156 if they like the proposed infix syntax better than the usual Lisp syntax, I think it is harmful to make it part of a Scheme standard. On the one hand, it is not general enough but just covers a few cases of the motivation behind SRFI 156; on the other hand, it would make reading portable code written by others harder because `(< a b)` is suddenly expressible in two different ways. Apart from that, the semantic differences between `(< a b c)` and `(is a < b < c)` are confusing at the best, but may also lead to subtle errors.

8. I won't say anything about the SRFIs in the ballot I wrote, but I readily answer any questions.

Marc

--

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/000000000000f6f25105ce6cf8f6%40google.com.

[Daphne Preston-Kendal]

On 16 Oct 2021, at 18:11, Marc Nieper-Wißkirchen <marc....@gmail.com> wrote:

> 2. I recommend to postpone a final decision on SRFI 26 (and also SRFI 156). Depending on what macro facilities are being voted into R7RS-large, better versions with a bit more bells and whistles may be possible.

There’s no reason we can’t add extra features to them later, much as (scheme generator) already been extended and (scheme comparator) will likely be extended. (Although syntax-rules portability is still valuable even once we have the low-level macro system sorted, because all R7-small implementations can support such libraries. Also especially valuable if we adopt (as I hope) the rule-of-thumb that things in Large which have portable sample implementations running on small should be mandatory for Large implementations.)

> 3. I would postpone a decision on SRFI 219 until we have collected all extensions to `define` that are desirable and then vote on the final syntax.

I don’t think any further extensions to define itself are desirable. SRFI 219 is a nice thing to have, in part because it happens to fall out of a simple syntax-rules implementation of define. Anything else should be a new form of define with a different name.

> 4. It's not clear to me what a positive answer to the first question entails. Does it entail the full chapter 12 of the R6RS Standard Libraries and section 9.2 of the R6RS base document?

This is also unclear to me. I’m assuming it at this stage that the ballot a general straw poll on approaches to macro system, and we can hammer out details (like identifier macros) later. (Especially since there is still no spec for explicit renaming …)

> 5. I fully agree with Daphne that having both ER and syntax-case in the same standard causes more trouble than that it helps as ER wouldn't add anything to what can (even more simpler) be expressed using the syntax-case system. Moreover, the current ballot is silent on how to make both systems work together and how to deal with the deficiencies of the bare ER system.

I didn’t mention the question of interoperability between the two systems, but that is also a concern. Chibi and Unsyntax support both just fine, though ;-)

> 6. If both SRFI 26 and SRFI 156 are voted into R7RS-large, they should agree whether to use "_" or "<>" for the placeholder.

+1.


Daphne

[Marc Nieper-Wißkirchen]

Am Sa., 16. Okt. 2021 um 19:08 Uhr schrieb Daphne Preston-Kendal <d...@nonceword.org>:

On 16 Oct 2021, at 18:11, Marc Nieper-Wißkirchen <marc....@gmail.com> wrote:

> 2. I recommend to postpone a final decision on SRFI 26 (and also SRFI 156). Depending on what macro facilities are being voted into R7RS-large, better versions with a bit more bells and whistles may be possible.

There’s no reason we can’t add extra features to them later, much as (scheme generator) already been extended and (scheme comparator) will likely be extended.

But you cannot easily add incompatible features later (should these come up and make sense in view of advanced macro facilities).

[...]

 

(Although syntax-rules portability is still valuable even once we have the low-level macro system sorted, because all R7-small implementations can support such libraries. Also especially valuable if we adopt (as I hope) the rule-of-thumb that things in Large which have portable sample implementations running on small should be mandatory for Large implementations.)

> 3. I would postpone a decision on SRFI 219 until we have collected all extensions to `define` that are desirable and then vote on the final syntax.

I don’t think any further extensions to define itself are desirable. SRFI 219 is a nice thing to have, in part because it happens to fall out of a simple syntax-rules implementation of define. Anything else should be a new form of define with a different name.

Keyword arguments or optionals are another area where it can make sense to extend `define`.  (If keyword arguments or an optionals mechanism like in SRFI 227 are adopted, they will probably occur much more often than code to which SRFI 219 applies.)

 

> 4. It's not clear to me what a positive answer to the first question entails. Does it entail the full chapter 12 of the R6RS Standard Libraries and section 9.2 of the R6RS base document?

This is also unclear to me. I’m assuming it at this stage that the ballot a general straw poll on approaches to macro system, and we can hammer out details (like identifier macros) later. (Especially since there is still no spec for explicit renaming …)

So there will be another non-straw poll on these things shortly after this one?

 

> 5. I fully agree with Daphne that having both ER and syntax-case in the same standard causes more trouble than that it helps as ER wouldn't add anything to what can (even more simpler) be expressed using the syntax-case system. Moreover, the current ballot is silent on how to make both systems work together and how to deal with the deficiencies of the bare ER system.

I didn’t mention the question of interoperability between the two systems, but that is also a concern. Chibi and Unsyntax support both just fine, though ;-)

Unsyntax supports both as long as `bound-identifier=?` instead of `eq?` is used to compare identifiers.  And this is unavoidable to make it compatible with `syntax-case`.  Moreover, Unsyntax's ER expander has the same algorithmic complexity as Chicken's IR exapnder.  This also seems unavoidable for ER systems that want to get breaking hygiene right.

Chibi's syntax-case implementation cannot support all uses of `datum->syntax` beecause Chibi's identifiers (symbols outside macro generated code) simply do not carry enough information.  The syntax-case system keeps the lexical context information (the "substitutions" in Dybvig's original paper) apart from the renaming aspect (the "marks").  In the ER approach both parts are intermixed in the single concept of a renaming causing the resulting system being less expressive than the substitutions/marks system.

[...]

Marc

[Marc Nieper-Wißkirchen]

Am Sa., 16. Okt. 2021 um 18:11 Uhr schrieb Marc Nieper-Wißkirchen <marc....@gmail.com>:

In case someone cares about my opinion:

1. SRFI 61 looks very good to me. It is the best approach to multiple values/failure recognition, I have seen so far and could serve to set a good example. (The approach to multiple values/failure recognition of SRFI 202, which is not on the ballot, is, on the other hand, leaves much to be desired and should not be standardized.)

After having given it a bit more thought to SRFI 61, I have to relativize my recommendation. While it is more general than ordinary `cond` and handles some extended cases involving multiple values reasonably, it still doesn't handle the general case: The most general case of a condition delivering values in the positive case can be modelled by a procedure taking a success and a failure "continuation". An example is given by a parsing procedure `(parse STRING SUCCESS FAILURE)` that parses STRING and calls SUCCESS on the resulting values when the parsing is successful and FAILURE on no values when parsing is not successful.

Maybe it is not a good idea to add enough generality to `cond` to be able to handle this situation idiomatically, but I think it should be discussed. (That's a general point about this ballot: There have not been many discussions on the items apart from syntax-case/ER issues in the context of R7RS-large, have there?)

A first approach to a general `cond` form, called `select` here, can look like the following one:

(select

  ((parse-number str (=> sign absval) (=> #f))

   <body1>)

  ((parse-string str (=> len chars) (=> #f))

   <body2>)

  (else <expr1> ... <expr2>)) 

Here, `sign` and `absval` will be bound in <body1> and `len` and `chars` will be bound in <body2>.  The general syntax (omitting the else clause) is

(select

  ((<cond> <body>) ...))

In <cond> `=>` is syntax-parameterized so that `(=> #f)` evaluates to a procedure that, when called, evaluates the `select` expression restricted to the following clauses and `(=> . <formals>)` evaluates to a procedure that, when called on arguments, evaluates the corresponding <body> with the identifiers in <formals> bound to the arguments.

(Note that this is a good example of why R6RS macro invocations of the form `(keyword . datum)` are good to have.)

The usual `cond` can be reduced to `select`:

A `cond` clause of the form `(<test> <expr> ...)` is rewritten to a `select` clause of the form

((let ((tmp <test>)) (if tmp ((=> tmp)) ((=> #f)))) (begin tmp <expr> ...)

and a `cond` clause of the form `(<test> => <expr>)` is rewritten to a `select` clause of the form

((let ((tmp <test>)) (if tmp ((=> tmp)) ((=> #f)))) (<expr> tmp))

Finally, SRFI 61 clauses of the form `(<producer> <guard> => <consumer>)` are rewritten to a `select` clause of the form

((let-values ((tmp* <producer>)) (if (apply <guard> tmp*) ((=> tmp*)) ((=> #f))) (apply <consumer> tmp*))

`Select`, whether merged or not with `cond` is attractive for many of the data structure APIs of recent SRFIs.

-- Marc

[John Cowan]

On Sat, Oct 16, 2021 at 2:55 AM Marc Nieper-Wißkirchen <marc....@gmail.com> wrote:

But, as announced earlier, I will abstain.

And as I believe I said earlier, no one is being paid to vote.

I may or may not have said that voting ends at the end of January 2022 anywhere on Earth (that is, February 1st at 1200 UTC).  As with all R7RS Scheme ballots, you are eligible to vote if (a) you have voted in any Scheme election since the 2009 Steering Committee election, or (b) you post to this mailing list a brief statement of your interest in Scheme standardization.

[Arthur A. Gleckler]

On Sun, Oct 17, 2021 at 6:32 PM John Cowan <co...@ccil.org> wrote:

 

And as I believe I said earlier, no one is being paid to vote.

 

I hope that everyone who loves the language will, in the end, vote.  Let's not let the perfect be the enemy of the good.  And, as I tell friends and family before elections, I for one will not listen to the complaints of anyone who hasn't voted, no matter how well grounded they are.  Even if R7RS Large doesn't become the Platonic ideal standard for Scheme, the imperfect voting system we have is how we can at least make progress toward that ideal.

Just in case, I've reserved r8rs.org so that we have it for the next round.

[Marc Nieper-Wißkirchen]

Am Mo., 18. Okt. 2021 um 06:12 Uhr schrieb Arthur A. Gleckler <a...@speechcode.com>:

On Sun, Oct 17, 2021 at 6:32 PM John Cowan <co...@ccil.org> wrote:

 

And as I believe I said earlier, no one is being paid to vote.

 

I hope that everyone who loves the language will, in the end, vote.  Let's not let the perfect be the enemy of the good.  And, as I tell friends and family before elections, I for one will not listen to the complaints of anyone who hasn't voted, no matter how well grounded they are. 

Referring to elections in democratic countries, I fully subscribe to your opinion. But it doesn't support the system in principle, I think it is important that non-participation remains a valid choice of action. By participating, one endorses the system and submits to whatever comes out. In this sense, one could possibly even turn around the argument and claim that those who participated are those who shouldn't complain but should accept the result.

The current voting system encourages piling library on top of library with only weak coherence; if one opposes this, it cannot really be expressed through voting.

Anyway, I try to participate actively in improving Scheme in different ways, say by writing SRFIs and by voicing my opinion on matters I deem important.

 

Even if R7RS Large doesn't become the Platonic ideal standard for Scheme, the imperfect voting system we have is how we can at least make progress toward that ideal.

If one looks at all the SRFIs that emerged since the R7RS Large project was started and at all the deep discussions on syntax and semantics of the language around them, I think we have been making a lot of progress (even) outside any ballots and outside declaring certain subsets of SRFIs as certain (colored) editions of R7RS Large. On the other hand, I am not so sure whether carving the huge collection of SRFIs that are or will be part of R7RS Large in stone can be considered progress. In fact, I fear that it may not.

 

Just in case, I've reserved r8rs.org so that we have it for the next round.

Thanks! And good to know!

For sure, we don't want to have another split of the Scheme language after the R6RS/R7RS divorce, so if we envision the possibility of an R8RS, we should keep this in mind when designing R7RS Large. Withdrawing things or adding in incompatible changes can easily lead to a split, but the larger R7RS Large gets and the more anarchical it grows, the harder it will be to have a next standard building on it.

I should add that these are my personal opinions. It's perfectly clear that I may be wrong and that other opinions are at least as well-founded.

Marc

[Lassi Kortela]

> By participating, one endorses the system and submits to whatever comes
> out. In this sense, one could possibly even turn around the argument and
> claim that those who participated are those who shouldn't complain but
> should accept the result.

George Carlin made this point in a well-known comedy bit (a web search
for "why I don't vote" finds it).

The main function of voting is to affirm the existing power structure as
a whole. Non-voters refuse to take the affirmation, which is an affront
to the worldview of voters. Complaints about specific policies don't
enter into it: both a voter and a non-voter have the same infinitesimal
effect on the policies that are actually implemented, and both know it.

[Marc Nieper-Wißkirchen]

Am Mo., 18. Okt. 2021 um 11:05 Uhr schrieb Marc Nieper-Wißkirchen <marc....@gmail.com>:

Am Mo., 18. Okt. 2021 um 06:12 Uhr schrieb Arthur A. Gleckler <a...@speechcode.com>:

On Sun, Oct 17, 2021 at 6:32 PM John Cowan <co...@ccil.org> wrote:

 

And as I believe I said earlier, no one is being paid to vote.

 

I hope that everyone who loves the language will, in the end, vote.  Let's not let the perfect be the enemy of the good.  And, as I tell friends and family before elections, I for one will not listen to the complaints of anyone who hasn't voted, no matter how well grounded they are. 

Referring to elections in democratic countries, I fully subscribe to your opinion. But it doesn't support the system in principle, I think it is important that non-participation remains a valid choice of action. By participating, one endorses the system and submits to whatever comes out. In this sense, one could possibly even turn around the argument and claim that those who participated are those who shouldn't complain but should accept the result.

TYPO! Please read: "But if one doesn't support...".

[Vladimir Nikishkin]

>y participating, one endorses the system and submits to whatever comes out. In this sense, one could possibly even turn around the argument and claim that those who participated are those who shouldn't complain but should accept the result.

As a person who has quite a lot of experience with elections, I could
not disagree more. I have yet to see a system that works this way.
In "almost surely" all circumstances I have seen, abstention means "I
do not mind". Conversely, if you have taken part and voted against, it
is a valid proof of your disagreement (and thus a critical point
towards the procedure in general.).

I do not think this question is regarding a democratic or an
authoritarian system per se. I think that the inflection point lies in
the turnout. If less than a convincing majority of the eligible voters
turn up, the rest can be considered "agreeing by default". If more
than a convincing majority turns up, the rest can be considered
"boycotting and thus disagreeing".

(What is a convincing majority is a question though.)

> --
> 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/b5047130-31e9-f52e-7cc4-ac22e2f2c8a1%40lassi.io.

--
Yours sincerely, Vladimir Nikishkin

(Sent from GMail web interface.)

[Marc Nieper-Wißkirchen]

Am Mo., 18. Okt. 2021 um 12:38 Uhr schrieb Vladimir Nikishkin <lock...@gmail.com>:

>y participating, one endorses the system and submits to whatever comes out. In this sense, one could possibly even turn around the argument and claim that those who participated are those who shouldn't complain but should accept the result.

As a person who has quite a lot of experience with elections, I could
not disagree more. I have yet to see a system that works this way.
In "almost surely" all circumstances I have seen, abstention means "I
do not mind". Conversely, if you have taken part and voted against, it

Within the system, abstention does, of course, mean "I do not mind" (unless the system has some built-in quorum).

Viewed from outside the system, it is quite a different thing.

PS I do vote in every democratic election as a citizen of my state of residence, not because we have already reached the platonic ideal of a democratic state but because I believe that abstention (and the message connected to it) and not endorsing the system would be detrimental. With the current way leading to R7RS Large, I think differently. Voting would, in my opinion, cement the way it is currently going, so I think that it is less detrimental not to vote.  It is certainly not that "I do not mind", quite the contrary, and I think my contributions to this list and the SRFI process show it.

[Arthur A. Gleckler]

On Mon, Oct 18, 2021 at 2:05 AM Marc Nieper-Wißkirchen <marc....@gmail.com> wrote:

 

Anyway, I try to participate actively in improving Scheme in different ways, say by writing SRFIs and by voicing my opinion on matters I deem important.

Yes, and thank you for that.  Scheme is better because of the enthusiastic participation of so many people.

[Robert Calco]

Without respect to voting on the ballot presented per se, which I haven't decided yet (since I'm only familiar with a couple of the proposals and need time to consider them), I'd like to register my interest in Scheme standardization in order to reserve that right. I'm currently working on a new native Scheme compiler in its early stages of development, and separately with one that has already been created to run on the CLR (namely, IronScheme, maintained by Llewelyn Pritchard). Both of these target R6RS, but the native one I'm working on is more likely to target R7RS and beyond. It has struck me how hard code portability between Scheme implementations in practice has been, and how much basic things like library structure change from one standard to the next. I'm therefore keen on proposals that will increase code portability and reduce the incompatibility of library mechanisms. I have other interests, such as supporting purer functional programming paradigms, but those are the main ones I see needing "better" standardization.

--

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_QF4_6ORi3Qv2R2jY4mw5VcH917o1dbYSsQVjGcd_HHJw%40mail.gmail.com.

--

Bob Calco

bobc...@gmail.com

813-997-3583 (work mobile)

813-523-3751 (personal mobile)

"But you can catch yourself entertaining habitually certain ideas and setting others aside; and this, I think, is where our personal destinies are largely decided." -- Alfred North Whitehead

"And now I see with eye serene the very pulse of the machine." -- William Wordsworth

[Dr. Arne Babenhauserheide]

Lassi Kortela <la...@lassi.io> writes:

>> By participating, one endorses the system and submits to whatever
>> comes out. In this sense, one could possibly even turn around the
>> argument and claim that those who participated are those who
>> shouldn't complain but should accept the result.
>
> George Carlin made this point in a well-known comedy bit (a web search
> for "why I don't vote" finds it).
>
> The main function of voting is to affirm the existing power structure
> as a whole. Non-voters refuse to take the affirmation, which is an
> affront to the worldview of voters.

This depends on what you vote on.

The main function of voting is to either take a decision as a group or
get an aggregate of opinions.

In this ballot, you always have the option "other" with a free form text
field. So if your disagreement is not about voting as a process but
about the specific ballot, you can just use the "other" free form text
to state something like „This is not yet in a good enough shape to be
voted on“. Or „this ballot is not ready“. That way you record your
opinion in a referencable way.

If you do not vote at all, you take the decision not to take part in
group-based decisionmaking.

Naturally you can also comment here on the ballot — which would also be
group-based decisionmaking.

> Complaints about specific policies don't enter into it:
> both a voter and a non-voter have the same
> infinitesimal effect on the policies that are actually implemented,
> and both know it.

This is only true in large groups where most do not have a part in
implementing the policies. In smaller groups like this one the effect of
every voter is much bigger.

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

[Taylan Kammer]

On 18.10.2021 11:05, Marc Nieper-Wißkirchen wrote:
>
> The current voting system encourages piling library on top of library with only weak coherence; if one opposes this, it cannot really be expressed through voting.
>

I agree to your criticism but a large number of "No" votes would effectively be
an expression of that criticism, wouldn't it?

My answers contain two "Yes" votes (for syntax-case and SRFI-188), 6 "No" votes
and 7 "No vote" votes.

I really want syntax-case, and that's really the most important thing to me.

SRFI-188 is something I see myself desiring at some point while programming
something, and it's a very non-intrusive addition so it's quite welcome.

For all the others, without going into details, the "No vote" ones are SRFIs
which I think are OK but really not needed in the standard, and the "No" ones
are intrusive or large changes or large libraries that I find completely
unnecessary or even potentially harmful to code readability (SRFI 5 sounds
really bad to me for instance, due to the strange use of dot-notation).

--
Taylan

[Marc Nieper-Wißkirchen]

Am Di., 19. Okt. 2021 um 19:26 Uhr schrieb Taylan Kammer <taylan...@gmail.com>:

On 18.10.2021 11:05, Marc Nieper-Wißkirchen wrote:
>
> The current voting system encourages piling library on top of library with only weak coherence; if one opposes this, it cannot really be expressed through voting.
>

I agree to your criticism but a large number of "No" votes would effectively be
an expression of that criticism, wouldn't it?

Partially, but it wouldn't touch the question of coherence.

For example, the syntax-case or ER system becomes so much more expressive with identifier properties* that one may decide that including syntax-case or ER makes only sense together with identifier properties. But this cannot be expressed because the voting system produces some unrelated average per item.

Of course, one could add a statement like "count my vote for syntax-case only if identifier properties will be included", but individual options that are taken only by single persons tend to be non-influential.

-- Marc

(*) That the SRFI 213 identifier properties considerably increase the usefulness of a macro system like syntax-case or ER is not fictional and needed for communicating macros (much as syntax-case/syntax communicate about pattern variables) where the communicating objects are properly lexically scoped. The Nanopass framework is a large example that is made possible with identifier properties. Simpler examples included R7RS-style syntactic record names that carry syntactic information that can be used at macro expansion time for example for pattern matchers or child record types.

[John Cowan]

On Tue, Oct 19, 2021 at 1:26 PM Taylan Kammer <taylan...@gmail.com> wrote:

SRFI 5 sounds
really bad to me for instance, due to the strange use of dot-notation.

I'm not a user of SRFI 5 personally, but the (let ((a 1) (b 2) (c 3) . (d '())) exprs) notation allows you to invoke p with 3 or more arguments where the extra args are bound to d, whereas standard named-let requires p to be invoked with a fixed number of arguments only.  So this is an increase in expressive power.  The other SRFI 5 feature is basically just syntax sugar: it allows you to write (let (p (a 1) (b 2) (c 3)) exprs) as well as (let p ((a 1) (b 2) (c 3)) exprs)

[John Cowan]

On Tue, Oct 19, 2021 at 2:08 PM Marc Nieper-Wißkirchen <marc....@gmail.com> wrote:

 

For example, the syntax-case or ER system becomes so much more expressive with identifier properties* that one may decide that including syntax-case or ER makes only sense together with identifier properties.

That's as much as to say that R6RS syntax-case is by itself useless, which I don't think anyone else believes.

 

Of course, one could add a statement like "count my vote for syntax-case only if identifier properties will be included", but individual options that are taken only by single persons tend to be non-influential.

Well, one can say "I'm voting conditionally and this is why."

[Marc Nieper-Wißkirchen]

Am Di., 19. Okt. 2021 um 21:32 Uhr schrieb John Cowan <co...@ccil.org>:

On Tue, Oct 19, 2021 at 2:08 PM Marc Nieper-Wißkirchen <marc....@gmail.com> wrote:

 

For example, the syntax-case or ER system becomes so much more expressive with identifier properties* that one may decide that including syntax-case or ER makes only sense together with identifier properties.

That's as much as to say that R6RS syntax-case is by itself useless, which I don't think anyone else believes.

It was just an example (and that's why I added in the footnote that the claimed increase in expressiveness is not fictional) and maybe not the best one.

[Marc Nieper-Wißkirchen]

Am Di., 19. Okt. 2021 um 21:09 Uhr schrieb John Cowan <co...@ccil.org>:

On Tue, Oct 19, 2021 at 1:26 PM Taylan Kammer <taylan...@gmail.com> wrote:

SRFI 5 sounds
really bad to me for instance, due to the strange use of dot-notation.

I'm not a user of SRFI 5 personally, but the (let ((a 1) (b 2) (c 3) . (d '())) exprs) notation allows you to invoke p with 3 or more arguments where the extra args are bound to d, whereas standard named-let requires p to be invoked with a fixed number of arguments only.  So this is an increase in expressive power. 

I like the increase in expressiveness, but I agree with Taylan that the notation is strange and that probably a better syntax has to be found, e.g. "named-receive" à la SRFI 8 (substitute with a better name):

(named-receive f <formals> <init> <body>)

=>

(letrec ((f (lambda <formals> <body>)))

  (call-with-values (lambda () <init>) f))

Your example would then be:

(named-receive p (a b c . d) (values 1 2 3) exprs).

One can see it as unfortunate that the name "receive" cannot be used for "named receive" as well (because of ambiguity), but one can also see it as fortunate because editors like Emacs need quite some hackery to be able to treat named let differently from let.

 

The other SRFI 5 feature is basically just syntax sugar: it allows you to write (let (p (a 1) (b 2) (c 3)) exprs) as well as (let p ((a 1) (b 2) (c 3)) exprs)

What's the point of this? I don't see any advantage but the risk of diverging code bases.

[John Cowan]

On Tue, Oct 19, 2021 at 3:59 PM Marc Nieper-Wißkirchen <marc....@gmail.com> wrote:'

One can see it as unfortunate that the name "receive" cannot be used for "named receive" as well (because of ambiguity), but one can also see it as fortunate because editors like Emacs need quite some hackery to be able to treat named let differently from let.

If you want to write this up as a SRFI (which I think will be pretty uncontroversial) I'll add it to the ballot.

What's the point of this? I don't see any advantage but the risk of diverging code bases.

The same can be said of (define a (lambda (b c) exprs) vs. (define (a b c) exprs).  I prefer the second format; others prefer the first. 

[Marc Nieper-Wißkirchen]

Am Di., 19. Okt. 2021 um 22:03 Uhr schrieb John Cowan <co...@ccil.org>:

On Tue, Oct 19, 2021 at 3:59 PM Marc Nieper-Wißkirchen <marc....@gmail.com> wrote:'

One can see it as unfortunate that the name "receive" cannot be used for "named receive" as well (because of ambiguity), but one can also see it as fortunate because editors like Emacs need quite some hackery to be able to treat named let differently from let.

If you want to write this up as a SRFI (which I think will be pretty uncontroversial) I'll add it to the ballot.

Thanks, but I have to get my current SRFIs finished first. I encourage everyone to toy with the "named receive"-idea and write their own SRFI.

 

What's the point of this? I don't see any advantage but the risk of diverging code bases.

The same can be said of (define a (lambda (b c) exprs) vs. (define (a b c) exprs).  I prefer the second format; others prefer the first. 

That could only be solved by banning the `(define (f ...) ...)` shorthand but that would probably cause a riot. :)

In any case, The second `define` really is some useful abbreviation (because you can drop the lambda) just like the idea of a named-let is a useful abbreviation for a certain type of letrec construct.

The alternative named-let syntax proposed by SRFI 5, however, just differs in the place of one symbol so there is no real gain. And the motivation in SRFI 5 for that change is very lame and the inconsistency is only perceived.

I just checked the mailing list of SRFI 5. Apparently, it has never been thoroughly discussed.

[Taylan Kammer]

On 19.10.2021 21:09, John Cowan wrote:
>
> (let p ((a 1) (b 2) (c 3) . (d '())) exprs)

My problem with this syntax is that it's not the canonical representation
of the s-expression it represents, which would instead be:

(let p ((a 1) (b 2) (c 3) d '()) exprs)

So if a program reads and then writes code using SRFI 5, it will produce
that arguably confusing and non-intuitive output.

I suspect that named-let with rest arguments is a very rare use case, but
if really desired I'd highly prefer a different syntax for this reason.

Perhaps:

(let p ((a 1) (b 2) (c 3) (d ... '())) exprs)

But I guess reusing the aux syntax '...' this way would cause headaches
when you want to produce a named-let with rest arguments via a macro
template? Then again, that should be even rarer than the already rare
case of a named-let with rest arguments per se. Even macro-producing
macros are probably more common, for which we already have some hacks
to avoid the ellipsis problem that can be used here just as well.

My proposed syntax also clashes with SRFI 71 where the "(d ... expr)"
would erroneously expect "expr" to return two values and bind them to
the identifiers 'd' and '...' but I suppose one could define the
rest-argument meaning of '...' in that position to have higher
priority, since it will almost certainly be the intended meaning.

Anyhow, I'm rambling, maybe I should make a mini-SRFI for this syntax
so it can be properly discussed. Unless someone wants to shoot it
down right here and now, like in case I'm missing something obvious.

--
Taylan

[Dr. Arne Babenhauserheide]

Thank you for creating the ballot!

Also thank you very much for the plain-text version!

I tried to vote, but realized that I have still too little information
to actually give my preference for many of the points.

It would be great to have a "further reading" link for each of the
points — the SRFIs are a good example of that.

johnw...@gmail.com writes:

> Scheme WG2 Yellow/Kronos Edition ballot
>
> Dedicated to the memory of John Shutt
>

> 0. What is your name? Arne Babenhauserheide

> 1. [non-portable macro system] Should R7RS provide R6RS syntax-case? *
>

> * No vote
> * No
> * Yes

Yes

> * Other:

>
> 2. [non-portable macro system] Should R7RS provide explicit renaming? *
> There is no formal definition of explicit renaming: see https://www.gnu.org/software/mit-scheme/documentation/stable/mit-scheme-ref/Explicit-Renaming.html for the MIT Scheme description
>

> * No vote
> * No
> * Yes
> * Other:

Other: I am unsure. From the discussions in here I am in favor of
syntax-case, because I really want to keep my macros, and having
multiple macro systems would go against the elegance I see in Scheme as
a standard (remove limitations instead of piling up features — in this
case: competing features side by side).

> 3. [non-portable macro system] Should R7RS provide the R6RS identifier-syntax macro transformer? *
>

> * No vote
> * No
> * Yes
> * Other:

Other: I do not know yet.

I need more reasons why some existing R5RS Schemes do not want R6RS macros.

> 4. [non-portable macro feature] Should R7RS provide syntax parameters (hygiene bending)? *
> This feature allows macros to do more than syntax-rules permits without introducing unhygienic binding. Instead, an identifier is bound once, but its value can be adjusted for successive macro calls.
>

> * No vote
> * No
> * SRFI 139
> * Other:

Same as for 3.

Quadratic Time macros are a no-go for me.

> 5. [non-portable macro feature] Should R7RS provide R6RS-style splicing versions of let-syntax and letrec-syntax? *
> When used in a definition context, let-syntax and letrec-syntax provide a new lexical contour, but splicing-let-syntax and splicing-letrec-syntax do not; definitions are spliced into the outer lexical contour.
>

> * No vote
> * No
> * SRFI 188
> * Other:
SRFI 188. This sounds like a good way to unify R[567]RS.

> 6. [non-portable macro feature] Should R7RS provide identifier aliasing? *
> Identifier aliasing allows a new variable or syntactic keyword to have the same binding as an existing one.
>

> * No vote
> * No
> * SRFI 212
> * Other:
Same as for 3. I’m not sure.

> 7. [non-portable macro feature] Should R7RS allow arbitrary properties to be attached to an identifier? *
>

> * No vote
> * No
> * SRFI 212
> * Other:

SRFI 212? Need more info. That's the aliases SRFI.

Arbitrary properties attached to an identifier would be good: That
can allow for very convenient doctesting — see
https://hg.sr.ht/~arnebab/wisp/browse/examples/doctests.scm?rev=7ccdb6b2fd94#L104

> 8. [portable syntax-rules] Should R7RS provide a generalization of cond to allow different kinds of falsy value or multiple values? *
>

> * No vote
> * No
> * SRFI 61
> * Other:

No: I do not like reserving syntax (=>) in the standard. It can be
implemented via syntax-case, so every conforming implementation can
provide the SRFI.

Also I do not like different kinds of falsy. That’s a very common
source of ugly problems in Javascript.

> 9. [portable syntax-rules] Should R7RS provide syntax for binding a single multiple-valued expression to local variables? *
>

> * No vote
> * No
> * SRFI 8
> * Other:

SRFI 8.

> 10. [portable syntax-rules] Should R7RS provide syntax for binding a local variable to its body for recursive use? *
>

> * No vote
> * No
> * SRFI 31
> * Other:

No: I do not see this as sufficiently stronger than named let, so I would prefer the rec variable to stay free.

> 11. [portable syntax-rules] Should R7RS provide syntax for specializing parameters? *
>

> * No vote
> * No
> * SRFI 26
> * Other:

I’m not sure. I like cut, but I don’t like the reserved syntax (<> and
<…>). It is OK in a library, but I think it has no place in the
standard.

So rather No.

> 12. [portable syntax-rules] Should R7RS provide named let with rest arguments? *
>

> * No vote
> * No
> * SRFI 5
> * Other:

Other: I think the full (let (fun ...) …) of SRFI-5 is too much, but I would like

(let fibonacci ((n 10) (i 0) (f0 0) . (f1 1)) …)

but not

(let (fibonacci (n 10) (i 0) (f0 0) (f1 1)) …)

But I’m not sure about my reasoning here. It might just be unfamiliarity. After all,

(let (a (b 1)) a)

is aleady a syntax error, so SRFI-5 is guaranteed not to break any existing code.

> 13. [portable syntax-rules] Should R7RS provide syntax (not lexical syntax) for infix notation? *
>

> * No vote
> * No
> * SRFI 156
> * Other:

Other: I think the `is` macro is beautiful, but isnt should not enter
the language: It is just (not (is …)), and using abbreviations of slang
("isn’t" as abbreviation of "is not") does not match existing
identifiers in R7RS-small.

> 14. [portable syntax-rules] Should R7RS allow definitions like (define ((foo a b) d e f), where foo accepts arguments a and b and returns a procedure that accepts arguments d, e, and f? *
>

> * No vote
> * No
> * SRFI 219
> * Other:

No, because that would prevent using such forms for other usages like
optional typing, which is an area that people are actively
experimenting with.

> 15. Should R7RS provide a library of portable syntax-rules macros and procedures for handling multiple values? *
>

> * No vote
> * No
> * SRFI 210
> * Other:

Other: SRFI-210, but the naming */mv does not match well, because from Linux it evokes */move.

Rationale: Multiple values are badly supported at the moment. Since
they are in the standard, the support machinery should be provided.

[Marc Nieper-Wißkirchen]

Am Do., 21. Okt. 2021 um 10:29 Uhr schrieb Dr. Arne Babenhauserheide <arne...@web.de>:

>  7. [non-portable macro feature] Should R7RS allow arbitrary properties to be attached to an identifier? * 
>   
>  * No vote 
>  * No 
>  * SRFI 212 
>  * Other:

SRFI 212? Need more info. That's the aliases SRFI.

SRFI 213 is meant here.

[Marc Nieper-Wißkirchen]

Am Do., 21. Okt. 2021 um 10:29 Uhr schrieb Dr. Arne Babenhauserheide <arne...@web.de>:

>  4. [non-portable macro feature] Should R7RS provide syntax parameters (hygiene bending)? * 
>  This feature allows macros to do more than syntax-rules permits without introducing unhygienic binding. Instead, an identifier is bound once, but its value can be adjusted for successive macro calls. 
>   
>  * No vote 
>  * No 
>  * SRFI 139 
>  * Other:

Same as for 3.

Quadratic Time macros are a no-go for me.

What do you mean by this, especially in relation to SRFI 139?

 

>  8. [portable syntax-rules] Should R7RS provide a generalization of cond to allow different kinds of falsy value or multiple values? * 
>   
>  * No vote 
>  * No 
>  * SRFI 61 
>  * Other:

No: I do not like reserving syntax (=>) in the standard. It can be
implemented via syntax-case, so every conforming implementation can
provide the SRFI.

I am not sure whether I understand your complaint. `=>' is already an auxiliary syntax keyword exported by the base library.  Of course, `cond' can be extended as library syntax but extending it in the base library has the advantage that the base library can always be imported unconditionally.

 

Also I do not like different kinds of falsy. That’s a very common
source of ugly problems in Javascript.

In what sense is this related to SRFI 61? The eof object is some kind of "falsy" value, which is already in existence. What SRFI 61 provides is a clean way of mapping that value to the true false value, namely #f.

>  10. [portable syntax-rules] Should R7RS provide syntax for binding a local variable to its body for recursive use? * 
>   
>  * No vote 
>  * No 
>  * SRFI 31 
>  * Other:

No: I do not see this as sufficiently stronger than named let, so I would prefer the rec variable to stay free.

`rec' is not a wrapper around named let, which calls the bound procedure. In fact, `rec' is a different wrapper around `letrec', which one can use to define named let:

(let f ((<var> <init>) ...) <body>)

=>

((rec f (lambda (<var> ...) <body>)) <init> ...)

 

>  11. [portable syntax-rules] Should R7RS provide syntax for specializing parameters? * 
>   
>  * No vote 
>  * No 
>  * SRFI 26 
>  * Other:   

I’m not sure. I like cut, but I don’t like the reserved syntax (<> and
<…>). It is OK in a library, but I think it has no place in the
standard.

One should cut down the auxiliary syntax needed by replacing `<...>' with the juxtaposition of `<>' and `...'. (See SRFI 148 and SRFI 197 for that approach.)

One may then want to replace `<>' with `_' so that no additional auxiliary syntax is needed.

 

Marc

[John Cowan]

On Thu, Oct 21, 2021 at 4:28 AM Dr. Arne Babenhauserheide <arne...@web.de> wrote:

Thank you for creating the ballot!

Also thank you very much for the plain-text version!

I tried to vote, but realized that I have still too little information
to actually give my preference for many of the points.

It would be great to have a "further reading" link for each of the
points — the SRFIs are a good example of that.

Alas, Google forms don't allow any links.

I will hand-transfer your ballot to the results after the polls close.

[Linas Vepstas]

Easier to read for newbies. Scheme remains challenging and fearsome to beginners. The former notation seems to be easier to read and understand.

For example, beginners are comfortable with (define (f x y z) exprs) but often find (define f (lambda (x y z) exprs)) to be deeply confusing and hard to understand. Language adoption means being friendly to newbies.

--linas

--

Patrick: Are they laughing at us?

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

 

[Marc Nieper-Wißkirchen]

Am Mi., 27. Okt. 2021 um 18:55 Uhr schrieb Linas Vepstas <linasv...@gmail.com>:

For example, beginners are comfortable with (define (f x y z) exprs) but often find (define f (lambda (x y z) exprs)) to be deeply confusing and hard to understand. Language adoption means being friendly to newbies.

From a didactical point of view, the version

(define f

  (lambda (x y z)

    exprs))

has advantages if the point that Scheme is a functional language is to be stressed.  (The other version has advantages, also from a didactical point of view, for people coming from non-functional languages that do not want to be burdened with the baggage of first-class functions.)

(NB 1: In everyday use, choose the procedure-defining version you like more, of course.)

(NB 2: This discussion has not a lot to do with SRFI 5, whose claim that the proposed alternative syntax is suggested by the alternative version of define is apocryphal.)

[Marc Nieper-Wißkirchen]

John, will you provide us with some intermediate results, especially about the (size of the) set of voters so far? If I remember correctly, you did so during earlier ballots.

[John Cowan]

On Thu, Nov 18, 2021 at 5:32 AM Marc Nieper-Wißkirchen <marc....@gmail.com> wrote:

John, will you provide us with some intermediate results, especially about the (size of the) set of voters so far? If I remember correctly, you did so during earlier ballots.

I usually post after I have voted, which I generally do around the midpoint of the election, but as that collides with Christmas it will probably be early in January.

In the meantime, if you look at the ballot form at <https://docs.google.com/forms/d/1FEovNGbLYWz2yd6-UrbSCjFwAQ6fynrStLQyyC6YYDE>, the number of votes appears in the "Responses" tab: it is currently 28.  One person voted twice (which is legitimate; all but the last ballot is manually ignored), but one person voted by email and has not yet been recorded, so that cancels out.

If you click on the Responses tab, you will see a series of pie charts representing the ballot questions.  The shape of the pie slices should be ignored: hover over the Yes and No slices to see the actual number of votes cast.

[Marc Nieper-Wißkirchen]

Thanks for the quick response, John. Unfortunately, I can't find a "Responses" tab when I open the form. Am I doing something wrong or won't it work for me because I have no editing rights for the form?

--
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_TWOKtnkSLk23Cb9CUCAVVw_E%2BdBPcoaxrWBvx_9-wTvg%40mail.gmail.com.

[John Cowan]

On Thu, Nov 18, 2021 at 3:07 PM Marc Nieper-Wißkirchen <marc....@gmail.com> wrote:

Thanks for the quick response, John. Unfortunately, I can't find a "Responses" tab when I open the form. Am I doing something wrong or won't it work for me because I have no editing rights for the form?

That's probably right.  Well, I'll give more detail later.