Tcl Source Code

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

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

kbkHmmm, 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]kbkHmm. I don't really like unique-prefix
matching in this context.
[14:23]kbkbut if we do it, we should do it only if
all else fails.
[14:23]dgpwell, the parser doesn't (can't?) check the
validity of function names.
[14:23]kbkwhich is to say, *don't* do it if the
bareword is followed by optional whitespace and a left
paren.
[14:24]kbkbecause false() isn't a valid expr.
[14:24]dgphmmm.... parens...
[14:24]kbkunless there's a function so named.
[14:25]kbkeq, ne, in, ni, would need further handling
somehow, though, becase $a eq("stuff") is valid, and is
not a function call.
[14:27]kbkand *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]kbkUgh.
[14:27]kbkI'm starting to think that expr has
outgrown a recursive-descent parser.

Logged In: YES 
user_id=72656

FWIW, users find the single char bareword handling of
booleans surprising:

http://bugs.activestate.com/show_bug.cgi?id=59177

While I could see the pattern straight off, not even other
expert Tcl'ers could, and it is eyebrow raising.  This needs
at least clear exception docs in expr.n, if not other
consideration for correction.

Logged In: YES 
user_id=80530

TIP 182 implementation
includes tests for the improved
bareword parser.

Logged In: YES 
user_id=80530


Committed for 8.4.10 and 8.5a3.

Leaving report open because
some tests really ought to be
added to the test suite for this.
(Volunteers invited!)

File Added - 135280: 1201589-84.patch

Logged In: YES 
user_id=80530


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

File Added - 135277: 1201589-2.patch

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.

File Added - 135271: 1201589.patch

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.