Having trouble viewing or submitting this form? | |
| |
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 |
This content is neither created nor endorsed by Google.
Report Abuse - Terms of Service - Additional Terms |
Create your own Google Form |
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.
To view this discussion on the web visit https://groups.google.com/d/msgid/scheme-reports-wg2/CAEYrNrRAtDnf2PU5S3mF4zYOZ7_%2ByuWwWS9J7zDjsupw7%2BrjOQ%40mail.gmail.com.
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).
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.
--
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.
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 ;-)
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.)
But, as announced earlier, I will abstain.
And as I believe I said earlier, no one is being paid to vote.
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.
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.
>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
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.
--
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.
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?
SRFI 5 sounds
really bad to me for instance, due to the strange use of dot-notation.
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.
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.
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.
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)
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.
What's the point of this? I don't see any advantage but the risk of diverging code bases.
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.
> 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.
> 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.
> 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.
> 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.
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.
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.
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.
--
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.
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?