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