> and I would suggest that we implement the racket matcher completely with
syntax parse.
> I usually argue for clarity of code over speed. BUT we must pay
attention to performance, especially widely used features.
> Have you measure the performance of the two versions? Indeed you really
need
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
2012-05-12 09:01
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
On 05/11/2012 07:45 AM, [email protected] wrote:
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-synt
On May 11, 2012, at 9:45 AM, [email protected] wrote:
> 1. Ported syntax-parse over to guile.
> 2. Implemented racket's match completely with the help of syntax parse.
This is really good to hear.
> Comments about 1.
>
> i propose instead to add syntax-class-set! and syntax-spl
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 al
6 matches
Mail list logo
