this registration thing is nonsense. Anyone who knows about the existence of the voting ballots clearly already has an interest in Scheme. If the purpose is to prevent double-votes from some people, it's all too easy to make up a bunch of introductory emails, so it doesn't prevent that either.
Having said that, I've been working on an R7RS Small implementation in my free time for a while now, and it's slowly nearing to completion: https://gitlab.com/Oxyd/insider-scheme
this registration thing is nonsense. Anyone who knows about the existence of the voting ballots clearly already has an interest in Scheme. If the purpose is to prevent double-votes from some people, it's all too easy to make up a bunch of introductory emails, so it doesn't prevent that either.
this registration thing is nonsense. Anyone who knows about the existence of the voting ballots clearly already has an interest in Scheme. If the purpose is to prevent double-votes from some people, it's all too easy to make up a bunch of introductory emails, so it doesn't prevent that either.I can understand your skepticism, but it would be better if you expressed it politely.
I can understand your skepticism, but it would be better if you expressed it politely.I did. If you consider disagreement impolite, then we'll have a hard time with each other.
--
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/CALnw4LJLGA2m%2BMqSHytDjGURNEtiw_pg-1J_H5F31BqbLKCRtw%40mail.gmail.com.
I would advise not to overrate it. In one social culture, "nonsense" is understood as rude; in a different social culture, "nonsense" is understood as refreshingly frank.
We all have different social-cultural backgrounds and email is a bad medium anyway when compared to face time, so let's try not to read too much between the lines (as hard as it is).
especially about the fact that many distinct, detailed, and intermediate decisions are based on an upwardly-open, ever-changing body of voters most of who are not directly involved in envisioning, crafting, or discussing the specifications and who are not united by a common vision of where the language should head.
especially about the fact that many distinct, detailed, and intermediate decisions are based on an upwardly-open, ever-changing body of voters most of who are not directly involved in envisioning, crafting, or discussing the specifications and who are not united by a common vision of where the language should head.I don't wish to restart that discussion, but I will say that to me this description is more appropriate to a design-from-scratch committee than to a ratification committee, which is what WG2 is.
Marc Nieper-Wißkirchen <marc....@gmail.com> writes:
> That said, my vision is that of a committee of committed members that
> gets initially input from the Scheme community,
This sounds like the SRFI process, which is an important input to R7RS
large.
> then develops a conception based on this input and based on what's
> already there, crafts a coherent standard draft to be ratified in
> total,
This sounds like what we’re trying to do right now, if I understand it
right.
> and finally submits it to a ratification committee (which can be the
> whole Scheme community). Optimally, not a single draft but variations
> of a draft (e.g. in terms of the number of mandatory features) are
> submitted so that the ratification committee has a choice. The
> important point is that each of the submitted drafts in itself would
> be coherent.
I guess this is what will happen when it comes to adoption of R7RS
large. I don’t see a structure for this part yet.
On Mon, Dec 6, 2021 at 9:29 AM Dr. Arne Babenhauserheide <arne...@web.de> wrote:Marc Nieper-Wißkirchen <marc....@gmail.com> writes:
> That said, my vision is that of a committee of committed members that
> gets initially input from the Scheme community,
This sounds like the SRFI process, which is an important input to R7RS
large.Indeed, almost all the planned components of R7RS-large are either SRFIs or parts of R6RS. The only exception so far is explicit renaming.> then develops a conception based on this input and based on what's
> already there, crafts a coherent standard draft to be ratified in
> total,
This sounds like what we’re trying to do right now, if I understand it
right.It depends on what "coherent" means. If it means "100% consistent", then it isn't going to happen. The R7RS-large process has been going on for 12 years now, and the SRFI process on which it is based for twice as long. The volume of technical prose already voted in is huge, bigger than any standard I know of except CL, and will probably grow to be bigger than CL.
> and finally submits it to a ratification committee (which can be the
> whole Scheme community). Optimally, not a single draft but variations
> of a draft (e.g. in terms of the number of mandatory features) are
> submitted so that the ratification committee has a choice. The
> important point is that each of the submitted drafts in itself would
> be coherent.
I guess this is what will happen when it comes to adoption of R7RS
large. I don’t see a structure for this part yet.I plan to have a *minimal* cleanup phase when we get to the end, but not to have a final ratification pass. What is voted for now goes into the standard. As for multiple "coherent" drafts, the community barely has the spoons (<https://en.wikipedia.org/wiki/Spoon_theory>) to manage a single, admittedly imperfect, draft.
100% consistent is an ideal, which is never going to happen in practice. Replace this with "mostly consistent". And that is not ensured by the SRFI process.
If it is just about size, R7RS-large will do well.