[antlr-interest] Apparent problem with dynamic scopes in C target

[Jim Idle]

Daniel Jensen wrote:
> Jim Idle wrote:
>> Fixed in the templates. You need last nights jar.
>
> That's what I was using.  The code in my parser that seems to be 
> causing the trouble is:
>
>    $ExprScope::in_extract = $ExprScope[-1]::in_extract;
>
> which gets turned into this C code:
>
>    (SCOPE_TOP(ExprScope))->in_extract=     
> ((SCOPE_TYPE(ExprScope))(ctx->SCOPE_STACK(ExprScope)->get( 
> ctx->SCOPE_STACK(ExprScope), 
> ctx->SCOPE_STACK(ExprScope)->size(ctx->SCOPE_STACK(ExprScope)) - 1 - 
> 1) ))->in_extract;
>
> The change you made to C.stg changes the definition of SCOPE_SIZE, but 
> the generated code doesn't use SCOPE_SIZE, so the behavior is 
> unchanged.  Maybe the fix is to generate different code for 
> $ExprScope[-1] that uses the SCOPE_SIZE macro?
Yes, that might be necessary, I will look into doing that later today.
>
>>>  
>>>>> On another note, I will admit to being slightly baffled by 
>>>>> 'exprScopeDepth' - is it correct that it's only ever incremented?
>>>>>         
>>>> Er, yeah ... I'm sure I would have noticed that eventually. :-/  
>>>> Just pretend that there are @after actions that decrement 
>>>> exprScopeDepth following the @init actions that increment it.
>>>>     
>>> :-)
>>> You could use SCOPE_SIZE(ExprScope);
>> You must use this.
>
> Why, if the program that uses the parser only has a single thread?  
Because the C constructs are not the same as the Java ones and this 
hides the implementation for you. However, for the reference above, you 
should not need to do that of course.
> I'm actually targeting both C and Java with this grammar, so the fewer 
> C target-specific constructs I'm forced to use, the happier I'll be.
Sure, but C is C and Java is Java so you won't be able to use one 
generic parser once you start using scopes and actions. The better bet 
is to use a base grammar then branch this to the Java and C versions.

Jim