Re: [racket-users] degenerate performance in syntax-parse
> The only issue is converting our mountain of code that uses the old syntax
> (more than 40,000 lines, if you can believe it).
I would suggest keeping the old syntax too via {~or #:blend {~and blend-stx
blend}}, but making it log a warning when (attribute blend-stx) is true,
printing (syntax-source blend-stx) and (syntax-line blend-stx) and
(syntax-column blend-stx).
That will make it way easier to convert your old source. With a good backup and
a daring mood, you could even feed that to sed to make the change automatically
:) .
There was a talk by Jack Firth at racket-con about the idea of integrating
warnings to macros, and automatically suggesting or applying fixes. This seems
to be a good use-case for the idea.
--
You received this message because you are subscribed to the Google Groups
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to racket-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: [racket-users] degenerate performance in syntax-parse
On Monday, October 24, 2016 at 2:07:16 PM UTC-7, Ryan Culpepper wrote: > > It might make sense for syntax-parse to offer something like Redex's > `variable-not-otherwise-mentioned`, which would behave like you > expected. I think it would have to be a baked-in special case, but it > might be useful enough to justify that. > I'm trying using keywords (i.e. changing 'blend' to '#:blend'). It'll also help the readability of this DSL, since it's already quite Racket-like. The only issue is converting our mountain of code that uses the old syntax (more than 40,000 lines, if you can believe it). -- You received this message because you are subscribed to the Google Groups "Racket Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to racket-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [racket-users] degenerate performance in syntax-parse
On 10/24/2016 02:15 PM, Dan Liebgold wrote: On Sunday, October 23, 2016 at 1:14:56 PM UTC-7, Ryan Culpepper wrote: [...] 1. A term like `(a <- blend)` will match the first pattern and treat `blend` as a `remap:id`. If you don't want that to happen, there are two ways to prevent it. One is to define a syntax class like `id` that excludes all of the reserved words like `<-` and `blend` and use that for pattern variables like `remap`. The other is to reorder the patterns and use cut (~!): (pattern (source:id <- blend ~! remap:id extras:remap-entry-extra-params)) (pattern (source:id <- remap:id extras:remap-entry-extra-params)) This one is surprising. I thought that listing 'blend' as a datum-literal would prevent the more general 'remap:id from matching it. It might make sense for syntax-parse to offer something like Redex's `variable-not-otherwise-mentioned`, which would behave like you expected. I think it would have to be a baked-in special case, but it might be useful enough to justify that. I ran into the same issue recently when designing an(other) S-expression notation for SQL. Ryan -- You received this message because you are subscribed to the Google Groups "Racket Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to racket-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [racket-users] degenerate performance in syntax-parse
On Sunday, October 23, 2016 at 1:14:56 PM UTC-7, Ryan Culpepper wrote: > > > The easiest fix is to add the #:commit option to the `remap-entry` > syntax class. Then when `remap-entry` succeeds the first time, it throws > away the choice points it created, so the repeated pattern is never > considered. > Ok that makes sense and I hadn't realized it. Easy fix! [...] > > 1. A term like `(a <- blend)` will match the first pattern and treat > `blend` as a `remap:id`. If you don't want that to happen, there are two > ways to prevent it. One is to define a syntax class like `id` that > excludes all of the reserved words like `<-` and `blend` and use that > for pattern variables like `remap`. The other is to reorder the patterns > and use cut (~!): > >(pattern (source:id <- blend ~! remap:id > extras:remap-entry-extra-params)) >(pattern (source:id <- remap:id extras:remap-entry-extra-params)) > This one is surprising. I thought that listing 'blend' as a datum-literal would prevent the more general 'remap:id from matching it. It's easy to re-order the patterns, fortunately. > 2. `format-id` is useful for creating identifiers. > Ah, yes, awareness of 'format-id' is low among us here, I'll introduce it. > Ryan Thanks! -- You received this message because you are subscribed to the Google Groups "Racket Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to racket-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [racket-users] degenerate performance in syntax-parse
On 10/21/2016 05:50 PM, Dan Liebgold wrote: Hi all - In the process of putting together a somewhat complex application using syntax-parse, I discovered that when I specified a repeated pattern in a syntax-class (which was incorrect) AND I had a certain usage of the syntax transformer with an error, it would lead to degenerate performance (Racket would run out of memory or it would need to be killed. Please see this example and uncomment the last non-paren line to see it fall down: http://pasterack.org/pastes/50261 The problem is that the `remap-entry` syntax class can succeed in multiple ways because of the repeated pattern. So when you have a macro use like (m remap-entry-1 remap-entry-2 ... remap-entry-n bad) when parsing `bad` fails, syntax-parse backtracks and tries the other way of parsing all of the previous entries, so what should be a linear parse turns exponential. The easiest fix is to add the #:commit option to the `remap-entry` syntax class. Then when `remap-entry` succeeds the first time, it throws away the choice points it created, so the repeated pattern is never considered. It's usually reasonable to use #:commit with regular syntax classes (unless you're using syntax-parse to do logic programming). It's usually a bad idea to use it with splicing syntax classes, though, since it can lead to missed parses or bad error messages. Two other comments: 1. A term like `(a <- blend)` will match the first pattern and treat `blend` as a `remap:id`. If you don't want that to happen, there are two ways to prevent it. One is to define a syntax class like `id` that excludes all of the reserved words like `<-` and `blend` and use that for pattern variables like `remap`. The other is to reorder the patterns and use cut (~!): (pattern (source:id <- blend ~! remap:id extras:remap-entry-extra-params)) (pattern (source:id <- remap:id extras:remap-entry-extra-params)) 2. `format-id` is useful for creating identifiers. Ryan -- You received this message because you are subscribed to the Google Groups "Racket Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to racket-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[racket-users] degenerate performance in syntax-parse
Hi all - In the process of putting together a somewhat complex application using syntax-parse, I discovered that when I specified a repeated pattern in a syntax-class (which was incorrect) AND I had a certain usage of the syntax transformer with an error, it would lead to degenerate performance (Racket would run out of memory or it would need to be killed. Please see this example and uncomment the last non-paren line to see it fall down: http://pasterack.org/pastes/50261 Thanks, Dan -- You received this message because you are subscribed to the Google Groups "Racket Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to racket-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
