On 05/11/2012 06:45 AM, [email protected] 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
_________________________
Racket Developers list:
http://lists.racket-lang.org/dev
