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)

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>