Email list hosting service & mailing list manager

Existing binding forms Wolfgang Corcoran-Mathe (03 Jul 2020 16:38 UTC)
Re: Existing binding forms Panicz Maciej Godek (03 Jul 2020 20:15 UTC)
Re: Existing binding forms Marc Nieper-Wißkirchen (03 Jul 2020 21:11 UTC)
Re: Existing binding forms Panicz Maciej Godek (04 Jul 2020 06:12 UTC)
Re: Existing binding forms Wolfgang Corcoran-Mathe (04 Jul 2020 00:12 UTC)
Re: Existing binding forms Panicz Maciej Godek (04 Jul 2020 06:32 UTC)
Re: Existing binding forms Wolfgang Corcoran-Mathe (04 Jul 2020 13:39 UTC)

Re: Existing binding forms Wolfgang Corcoran-Mathe 04 Jul 2020 00:11 UTC

On 2020-07-03 22:14 +0200, Panicz Maciej Godek wrote:
> pt., 3 lip 2020 o 18:38 Wolfgang Corcoran-Mathe <xxxxxx@sigwinch.xyz>
> napisał(a):
>
> > I think this SRFI could avoid a great deal of confusion and
> > implementation difficulty by specifying separate pattern-matching
> > binding forms, instead of extending Scheme's core forms.
> >
> As to alleged implementation difficulty, I have implemented
> these extensions for two implementations of Scheme, and it wasn't very
> difficult.

The difficulty I was alluding to was also mentioned by Marc below: the
inherent "all-or-nothing" problem with extensions to core forms.  Which
extensions do you implement, and how do you reconcile them?

> But if you're suggesting
> that SRFI-201 should propose e.g. "match-let" instead of "let", then it
> would
> no longer be an "extension to the core Scheme binding', or would it?

While it may not be "in the spirit of [this] proposal", I suggest
that it would be better to specify the better-known "match-" forms
for pattern matching.  These forms are documented in _Pattern Matching
For Scheme_ (Wright 1996), and, as far as I'm aware, have never been
described in a SRFI.

> > In addition, it says in the Rationale that "[the match-lambda, etc.]
> > forms usually do not take into account the ability of Scheme
> > procedures to return multiple values".  Wright's forms do, however;
> > he writes of match-let: "These forms are convenient for destructuring
> > the result of a function that returns multiple values" (p. 1)  I'd
> > suggest that the author amend the rationale to indicate how this
> > SRFI's approach to multiple values differs from that of Wright's
> > forms.
>
> As far as I know, the implementation provided by Alex Shinn
> does not support multiple values.

It turns out that neither do the forms described in Wright 1996.  His
comment, cited above, is in fact misleading--he doesn't provide a form
for matching multiple values, and clearly intends that "multiple values"
be returned as a list.  This isn't surprising, given the date of the
paper.  As an aside, I doubt there'd be any difficulty in providing a
match-let-values form.

--
Wolfgang Corcoran-Mathe  <xxxxxx@sigwinch.xyz>

"Computer science is no more about computers than astronomy is
about telescopes." --pseudo-Dijkstra