> 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
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
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
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
>
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
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
6 matches
Mail list logo
