Donald G Porter wrote:
>------------- Begin Forwarded Message -------------
>
>Got started trying to implement
>TIP 176, and ran into a conflict
>that hasn't been noted before:
>
> lindex $l {2 +3}
>
>Currently, the second argument
>is interpreted as a list of
>indices, and the 3rd element
>of the 2nd element of $l is returned,
>if present.
>
>After TIP 176, though, {2 +3} would
>also match the proposed M+N syntax
>for an index, and the 5th element
>of $l would be returned.
>
>Also worth noting that there was
>much objection to the "end+N" notation
>in the original replies to this proposal,
>but that really should not be a problem.
>In fact, that feature is already present
>in Tcl:
>
>% string index abc end--1
>%
>
>That's equivalent in every way to
>the proposed end+1 that got people upset.
>
>I'm willing to move forward on this TIP,
>but the ambguity above has to be sorted
>out. Ruling out trailing whitespace in
>the M part of M+N would be sufficient,
>I think. Comments?
>
>
I think we should just leave the whitespace out. There's nothing in
the documentation that says you CAN'T put a space in there, but there's
also nothing that explicitly says you can. I, personally, never thought
you even could. I always read it as being one, single argument with no
spaces.
I don't think we should go mucking around with a other pieces of
code just to support this one, fringe case. We have to modify
documentation already to explain the new options for indexes, why not
just add that they must be one string with no spaces. Just because
'string is integer' recognizes spaces doesn't mean that it should
dictate this behavior.
Without spaces, this code becomes pretty easy to implement. It may
have a possible incompatibility, but I've never known or seen anyone
using a space between end- and N. Note, that the code already doesn't
allow a space between end and -.
Damon
|