[Tcl-bugs] [ tcl-Bugs-1201589 ] bareword madness in expr parser

[SourceForge.net <no...@so...>]

Bugs item #1201589, was opened at 2005-05-13 14:31
Message generated for change (Comment added) made by dgp
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=110894&aid=1201589&group_id=10894

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: 44. Parsing and Eval
Group: development: 8.5a3
Status: Open
Resolution: None
Priority: 5
Submitted By: Don Porter (dgp)
Assigned to: Don Porter (dgp)
Summary: bareword madness in expr parser

Initial Comment:
dgp	% if {yes} {puts foo}
		foo
		% if {!no} {puts foo}
		foo
		% if {y} {puts foo}
		foo
		% if {!n} {puts foo}
		syntax error in expression "!n": the word "n"
requires a preceding $ if it's a variable or function
arguments if it's a function

kbk	dgp - You have the appropriate logic in the 'n'
case in tclParseExpr.c(GetLexeme)?

kbk	Hmmm, ok, I see that you did it farther down, in
the 'default' branch, but look for those literals
exactly, not with unique-prefix matching.

[14:22]	kbk	Hmm. I don't really like unique-prefix
matching in this context.
[14:23]	kbk	but if we do it, we should do it only if
all else fails.
[14:23]	dgp	well, the parser doesn't (can't?) check the
validity of function names.
[14:23]	kbk	which is to say, *don't* do it if the
bareword is followed by optional whitespace and a left
paren.
[14:24]	kbk	because false() isn't a valid expr.
[14:24]	dgp	hmmm.... parens...
[14:24]	kbk	unless there's a function so named.
[14:25]	kbk	eq, ne, in, ni, would need further handling
somehow, though, becase $a eq("stuff") is valid, and is
not a function call.
[14:27]	kbk	and *that* interpretation depends on  left
context; the eq, ne, in, ni operators are operators
only if they follow a constant, a variable, or a right
paren.
[14:27]	kbk	Ugh.
[14:27]	kbk	I'm starting to think that expr has
outgrown a recursive-descent parser.


----------------------------------------------------------------------

>Comment By: Don Porter (dgp)
Date: 2005-05-20 11:19

Message:
Logged In: YES 
user_id=80530


and here's a version suitable
for application to the 8.4 branch.

----------------------------------------------------------------------

Comment By: Don Porter (dgp)
Date: 2005-05-20 11:04

Message:
Logged In: YES 
user_id=80530


second version of the patch
is limited to just fixing the
boolean literal prefix problem,
as well as accepting as function
names "eq" "ne" "in" and "ni"
when they appear in the
context for a function name
rather than an operator.

Treatment of other barewords
is left unchanged.



----------------------------------------------------------------------

Comment By: Don Porter (dgp)
Date: 2005-05-20 10:29

Message:
Logged In: YES 
user_id=80530


Attached patch makes expr
parser accept *all* barewords
as literals, which then includes
the reported problem of accepting
boolean value prefix barewords
as literals.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=110894&aid=1201589&group_id=10894