<tt>> 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)</tt> 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. <tt>> As Neil mentioned, syntax-parse does not use racket/match; it has its > own separate (far simpler) implementation in syntax/parse/private/minimatch. </tt> <tt>Yes now I remembered that this is the case, I had used guiles (ice-9 match) for those in the guile version.</tt> <tt>then it can makes more sense to implement the matcher with an extensive use of syntax-parse.</tt> <tt>> 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.</tt> <tt>cool, syntax-parse in guile is kind of heavy right now and splitting the parser into mutual files can save</tt> <tt>some dev pain. (On the other hand I should fix the code to be faster)</tt> <tt>> 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...)</tt> <tt> It's just an idea. I think it would be fun to try it out though.</tt> <tt>/Stefan</tt> <table width=100%> <tr valign=top> <td width=40%>Ryan Culpepper <ryan@cs.utah.edu> 2012-05-12 09:01 <td width=59%> <table width=100%> <tr valign=top> <td> <div align=right>To</div> <td>Stefan Israelsson/SECRC/ABB@ABB_SECRC <tr valign=top> <td> <div align=right>cc</div> <td>dev@racket-lang.org <tr valign=top> <td> <div align=right>Subject</div> <td>Re: [racket-dev] match syntax-parse</table> <table> <tr valign=top> <td> <td></table> </table> <tt>On 05/11/2012 06:45 AM, stefan.israelsson@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, > > </tt><a href="http://gitorious.org/guile-syntax-parse/guile-syntax-parse/blobs/master/compat/racket/match.scm"><tt>http://gitorious.org/guile-syntax-parse/guile-syntax-parse/blobs/master/compat/racket/match.scm</tt></a><tt> > > > 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 </tt>