Working Group 2 is pleased to announce the first draft of the second part of the R7RS-Large Foundations, the "Procedural Fascicle". This draft encompasses the familiar block programming forms, such as lambda, let, if, or, and set!.
The biggest new feature is the ability to mix definitions and expressions in bodies, such as the body of a lambda. For example, the following is now valid:
We welcome any and all comments on the draft. Anyone can comment by
* Filing an issue on the R7RS-Large issue tracker <https://codeberg.org/scheme/r7rs>
* Sending mail to the Working Group 2 mailing list <https://groups.google.com/g/scheme-reports-wg2> (you do not need a google account)
* Sending mail to the Scheme Reports mailing list <https://scheme-reports.simplelists.com/> and <scheme-reports@scheme-reports.org>
* Sending mail to the corresponding member Peter McGoron at <code@mcgoron.com>. I will forward your comment to the public issue tracker. Please indicate if you wish to be anonymous.
I hope you don't take this question the wrong way: why is R7RS large taking so long? Is there a consensus problem or just a lack of resources? If it's the latter, is there any way a random scheme dabbler can help?
The committee needs to think long and hard about which features to propose in each docket and what those features should look like, a lot of discussion needs to take place in order to get each docket formed, then the wider public needs to get its chance to weigh in, and then a voting round needs to be held. That process may need to happen several times for a docket, and there's a bunch of dockets planned before R7RSL will be done.
Think of it this way: if the committee was more cavalier about this we'd have the familiar situation where we start with a great language and then every update worsens it until we end up with an abominable horror show.
What tmtvl said is correct. However, it is also a resource problem. R7RS Large is a volunteer driven effort where if people stop having the time to contribute due to personal reasons, things slow down.
> If it's the latter, is there any way a random scheme dabbler can help?
Giving your comments on drafts, issues[1], and draft SRFIs is always welcome. The decisions of the Working Group are more complete when we hear more voices.
Delimited continuation machinery? It seems like call/cc is becoming quite a bit more acknowledged as being overkill while the more restricted shift/reset, control/prompt, F-operator stuff, etc. compose better.
We plan to add delimited continuations in a later draft. What the actual API will look like is still in question. There is a proposal for a large API, like Racket's <https://srfi.schemers.org/srfi-226/> and a minimalistic API <https://srfi.schemers.org/srfi-248/> similar-ish to Guile's.
Hello everyone.
Working Group 2 is pleased to announce the first draft of the second part of the R7RS-Large Foundations, the "Procedural Fascicle". This draft encompasses the familiar block programming forms, such as lambda, let, if, or, and set!.
The draft is available here:
https://r7rs.org/large/fascicles/proc/
The biggest new feature is the ability to mix definitions and expressions in bodies, such as the body of a lambda. For example, the following is now valid:
We welcome any and all comments on the draft. Anyone can comment by* Filing an issue on the R7RS-Large issue tracker <https://codeberg.org/scheme/r7rs> * Sending mail to the Working Group 2 mailing list <https://groups.google.com/g/scheme-reports-wg2> (you do not need a google account) * Sending mail to the Scheme Reports mailing list <https://scheme-reports.simplelists.com/> and <scheme-reports@scheme-reports.org> * Sending mail to the corresponding member Peter McGoron at <code@mcgoron.com>. I will forward your comment to the public issue tracker. Please indicate if you wish to be anonymous.
> The biggest new feature is the ability to mix definitions and expressions in bodies, such as the body of a lambda.
Looks like Rust. It helps macros a lot
I hope you don't take this question the wrong way: why is R7RS large taking so long? Is there a consensus problem or just a lack of resources? If it's the latter, is there any way a random scheme dabbler can help?
The committee needs to think long and hard about which features to propose in each docket and what those features should look like, a lot of discussion needs to take place in order to get each docket formed, then the wider public needs to get its chance to weigh in, and then a voting round needs to be held. That process may need to happen several times for a docket, and there's a bunch of dockets planned before R7RSL will be done.
Think of it this way: if the committee was more cavalier about this we'd have the familiar situation where we start with a great language and then every update worsens it until we end up with an abominable horror show.
What tmtvl said is correct. However, it is also a resource problem. R7RS Large is a volunteer driven effort where if people stop having the time to contribute due to personal reasons, things slow down.
> If it's the latter, is there any way a random scheme dabbler can help?
Giving your comments on drafts, issues[1], and draft SRFIs is always welcome. The decisions of the Working Group are more complete when we hear more voices.
[1]: https://codeberg.org/scheme/r7rs/issues
Delimited continuation machinery? It seems like call/cc is becoming quite a bit more acknowledged as being overkill while the more restricted shift/reset, control/prompt, F-operator stuff, etc. compose better.
We plan to add delimited continuations in a later draft. What the actual API will look like is still in question. There is a proposal for a large API, like Racket's <https://srfi.schemers.org/srfi-226/> and a minimalistic API <https://srfi.schemers.org/srfi-248/> similar-ish to Guile's.