Tcl Source Code

View Ticket
EuroTcl/OpenACS 11 - 12 JULY 2024, VIENNA
Ticket UUID: 1031507
Title: TIP #201 reference implementation
Type: Patch Version: None
Submitter: rmax Created on: 2004-09-20 20:22:02
Subsystem: 45. Parsing and Eval Assigned To: msofer
Priority: 5 Medium Severity:
Status: Closed Last Modified: 2004-10-23 05:13:43
Resolution: Accepted Closed By: msofer
    Closed on: 2004-10-22 22:13:43
Here is my first try on implementing TIP #201.
While doing this I stumbled over a parser problem with
alphanumeric operators. Initially it tried to parse
'int()' as 'in t()' after adding 'in'. This would
already have happened with 'eq', and 'ne' if there had
been a function that started with one of those
character seqences.

As a workaround I am accepting alphanumeric operands
only if they are not followed by another alphanumeric
character. I'd like this to be reviewed by people with
more C experience than I for correctness, and whether
there is a better way to do it.
User Comments: msofer added on 2004-10-23 05:13:43:
Logged In: YES 

TIP #201 has been committed on 2004-10-08 by dkf.
Implementation evolved from this patch.

rmax added on 2004-09-21 14:52:57:

File Added - 102230: tip201-3.patch

rmax added on 2004-09-21 14:52:56:
Logged In: YES 

I have moved the check for all alpha operators down to the
place where boolean literals and function names are checked.
I think it is better to have all alphanumeric parsing at one
place. The only downside I can see is that it might be
somewhat slower to have them there.

The way it is implemented now implies that an operator or
literal will never consist of anything but alphabetic
caracters, and that there will never be a function name like
in3() or true_42() that starts with alpha characters that
look like an operator or a literal immediately followed by a
digit or underscore.

dgp added on 2004-09-21 03:39:05:
Logged In: YES 

test 25.4 fails -- just a copy/paste
error writing the test.

more seriously, the isalpha() tests
should be moved a bit to avoid
reading past the end of buffer.
Tests in parseExpr.test (making use
of the [testexprparser] command)
would be best to verify those details.

rmax added on 2004-09-21 03:25:38:

File Added - 102170: tip201.patch