Re: [TCLCORE] Tcl C API Warts + Expr evolution

[Andreas L. <av...@lo...>]

Andreas Kupries <and...@ac...> wrote:
> > Much more of a wart in this area is the lack of exposure of the internal
> > function TclGetIntForIndexM() (but not with that name!) which does
> > parsing of Tcl's end-relative indices.
> +1 on this.
> Of course, on a different hand, depending on the outcome of the Expr
> evolution discussion it might be simpler to drop the whole thing and
> go back to have it handled via expressions.

If we did the "local expr symbols" idea, then any list-API function 
could assemble an expr that first sets up a local symbol "end" (with
a value of list's size or (size-1) depending on the operation and
leaves the rest to expr (with the necessary "uplevel"-wrap, though).

If refactoring went that way, then I'd rephrase an old wish of mine
for index pairs (as in string range, string replace, lreplace), to
offer a local symbol for the respective previously specified value.
e.g.: if the symbol's name was a single underscore, then one could
write:  [string range $str [getIndex ...] {_+1}] for a two-char 
string at the given location. For the very first index, the "_"
would either not be defined, or arbitrarily defined to 0.

Even if TclGetIntForIndexM() remains separate from expr (such as to
avoid any need for uplevel'ing), then I'd still wish for its public
replacement to provide a general mechanism for specifying symbols,
(and use that mechanism for "end" - plus eventually more...).