Hi,
> JimPoints out also that we should not be guarding our scope stacks.
Just for the record, I intensely dislike the guards added in 3.1. I'm from
the "the programmer knows best" camp and the [totally avoidable] automagic
guards hurt performance (since they are paid for in CPU cycles) ultimately.
> Let's begin with the guards we added for referencing rule
> properties.
> In version 3.0.1, if the else clause is not executed, s is
> null and you get a null pointer at $s.st.
>
> ('else' s=stat)? ... {$s.st}
Not really an issue since this should be properly written as:
(
'else' s=stat ...{$s.st}
)?
Then 's' is never used unless an else clause is present in the input.
> For 3.1, we have guarded all of those property references
> with s!=null?
> s.st:null. That is good.
Those checks are avoidable. The CPU cycles are better spent elsewhere...
> Now Imagine how we guard stack stuff. consider the following rule:
>
> block
> scope { int x; }
> : '{' stat+ '}'
> ;
>
> Ref $block::x currently checks that the stack is not empty
> before calling peek() to avoid a stack underflow exception.
> Jim argues that we should take that guard back out because it
> is a programming error to refer to $block::x when the stack
> is not properly set up. I think I'm agreeing with him. Is
> like accessing the local variable in an enclosing function
> but when there is no invoking function.
I agree with Jim too.
> Is it okay for me to remove the stack guards for dynamic
> scoping stuff? quick change to these two templates.
Removing all the [avoidable] guards is the smart thing to do IMHO.
Micheal
-----------------------
The best way to contact me is via the list/forum. My time is very limited.
_______________________________________________
antlr-dev mailing list
[email protected]
http://www.antlr.org:8080/mailman/listinfo/antlr-dev
