Re: Thoughts about the controversial {expand} feature

On 25 Oct 2006 19:13:29 GMT,
Andreas Leitgeb <avl@xxxxxxxxxxxxxxxxxxxxxxxx> wrote:

Fredderic <put_my_name_here@xxxxxxxxxxxxxxx> wrote:
Still, as soon as you create the magical case of {...} as a prefix,
it seems a waste not to make some use of it. And if it's
constrained to constant indicies only, people will tend to use the
more regular TCL command methods for most purposes anyhow.
I rather think they'll glue together a string and pass it to evil:
set foo "{$n}"; eval command $foo\$list .... yeuch!
The whole "expand"-business came into life to *avoid* eval ...
Ok, this is just speculation...

The "expand" business, I'd say, wouldn't be glue-able at all in the form
in which it's been proposed. What you're suggesting, would be the
ability to do this in 8.5;
set foo "{expand}"; eval command $foo\$list
I seriously hope that doesn't work. The whole {expand} concept, as I
understand it, takes place essentially at parse time. Returning the
string {expand}, is just that. It's returning a string. It's not
returning the concept of expansion. And [eval] et al should never ever
even see the {expand} token (as opposed to the string "{expand}"). It
would be plucked out by the parser, and acted upon right there and
then. Otherwise, it needs to be a flag attached to the value being
returned, and probably won't be {expand} anymore anyhow.

Allowing non-constant components in it reduces the idea to simply
wrapping the variable or command in another command (like [lindex],
[lrange], or [lpick]), and then using the original {expand} on that.
In which case, we may as well stick with {expand}. ;)

I'd much rather we stay with what we have in 8.5, than go down that
route.


lpick should also accept some kind of list-of-indices,
But it'd probably be a pain in the arse to pluck out a bunch of
individual words... If you wanted to pluck out three words, the
index of each was stored in a variable, the result probably
wouldn't be very pretty.
It's not meant for everyday use, but as a way to avoid shimmering
for professionals :-)

Okay. Now you're scarring me. ;)


If you use non-constant indices, and you glue them together to a
string: "$a-$b,$c" then all the (likely numeric-valued) value-objects
are shimmered to string. otoh, e.g.:
lrange $list $a $b $c $c end-1 end
would avoid this shimmering (with appropriately extended lrange)

On the other hand, if you use constants only, then this all only
happens once at parse time. Once the parser recognises it as an expand
directive, it can go ahead and process it on the spot, performing the
necessary selective expansion.

Whether that's generating a series of [lindex] and [lrange] statements,
or whether that's using an internal [lpick]-like function to generate a
new list which it then appends to the argument line instead of
inserting as an argument as per usual, it'll none the less likely end up
being done far more efficiently than getting some command to do it the
same way as any old command call.


PPS: I really want to keep separate expansion from extraction.
Heck. They'll do that anyhow. And that [list] example makes
more sense when you start adding more variables into the mix.
ok, admitted:
[list {%}$foo some $extra {%}$bar [words] ]
can make some sense.
What I considered moronic was: [list {2-3}$foo] for [lrange $foo 2 3]

Don't blame you there...


Still, it's better than some of the convoluted constructs
we end up as it is.
eval [linsert [lreplace $list 0 0 [lookup [lindex $list 0]]] 1
$extra]] ... becomes simply ...
eval [lookup {0}$list] {*}$extra {1*}$list
Second, your shortened version would be behaving very wrong:
it would first expand stuff, and then run the parser on
each expanded element. If you really have stuff of that
kind in your scripts, rather fix them!

I don't understand that... It would "expand" the first word of $list
(which gets sent through [lookup]), then all the words of $extra, and
then the rest of $list. It would simply be {expand}ing a sub-set of
the list, instead of the whole thing.

I'm only guessing here, but if {expand} basically concatenates lists,
instead of wrapping a list into an item and appending that item to the
current argument list, then {1*} would simply concatenate the list from
the second word onwards. The only tricky one, would be the selection
of individual words.


This would be 8.5 (as of now) syntax for your sample:
[lookup [lindex $list 0]] $extra {expand}[lrange $list 1 end]
I'd say this is good enough.

So would I. If that's what we're left with, that'll do just fine.
Partial expansion would be a handy improvement, though, avoiding the
need of another round of command execution.


Fredderic
.

Relevant Pages

  • Re: The "never use string commands with lists" mantra - Why?
    ... The reason is because Tcl isn't like other languages. ... The fundamental role of the tcl parser is to take a string (eg: ... Tcl has no idea what the command will do ... when lists truly were strings. ...
    (comp.lang.tcl)
  • Re: Thoughts about the controversial {expand} feature
    ... something to do with lists. ... what i miss with the expand feature is something like the reserved ... Those [foreach ... ... command for collection. ...
    (comp.lang.tcl)
  • Re: Thoughts about the controversial {expand} feature
    ... The whole {expand} concept, as I ... It's returning a string. ... intermediate script in a variable where we can look at it. ... command $list ...
    (comp.lang.tcl)
  • Re: TIP #187: Procedures as Values
    ... Leaving aside that with the proposed alias "lambda", ... to avoid the conversion to string that would happen just to find ... If real lists ... the command could be checked ...
    (comp.lang.tcl)
  • Re: join strips backslash - feature or bug?
    ... is a string" and that is all; a list is just a special class of string. ... If a script can tell two values apart when the values have ... offered by the command is that its result is a string ... If you parse lists generated by list only by feeding them to ...
    (comp.lang.tcl)
Loading