[racket-dev] match syntax-parse

> 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 think that this has to do with the evaluation structure in my 
implementation for guile. I think that I got it now, basically the 
syntax-classes
syntax structures in the racket version is defined before the parsers  are 
defined and inside those there is a check for syntax classes to be 
defined. 
Tricky I really need to talk with the guile dev's about  this in order to 
do the same as well for the guile version. I wrongly assumed that in order 
to get 
the interface you would need the interface of the used syntax classes.

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

Yes now I remembered that this is the case, I had used guiles (ice-9 
match) for those in the guile version.
then it can makes more sense to implement the matcher with an extensive 
use of syntax-parse.

> 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.

cool, syntax-parse in guile is kind of heavy right now and splitting the 
parser into mutual files can save
some dev pain. (On the other hand I should fix the code to be faster)

> 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...)

It's just an idea. I think it would be fun to try it out though.
/Stefan




Ryan Culpepper <ryan at cs.utah.edu> 
2012-05-12 09:01

To
Stefan Israelsson/SECRC/ABB at ABB_SECRC
cc
dev at racket-lang.org
Subject
Re: [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


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.racket-lang.org/dev/archive/attachments/20120514/0802a0dd/attachment-0001.html>