[racket-dev] match syntax-parse

On 05/11/2012 06:45 AM, stefan.israelsson at se.abb.com wrote:
> Hi,
>
> I have done two interseting things.
>
> 1. Ported syntax-parse over to guile.
> 2. Implemented racket's match completely with the help of syntax parse.
>
> Comments about 1.
>
> I found that the lack of possibility to define two syntax classes that
> referese to each other inferior to what
> can be done although I understand the choice of to do this and if you
> define one hugh syntax class and use
> syntax class parameters you will be able to implement any feature still
> but at the drawback that one need
> to define one hugh syntax class.

I don't understand your comment. Racket supports mutually recursive 
syntax classes. Here's a little toy example:

#lang racket
(require (for-syntax syntax/parse))

(begin-for-syntax
   (define-syntax-class x
     (pattern i:id
              #:with (flat ...) #'(i))
     (pattern l:xlist
              #:with (flat ...) #'(l.flat ...)))
   (define-syntax-class xlist
     (pattern (a:x ...)
              #:with (flat ...) #'(a.flat ... ...))))

(define-syntax (m stx)
   (syntax-parse stx
     [(_ x:x)
      #'(quote (x.flat ...))]))

(m (a (b c) ((d) ((e)))))
;; => '(a b c d e)

> i propose instead to add syntax-class-set! and
> syntax-splicing-class-set! that has the following logic:
> 1. Compile all the meta data for the class as before
> 2. there has to be an already defined syntax class, the declaration,
> which has a logically identical set of meta data except for
> the parser function
> 3. If there is no syntax class defined, error about it
> 4. If there the interfaces miss-matches print out what is different.
> 5. if everything is ok then set! the old named parser to the new parser
>
> With this logic one can have mutually recursively defined syntax classes
> in different files a boon if I have a say.

Ah, I see now. You want mutual recursion across modules, which Racket 
doesn't support in general.

One way to do this with Racket's syntax-parse is to define the two 
syntax classes as thin wrappers around reified syntax classes (see the 
syntax/parse/experimental/reflect module and ~reflect). Then you can 
create procedures that mutate the variables holding the reified syntax 
classes.

Those are the mechanics. I'll see about adding more syntactic support 
around it, so that you don't have to do things like declare attributes 
in multiple places. But I'd prefer not to add mutability to syntax 
classes themselves.

> Also I have this working in a test case (the match parser)
>
> So theory looks kind of nice what's the problems!
>
> 2.
> I must say that syntax-parse rocks and I would suggest that we implement
> the racket matcher completely with syntax parse.
> To see how it can look like consider looking at the file at,
>
> http://gitorious.org/guile-syntax-parse/guile-syntax-parse/blobs/master/compat/racket/match.scm
>
>
> Please look at this tomorrow CET I have a new version ready soon with
> interesting addons.
>
> The benefit: is much more hackable codebase then the current match
> code-base, it's smaller for one thing.
> The drawback: one must change syntax-parse to not use match code. I
> would say that this is not
> that hugh investment though. And that one introduces buggs.

As Neil mentioned, syntax-parse does not use racket/match; it has its 
own separate (far simpler) implementation in syntax/parse/private/minimatch.

> Then a final question:
> Should we consider implementing syntax-parse with the help of syntax-parse?

A few parts actually are. But for the syntax-parse core, figuring out 
how to bootstrap it seems like more trouble than it's worth. (Unless, of 
course, the rest of Racket goes that way...)

--

Thanks for the feedback, and thanks for the work you've done porting 
syntax-parse to Guile. It's great to hear that other people have found 
it useful enough to port to other systems.

Ryan