Rules with parameters

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Rules with parameters

jqno
Hi,

I found something strange. I'm not sure if this is actually a bug, or if I'm just using parboiled for Scala incorrectly.

Here's a gist that demonstrates my problem: https://gist.github.com/2209368
Of course, in my "real" code, the rules are more complex than this.

Basically, I have a method that defines a rule to match a certain amount of text, where the parameter is the number of characters that it should match.

If I wrap the rule in a rule {} block, AND if I use it more than once with different parameters, it doesn't match my input. If I remove the rule {} block, it does work; and if I change the rule and the input so that the places parameter has the same value twice, it also works.

I don't understand why this happens. Of course I can remove the rule {} block, but I'm not sure if I should? I would break the convention that all rules are wrapped in such a block.
On the other hand, it is the only rule with a parameter, which might be a significant difference too.


Basically, what I want to know is, what's the best way to handle rules that have a parameter, like this one?


Regards,
Jan
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Rules with parameters

mathias
Administrator
Jan,

sorry for being a little late with my reply, I'm incredibly swamped with work right now.
I've quickly looked into this issue and I can confirm it's indeed a bug.
Just created an issue for it: https://github.com/sirthias/parboiled/issues/40

The cause is that the code currently uses the rule methods StackTraceElement as a key into the rule cache.
However, the StackTraceElement only contains the rule methods static features like name, line number and so on, not the actual invocation arguments if there are any.
As a result the `rule` wrapper caches the rule created by the first call to your `Text` rule (the one with argument `4`) and erroneously returns the cached instance on the `Text(3)` call.
Clearly this needs to be fixed.
As a work-around you can leave away the `rule` wrapper, which "disables" rule caching, automatic rule naming and recursion protection for this rule.

Thanks for the report!

Cheers,
Mathias

---
[hidden email]
http://www.parboiled.org

On 29.03.2012, at 15:09, jqno [via parboiled users] wrote:

> Hi,
>
> I found something strange. I'm not sure if this is actually a bug, or if I'm just using parboiled for Scala incorrectly.
>
> Here's a gist that demonstrates my problem: https://gist.github.com/2209368
> Of course, in my "real" code, the rules are more complex than this.
>
> Basically, I have a method that defines a rule to match a certain amount of text, where the parameter is the number of characters that it should match.
>
> If I wrap the rule in a rule {} block, AND if I use it more than once with different parameters, it doesn't match my input. If I remove the rule {} block, it does work; and if I change the rule and the input so that the places parameter has the same value twice, it also works.
>
> I don't understand why this happens. Of course I can remove the rule {} block, but I'm not sure if I should? I would break the convention that all rules are wrapped in such a block.
> On the other hand, it is the only rule with a parameter, which might be a significant difference too.
>
>
> Basically, what I want to know is, what's the best way to handle rules that have a parameter, like this one?
>
>
> Regards,
> Jan
>
>
> If you reply to this email, your message will be added to the discussion below:
> http://users.parboiled.org/Rules-with-parameters-tp3867638p3867638.html
> To start a new topic under parboiled users, email [hidden email]
> To unsubscribe from parboiled users, click here.
> NAML

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Rules with parameters

jqno
Hi Mathias,

About your reaction being late: no worries! I really appreciate the work you're doing here.

And thanks for the explanation. I'll omit the wrapper on these rules for now.


Regards,
Jan
Loading...