[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: grammar questions



Indrek Mandre wrote:
> > and in CustomLexer (extends Lexer), you must override the peek(), next()
> > and filter() methods.  I'll let you figure out the details.
>
> I did that and it all works perfectly. Thanks a bunch. It wasn't as difficult
> as I had imagined.

Glad to hear that.

>...
> No recursion needed.

Good.  I was worried, as it can get ugly.

> > In other words, you could mismatch the colon and no-colon modes in the
> > different parts of an "if" statement.  ...
>
> This is not valid PHP syntax. And it would break the rule of symmetry/
> consistency (if there is such a rule). But there is no such thing as PHP
> specification, the specification is in a bison file and there they just let
> it shift. So yes, I'm a bit creative. But my grammar accepts all files
> accepted by current php implementation + couple of creative addons.

I see.  Then, the bison grammar behavior is probably similar to my
closest match solution (which yields an error on your tricky example).

> When I specify a rule in grammar like xxx* there's a function for setting
> that node's data - generated into the node source file:
>... 
> Wouldn't this all be equivalent to '_xxx_.addAll (list)' ?
> Isn't creating arrays like that slow?

This one is not intuitive to see for the casual reader;-) It is done to
avoid generating spurious "ConcurrentModificationException", as you are
most likely walking the AST when you modify it.

> And more. Isn't that functions used for modfifying the tree by users?
> If so then it doesn't replace the list but appends the contents. Is
> that valid behavior? Shouldn't it clear() it first?

Good point.  I think clear() should be called.  Could you submit a bug
about it at http://sourceforge.net/bugs/?func=addbug&group_id=5704

Thanks.

> And in TypedLinkedList.java you duplicate most of LinkedList
> methods. Has this to do with compatibility or something?

TypeLinkedList is a "typesafe" container.  It has to enfoce the type
safety through dynamic typecasts.  I haven't looked at the code lately. 
Maybe it could be simplified.  But, safety should be preserved.  You're
welcome to come up with suggestions.

Etienne
-- 
----------------------------------------------------------------------
Etienne M. Gagnon, M.Sc.                     e-mail: egagnon@j-meg.com
Author of SableCC:                             http://www.sablecc.org/
and SableVM:                                   http://www.sablevm.org/