Le 18/12/2013 11:15, Nicolas Anquetil a écrit :
ben there is nothing magic about PPCompositeParser, it is a parser like
all the other one
and if you call rules without consuming any input + have a loop in the
rule calls, then there will be a infinite loop
Yes and no. Some parsers can't handle left-recursion in rules (petit
parser? LL parsers can't), some parsers don't have any problem with left
recursion (LR parsers like SmaCC).
The only thing is that most (all) grammars for programming languages are
left recursives...
The idea is PetitParser tries to consume something by
calling a rule, if
this rules calls another one then it tries it etc ...
As long as no rule consume anything, it will just continue calling them
and you will have an infinite rule
So this is an issue.
Now about the other 2 rules that are the same, this is strange too.
You normally don't do that in a parser
In that particluar case, a parser would be unable to make a difference
between choosing ClassType or InterfaceType, since both are defined as
exactly the same production.
Then, depending on the Parser, it would select only the first, or
complain that it can't choose between both :)
Thierry
nicolas
On 12/17/2013 11:55 PM, Benjamin AREZKI wrote:
No it's not a mistake, both have exact same
definition but the not the
same and it's useful because I use those rules in other parts of the
grammar and it helps for the comprehension. Yeah I think it create an
infinite recursion but normally I can't have this problem with
PPCompositeParser ..
2013/12/17 Nicolas Anquetil <Nicolas.Anquetil(a)inria.fr
<mailto:Nicolas.Anquetil@inria.fr>>
well one thing I can see is that there is no way to decide between
ClassType and InterfaceType
because both have the exact same definition (or is it a mistake in
the mail?)
I wouldn't think this can crash petitparser, I would have think it
would just always go for classtype and never interfacetype
But this sure looks strange. Why would you need both? if they are
the same?
Another thing I am spotting is that there is a kind of recursive loop:
ClassOrInterfaceType > ClassType > TypeDeclSpecifier >
ClassOrInterfaceType
So may be it is entering an infinite recursion always following
this same path ... ?
In a typical grammar, you would need something before the
recursive call to make sure some token is consumed at some point
otherwise it can just call rules recursively without consuming any
otken in the input stream
nicolas
On 12/17/2013 11:32 PM, Benjamin AREZKI wrote:
Unfortunately no, I am actually in an other
university ... Do you
have any idea about this problem ?
2013/12/17 Uko2 [via Smalltalk] <[hidden email]
<http://user/SendEmail.jtp?type=node&node=4730847&i=0>>
Can we meet in next 3 days at Inria?
On 17 Dec 2013, at 23:22, Benjamin AREZKI <[hidden email]
<http://user/SendEmail.jtp?type=node&node=4730845&i=0>> wrote:
Hi,
To explain my problem I will take this sample , my parser is
a PPCompositeParser.
ClassOrInterfaceType: ClassType / InterfaceType
ClassType:TypeDeclSpecifier, TypeArgumentsopt
InterfaceType: TypeDeclSpecifier, TypeArgumentsopt
TypeDeclSpecifier: TypeName / ClassOrInterfaceType . Identifier
TypeName: Identifier /TypeName . Identifier
Ok, so Identifier works well, no problem but when I tested
typeDeclSpecifier, I lost the contral of Pharo but I don't
know why because I use a PPCompositeParser. For the moment
I use some tricks but I would like it works normally.
Thanks for your help.
_______________________________________________
Moose-dev mailing list
[hidden email]
<http://user/SendEmail.jtp?type=node&node=4730845&i=1>
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
_______________________________________________
Moose-dev mailing list
[hidden email]
<http://user/SendEmail.jtp?type=node&node=4730845&i=2>
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
------------------------------------------------------------------------
If you reply to this email, your message will be added to the
discussion below:
http://forum.world.st/PetitParser-PPCompositeParser-Infinite-loop-tp4730844…
To start a new topic under Moose, email [hidden email]
<http://user/SendEmail.jtp?type=node&node=4730847&i=1>
To unsubscribe from Smalltalk, click here.
NAML
<http://forum.world.st/template/NamlServlet.jtp?macro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespace&breadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml>
------------------------------------------------------------------------
View this message in context: Re: PetitParser PPCompositeParser,
Infinite loop ?
<http://forum.world.st/PetitParser-PPCompositeParser-Infinite-loop-tp4730844p4730847.html>
Sent from the Moose mailing list archive
<http://forum.world.st/Moose-f1310756.html> at
Nabble.com.
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch <mailto:Moose-dev@iam.unibe.ch>
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
--
Nicolas Anquetil -- RMod research team (Inria)
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch <mailto:Moose-dev@iam.unibe.ch>
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
--
Nicolas Anquetil -- RMod research team (Inria)
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
--
Thierry Goubier
CEA list
Laboratoire des Fondations des Systèmes Temps Réel Embarqués
91191 Gif sur Yvette Cedex
France
Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95