New draft (#7) of SRFI 204: Wright-Cartwright-Shinn Pattern Matcher Arthur A. Gleckler (04 Sep 2020 17:45 UTC)
Re: New draft (#7) of SRFI 204: Wright-Cartwright-Shinn Pattern Matcher Marc Nieper-Wißkirchen (05 Sep 2020 15:06 UTC)
Re: New draft (#7) of SRFI 204: Wright-Cartwright-Shinn Pattern Matcher Marc Nieper-Wißkirchen (05 Sep 2020 19:27 UTC)
Re: New draft (#7) of SRFI 204: Wright-Cartwright-Shinn Pattern Matcher Marc Nieper-Wißkirchen (08 Sep 2020 17:49 UTC)
Re: New draft (#7) of SRFI 204: Wright-Cartwright-Shinn Pattern Matcher Marc Nieper-Wißkirchen (08 Sep 2020 16:00 UTC)

Re: New draft (#7) of SRFI 204: Wright-Cartwright-Shinn Pattern Matcher Marc Nieper-Wißkirchen 08 Sep 2020 17:48 UTC

Am Di., 8. Sept. 2020 um 19:35 Uhr schrieb Felix Thibault
<xxxxxx@gmail.com>:

> Right now, I want to focus on getting the spec in shape so it meets the criteria you and Marc laid out. I was just re-reading the "non-linear and ellipsis patterns" thread and it looks like Marc and Alex were discussing making repeated patterns optional, at least in certain sections so I could include something like:
>
>> Non-linear pattern clauses involving repetition
>>
>> ((a b ... a) 'ok)
>>
>> can be expressed without repetition using failure
>>
>> ((a b ... c)) (=> fail) (if (equal? a c) 'ok (fail)))
>>
>> so repition can be considered an optional feature.

If you include something like this, make sure to separate the
normative from the non-normative. E.g:

Spec: ... It is implementation-defined whether repeated pattern
variables cause a syntax error or not. If they don't, their meaning is
as follows ...

Rationale: While the original Wright matcher only allowed linear
patterns (no repeated pattern variables), the popular implementation
by Alex Shinn does. Non-linear pattern variables are truly optional
because they can be avoided as in the following example. Note that
version with solely linear patterns does allow to use arbitrary
equality predicates and not just equal?.

PS Looking into Alex's implementation, I just noticed that my earlier code

(... (=> failure) (unless ... (failure) ...)

is not correct because (failure) is not like a continuation (in the
sense that it does not return). Instead, it evaluates to the value of
the remaining clauses of the match expression if I am not mistaken.
The spec, however, seems to imply that (failure) works more like a
goto, which seems to be useful. To implement this easily, one can add
an escaping continuation to the matcher code.