<font size=2 face="sans-serif">Hi,</font>
<br>
<br><font size=2 face="sans-serif">I have done two interseting things.</font>
<br>
<br><font size=2 face="sans-serif">1. Ported syntax-parse over to guile.</font>
<br><font size=2 face="sans-serif">2. Implemented racket's match completely
with the help of syntax parse.</font>
<br>
<br><font size=2 face="sans-serif">Comments about 1.</font>
<br>
<br><font size=2 face="sans-serif">I found that the lack of possibility
to define two syntax classes that referese to each other inferior to what
</font>
<br><font size=2 face="sans-serif">can be done although I understand the
choice of to do this and if you define one hugh syntax class and use</font>
<br><font size=2 face="sans-serif">syntax class parameters you will be
able to implement any feature still but at the drawback that one need</font>
<br><font size=2 face="sans-serif">to define one hugh syntax class.</font>
<br>
<br><font size=2 face="sans-serif">i propose instead to add syntax-class-set!
and syntax-splicing-class-set! that has the following logic:</font>
<br><font size=2 face="sans-serif">1. Compile all the meta data for the
class as before</font>
<br><font size=2 face="sans-serif">2. there has to be an already defined
syntax class, the declaration, which has a logically identical set of meta
data except for </font>
<br><font size=2 face="sans-serif">&nbsp; &nbsp; the parser function</font>
<br><font size=2 face="sans-serif">3. If there is no syntax class defined,
error about it</font>
<br><font size=2 face="sans-serif">4. If there the interfaces miss-matches
print out what is different.</font>
<br><font size=2 face="sans-serif">5. if everything is ok then set! the
old named parser to the new parser</font>
<br>
<br><font size=2 face="sans-serif">With this logic one can have mutually
recursively defined syntax classes in different files a boon if I have
a say.</font>
<br>
<br><font size=2 face="sans-serif">Also I have this working in a test case
(the match parser)</font>
<br>
<br><font size=2 face="sans-serif">So theory looks kind of nice what's
the problems!</font>
<br>
<br><font size=2 face="sans-serif">2.</font>
<br><font size=2 face="sans-serif">I must say that syntax-parse rocks and
I would suggest that we implement the racket matcher completely with syntax
parse.</font>
<br><font size=2 face="sans-serif">To see how it can look like consider
looking at the file at,</font>
<br>
<br><font size=2 face="sans-serif">&nbsp; &nbsp;</font><a href="http://gitorious.org/guile-syntax-parse/guile-syntax-parse/blobs/master/compat/racket/match.scm"><font size=2 face="sans-serif">http://gitorious.org/guile-syntax-parse/guile-syntax-parse/blobs/master/compat/racket/match.scm</font></a>
<br>
<br><font size=2 face="sans-serif">Please look at this tomorrow CET I have
a new version ready soon with interesting addons.</font>
<br>
<br><font size=2 face="sans-serif">The benefit: is much more hackable codebase
then the current match code-base, it's smaller for one thing.</font>
<br><font size=2 face="sans-serif">The drawback: one must change syntax-parse
to not use match code. I would say that this is not</font>
<br><font size=2 face="sans-serif">that hugh investment though. And that
one introduces buggs.</font>
<br>
<br><font size=2 face="sans-serif">Then a final question:</font>
<br><font size=2 face="sans-serif">Should we consider implementing syntax-parse
with the help of syntax-parse?</font>
<br>
<br><font size=2 face="sans-serif">Have fun!</font>
<br><font size=2 face="sans-serif">/Stefan</font>
<br>
<br><font size=2 face="sans-serif"><br>
</font>