New draft (#2) of SRFI 255: Restarting conditions
Arthur A. Gleckler
(17 Sep 2024 18:56 UTC)
|
||
(missing)
|
||
(missing)
|
||
(missing)
|
||
(missing)
|
||
(missing)
|
||
(missing)
|
||
(missing)
|
||
(missing)
|
||
Re: New draft (#2) of SRFI 255: Restarting conditions Wolfgang Corcoran-Mathe (19 Sep 2024 17:37 UTC)
|
On 2024-09-19 08:24 +0200, Marc Nieper-Wißkirchen wrote: > Am Mi., 18. Sept. 2024 um 23:33 Uhr schrieb Arthur A. Gleckler < > xxxxxx@speechcode.com>: > > > On Wed, Sep 18, 2024 at 12:45 PM Marc Nieper-Wißkirchen < > > xxxxxx@gmail.com> wrote: > > > > > >> Semantically, it makes more sense to have the inner parens removed. The > >> reason is that the embedded definition is not independent but is being > >> parsed by "restartable" ("define" becomes an auxiliary keyword). Wrapping > >> it in parantheses so that it looks like an ordinary "define" form is > >> misleading. > >> > > > > > >> Syntactically, they are just superfluous noise. > >> > > > > Then you could drop define entirely. Or change the form to > > define-restably or restartable-define. That makes it clearer that a > > definition is being made. > > > > It makes sense to "wrap" also bare lambdas and case-lambda (and possibly > other expressions like named let) in "restartable". If every such instance > defines a new keyword, we end up with several unnecessary exports compared > to the version with one keyword. This is exaggerating a bit. We don’t need to multiply restartable-foo forms arbitrarily. It makes sense to me to have one form for restartable procedure definitions, and one for procedure-valued expressions. (I’m not sure what restartable semantics would mean for a let, unless it’s named let you mean.) At the very least this would be a win for clarity. As Arthur says, it should be clear when a form expands to a definition. > There is also a technical reason why this wouldn't be a good idea. A later > version of SRFI 255 could make use of identifier properties. The > "restartable" macro would check the property on the decorated keyword and > would use that information to act accordingly. This way, the mechanism can > become extensible. I’m curious about how this would look, although I don’t want SRFI 255 to depend on identifier properties. > PS Doesn't this discussion belong to the SRFI 255 mailing list? CC’ing to the 255 list. -- Wolfgang Corcoran-Mathe <xxxxxx@sigwinch.xyz>