[antlr-interest] unknown parameters

John Ridgway john.ridgway at trincoll.edu
Wed Nov 7 09:16:21 PST 2007


On Nov 7, 2007, at 5:58 AM, Corno Schraverus wrote:

>> You cannot use parameters in predicates I am afraid, as when the
>> predicate
>> fragment is generated, the rule parameter is no longer in scope. I
>> suspect
>> that you are using the backtrack=true; option, which is where these
>> options
>> are coming from. If you wish to pass in such a parameter AND you wish
>> to use
>> backtrack=true, then you will need to use scopes rather than local
>> parameters.
>>
>> Overall it is probably best to get a grammar that does not use
>> backtrack=true, but using scopes will solve your issue with  
>> parameters.
>>
>> Jim
>>
> That's correct, I'm using the 'backtrack=true' option, I'm working  
> with the
> Java 1.5 grammar that Terence made for Antlr3. If he wasn't able to  
> create a
> grammar without backtracking, I'm very much afraid that I won't be  
> able to
> improve on that.
>
> I'm trying to understand if the fact that you can't combine  
> parameters and
> backtracking is an implementation issue or a conceptual issue. I could
> imagine that the same fragment function is generated twice by  
> antlr; one
> with and one without parameters and actions. The first one is used  
> during
> probing and the second one is used when the right 'path' is found.  
> Would
> that be possible?
>
> The actual issue I have is a bit more complicated than the example  
> I showed,
> I'm not passing the parameter directly, the parameter is a  
> container and for
> every matched subrule a component will have to be added to that  
> container.
> If I was to use scopes; would the following code be a 'good' solution?
>
> bar [Bar * myBar]
> 	scope {
> 		Bar * bar_;
> 	}
> 	@init {
> 		$bar::bar_ = myBar;
> 	}
> 	:
> 	(
> 		{
> 			Foo * myFoo = new Foo();
> 			$bar::bar_.addFoo(myFoo);
> 		}
> 		foo [myFoo]
> 	 )*
> 	;
>
> TIA,
>
> Corno
>

Corno -
I believe that it's a conceptual issue.  What happens if the  
parameter that is passed is used in a semantic predicate to allow/ 
disallow a particular parse path?  The parse tree is then dependent  
on the parameter.  I have tried, with some success (not fully yet, I  
believe, but that may be inexperience), the following:

bar[Bar myBar]
     :   (foo[null])=> foo[myBar]
     ;
or whatever.  If the parse is not dependent on the parameter then the  
syntactic predicate should work correctly.

Hope this helps -- and I hope I'm not wildly off-base.

Peace
- John
  


More information about the antlr-interest mailing list