New pre-SRFI: Extensible pattern matcher Daphne Preston-Kendal (18 Oct 2023 12:26 UTC)
Re: New pre-SRFI: Extensible pattern matcher Jeronimo Pellegrini (18 Oct 2023 12:33 UTC)
Re: New pre-SRFI: Extensible pattern matcher Daphne Preston-Kendal (18 Oct 2023 12:37 UTC)

Re: New pre-SRFI: Extensible pattern matcher Jeronimo Pellegrini 18 Oct 2023 12:32 UTC

Hello!

Isn't a '(match' missing in In this example (the one for "or")?

(define (arithmetic-operation x)
   ((list (and operator (or '+ '- '* '/))
          (and operands (? number?)) ...)
    (list operator operands)))

Between the first and second lines?

J.

On 2023-10-18 09:26, Daphne Preston-Kendal wrote:
> Documentation:
> <http://dpk.io/temp/extensible-match/README>
>
> Implementation:
> <https://gitlab.com/dpk/presrfis/-/tree/extensible-match/extensible-match>
>
> As of writing (commit f6f13fe8), the implementation supports all
> documented features. However, it currently only runs in the (Chez
> Scheme) REPL and still hasn’t been sorted out into libraries with
> respect for phasing, etc.
>
> Before making this a full SRFI and giving it consideration for the R7RS
> Large Batteries, this is approximately the to-do list:
>
> - Gather feedback on the design at the pre-SRFI stage (hence this email
> ;-) )
> - Add support for unordered patterns so it’s possible to match things
> like sets, hash tables, etc.
> - Probably change away from syntax-case style fenders to providing an
> escape procedure to jump to the next matching clause. This would allow
> the code part of each match clause to be a full Scheme body rather than
> a single expression
> - Improve the implementation of sequence matching to be based on a fast
> iterator protocol instead of bare lists, to make matching non-list
> sequencing types more efficient by not requiring them to be converted
> into a list first — possibly do this in conjunction with the next item
> (second design principle)
> - Change the core of the implementation from consing up a list of
> matched variable values to using a mix of local variable bindings and
> multiple-value return to store matched variable values, to use
> efficient stack/register storage as much as possible and the heap as
> little as possible (second design principle)
>
>
> Daphne