syntax-case as a pattern matcher Marc Nieper-Wißkirchen (30 Jun 2020 13:03 UTC)
Re: syntax-case as a pattern matcher Panicz Maciej Godek (30 Jun 2020 17:45 UTC)
Re: syntax-case as a pattern matcher Marc Nieper-Wißkirchen (30 Jun 2020 17:50 UTC)
Re: syntax-case as a pattern matcher Shiro Kawai (30 Jun 2020 19:43 UTC)
Re: syntax-case as a pattern matcher Shiro Kawai (30 Jun 2020 19:47 UTC)
Re: syntax-case as a pattern matcher Marc Nieper-Wißkirchen (30 Jun 2020 20:46 UTC)
Re: syntax-case as a pattern matcher Alex Shinn (30 Jun 2020 23:36 UTC)
Re: syntax-case as a pattern matcher Marc Nieper-Wißkirchen (01 Jul 2020 08:50 UTC)
Re: syntax-case as a pattern matcher Marc Nieper-Wißkirchen (04 Oct 2020 08:50 UTC)

Re: syntax-case as a pattern matcher Marc Nieper-Wißkirchen 04 Oct 2020 08:50 UTC

Speaking of SRFI 115, this is actually a very good use case for
`syntax-case' compared to match. In SRFI 115, we have the procedure

(regexp re)

and the syntax

(rx sre ...)

that is equivalent to (regexp `(: sre ...)).

Of course, the former can also be implemented in terms of the latter
through (define (regexp re) (rx ,re)) so in this case, we are left
with implementing the latter. The advantage of the syntactic form is
that the <sre> ... still carry contextual information, including
source code location information so that sre syntax errors can be
displayed in a meaningful way. To make this work, we want to write our
matcher using syntax-case (if available) and not match:

(define-syntax rx
  (lambda (stx)
    (syntax-case stx ()
      ((_ sre ...) (compile-rx #'(: sre ...)))
      (_ (syntax-violation 'rx "ill-formed rx form" stx)))))

(define (compile-rx sre)
  (syntax-case sre ()
    ((op . rest)
     (identifier=? #'op)
     (case (syntax->datum #'op)
       ((*) (compile-rx-* sre))
       ...
       (else => (lambda (sym) (syntax-violation 'rx (format "unknown
operator ‘~a’ in sre" sym) sre #'op)))))
    (op
     (identifier=? #'op)
     (case (syntax->datum #'op)
       ...))
    (_ (syntax-violation 'rx "invalid sre" sre))))

Am Mi., 1. Juli 2020 um 10:49 Uhr schrieb Marc Nieper-Wißkirchen
<xxxxxx@nieper-wisskirchen.de>:
>
> Am Mi., 1. Juli 2020 um 01:36 Uhr schrieb Alex Shinn <xxxxxx@gmail.com>:
> >
> > On Wed, Jul 1, 2020 at 4:43 AM Shiro Kawai <xxxxxx@gmail.com> wrote:
> >>
> >> syntax-case can be used to match against a bare (unwrapped) expression, but pattern variables must be referenced within syntax expressions.  So you have to do (syntax->datum (syntax ...)) to substitute match, correct?  Using syntax-case for general pattern matching is doable, though it feels like re-adapting a tool created for another purpose.
> >
> >
> > As a comparison, we could consider SRFI 115 regular expressions as a general pattern matching library worth referencing.  In fact, it is designed for arbitrary strings which makes it more general.  To use with Scheme datum you do need to encode with write/read, but this is analogous to encoding via datum->syntax/syntax->datum when matching with syntax-case.
>
> There's some truth in the comparison so using syntax-case for things
> not being source code looks like using the wrong tool. But for that,
> it can be used outside macro transformers, which is what my initial
> objection to the formulation in SRFI 200 was about.
>
> But one can also consider the comparison with SRFI 115 lame.
> `datum->syntax' can be implemented in O(1), and `syntax->datum' only
> has to touch the non-constant parts of the template, so once packaged
> into a nice syntax that abstracts away the conversion procedures, it
> is actually quite efficient.
>
> But we should rather make the concept of a syntax object parameterizable.
>
> Marc