Thoughts about the controversial {expand} feature
Sacha Schär
I followed the discussion about the necessity and the implementation
problems of the "Threat this token, which otherwise would be a single
list element, as a sub-range of the enclosing list" task, aka {expand}
feature.
Personally, I think this a very important option, and it is a pity, that
it was not introduced in the very beginning of the language development.
As many, I disliked the appearance of {expand}, but meanwhile I think,
it ist the best solution among the bad options.
However, recently, I had an idea about an alternative approach:
Let us introduce a new special command [lreturn], which signals, that
the return value should be expanded inside the enclosing list.
So instead of
proc foo {} {
return {bar baz}
}
list a b {expand}[foo]
one would write
proc foo {} {
lreturn {bar baz}
}
list a b [foo]
one could then also easily emulate a syntax that has a equivalent
semantics as the {expand} approach:
proc expand {x} {
lreturn $x
}
list a b c [expand {1 2 3}] ;# instead of "list a b c {expand}{1 2 3}
Of course, [lreturn] would be a very special command, and it would
probably also cause other trouble.
I'm just curious. Was this idea considered? What are the drawbacks?
-Sacha
Bruce Hartweg
I think I remember discussions about this. but don;t have any concrete refs.
Problem here is the solving of the problem at the wrong place. the func creating
the list doesn't know or care how you use ht elist so using return or lreturn
will not make sense - it is the caller who needs to mark it as expended.
Bruce
miguel sofer
Sacha Schär wrote:
> Let us introduce a new special command [lreturn], which signals, that
> the return value should be expanded inside the enclosing list.
> Of course, [lreturn] would be a very special command, and it would
> probably also cause other trouble.
> <snip>
> I'm just curious. Was this idea considered? What are the drawbacks?
See http://wiki.tcl.tk/11787, http://wiki.tcl.tk/9468,
http://aspn.activestate.com/ASPN/search?query=%7Bexpand%7D&x=0&y=0&type=Archive_tcl-core_list
I'm sure there is more ...
Miguel
Sacha Schär
Thanks for the links! Now I definitely vote for {expand} ;)
-Sacha
David Gravereaux
Hash: SHA1
Too bad it looks so ugly.. Why not something tighter like {@} or some
other single meaning character within the brace (given the necessity due
to parser rules for for/back compatibility)?
exec {@}[auto_execok start] $url
I think this proves why Tcl can never go to a 9.0 branch. If people are
so concerned about "backward compatibility" when they really meant
"forward compatibility" (as in ignorance to the new stuff)
Our 11 Golden Rules are so set in cement, we can never get out of it.
I wonder if McVoy's work can fix Tcl's face?
- --
David Gravereaux <davy...@pobox.com>
[species:human; planet:earth,milkyway(western spiral arm),alpha sector]
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (MingW32)
iD8DBQFFORbKlZadkQh/RmERAvsRAJ4i5hPCZ3Cs/LgZOfNJ8Q/KtrAUOgCfdLsE
A7Gmlo9VfU9XSHlWjXzy/DQ=
=ua4J
-----END PGP SIGNATURE-----
Sacha Schär
> Too bad it looks so ugly.. Why not something tighter like {@} or some
> other single meaning character within the brace (given the necessity due
> to parser rules for for/back compatibility)?
>
> exec {@}[auto_execok start] $url
>
> I think this proves why Tcl can never go to a 9.0 branch. If people are
> so concerned about "backward compatibility" when they really meant
> "forward compatibility" (as in ignorance to the new stuff)
>
I don't think {@} looks nicer than {expand}, rather the other way round.
Somehow I got used to {expand}, even though, I never used it in
reality. In the beginning, I also thought it is ugly, I could not even
belief that this is a serious proposal because of its uglyness!
But now, somehow that changed....
About the braces: For me it is not (only) a question of backward/forward
compatibility. With this syntax, when you look at some code, it is easy
to see that something very special is going on here (which is actually
the case). Even if you are totally unaware of this new feature and you
see this in someone elses code, you do not start looking for an expand
command or variable, because you will realize that it could not be
invoked that way. So it must be something special. The word inside the
braces gives you a hint about it... (much better than a single character)
-Sacha
PS: would this work?
proc @ {} {
return "{expand}"
}
[@]{this is to be expanded}
Donal K. Fellows
> PS: would this work?
> proc @ {} {
> return "{expand}"
> }
> [@]{this is to be expanded}
No, that won't work because it clashes with existing legal behaviour:
% proc @ {} { return "{expand}" }
% puts [@]{this is to be expanded}
wrong # args: should be "puts ?-nonewline? ?channelId? string"
% list [@]{this is to be expanded}
\{expand\}\{this is to be expanded\}
% llength [list [@]{this is to be expanded}]
5
% info patch
8.4.14
Expanding substitutions need to be syntactically different to the other
things in Tcl(n), i.e. the language itself. Doing this in 8.5 (i.e.
with syntactic backward compatability) means that we must use one of
the few constructs that is illegal in 8.4; braces with characters
immediately after. We stick an "expand" inside (much to Jeff's disgust)
to distinguish from the "oops, forgot the space" case.
I really wanted backtick, but that would definitely not be
syntactically compatible. (The semantics of expanding substitutions are
precisely correct, as is using syntax. This was all hammered out in
excruciating detail 3 years ago or so. We're not reopening it.)
Donal.
Fredderic
> I really wanted backtick, but that would definitely not be
> syntactically compatible. (The semantics of expanding substitutions
> are precisely correct, as is using syntax. This was all hammered out
> in excruciating detail 3 years ago or so. We're not reopening it.)
A backtick would be bad... It's introducing a whole new substitution
token..!
Hey Donal, how about giving
{apples oranges}[more_fruit]{grapes bananas}
list concatenation semantics. It'd be quite handy, really...
And then we'll just HAVE to go back and re-write the books for
dollar-backtick instead of {expand}, for that particular
functionality. ;)
Fredderic
Bryan Oakley
> ... This was all hammered out in
> excruciating detail 3 years ago or so. We're not reopening it.)
... and yet, here we are :-\
This is a seriously dead horse. Dead, and turned to glue, used as glue,
then the objects the glue was used on were thrown away, the trash was
burned, the ashes buried. Nothing left but a small mound of earth that
people keep stumbling over.
For those still asking the question "why" or who wish to make a last
minute proposal, read the old threads and accept the fact it *is* in 8.5
and will remain part of the language for a long time.
It's important to remember that the language exists to make it easy for
us to write code. {expand}, while arguably quite ugly, makes it easier
for us to write code.
David Gravereaux
Hash: SHA1
Fredderic wrote:
> On 20 Oct 2006 14:01:43 -0700,
> "Donal K. Fellows" <donal.k...@man.ac.uk> wrote:
>
>> I really wanted backtick, but that would definitely not be
>> syntactically compatible
....
> A backtick would be bad... It's introducing a whole new substitution
> token..!
And right there is the problem. If we can ever go to 9.0, raising the
major version says that it won't be compatible. Then all is good with
redefining the golden rules.
- --
David Gravereaux <davy...@pobox.com>
[species:human; planet:earth,milkyway(western spiral arm),alpha sector]
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (MingW32)
iD8DBQFFObSQlZadkQh/RmERAscrAKDP+GuGpaqQ/QTKTVpkfgwdpf0Q2QCgu3UW
IdG7HJ71h+ltyK7l1escY9U=
=n8xS
-----END PGP SIGNATURE-----
David Gravereaux
<oak...@bardo.clearlight.com> wrote:
>accept the fact it *is* in 8.5
>and will remain part of the language for a long time.
There might only be one answer left... FORK!
Jeff Hobbs
>>>> Let us introduce a new special command [lreturn], which signals, that
>>>> the return value should be expanded inside the enclosing list.
>>>> Of course, [lreturn] would be a very special command, and it would
>>>> probably also cause other trouble.
>>>> <snip>
>>>> I'm just curious. Was this idea considered? What are the drawbacks?
>>> See http://wiki.tcl.tk/11787, http://wiki.tcl.tk/9468,
>>> http://aspn.activestate.com/ASPN/search?query=%7Bexpand%7D&x=0&y=0&type=Archive_tcl-core_list
>>>
>
> other single meaning character within the brace (given the necessity due
> to parser rules for for/back compatibility)?
>
> exec {@}[auto_execok start] $url
In ActiveTcl 8.5 you can just do:
exec {}[auto_execok start] $url
The typo argument was a poor one. All language constructs are
typo-prone at some level.
One recommendation I got was to use {*} as in:
exec {*}[auto_execok start] $url
which means expand all the items, if you naturally lead from that to
allowing things like {1}$value to be equivalent to [lindex $value 1].
--
Jeff Hobbs, The Tcl Guy, http://www.activestate.com/
Donal K. Fellows
> One recommendation I got was to use {*} as in:
> exec {*}[auto_execok start] $url
> which means expand all the items, if you naturally lead from that to
> allowing things like {1}$value to be equivalent to [lindex $value 1].
Hmm, interesting...
Donal.
Michael Schlenker
like python...
Michael
Donal K. Fellows
No, since that would still expand to multiple arguments. It would let
you use something like [list {1..end}$value] to replace [lrange] though.
Donal.
Neil Madden
As Jeff said, ActiveTcl already supports {}[...] notation instead of
{expand}. This alternative is actually #ifdef'd as ALLOW_EMPTY_EXPAND in
tclParse.c (Tcl_ParseCommand) in Tcl 8.5 CVS on sourceforge. Interesting.
-- Neil
Tom Conner
"Neil Madden" <n...@cs.nott.ac.uk> wrote in message
news:Q_U_g.7142$t6....@newsfe4-win.ntli.net...
> David Gravereaux wrote:
> > On Fri, 20 Oct 2006 19:43:30 -0500, Bryan Oakley
> > <oak...@bardo.clearlight.com> wrote:
> >
> >
> >>accept the fact it *is* in 8.5
> >>and will remain part of the language for a long time.
> >
> > There might only be one answer left... FORK!
>
> As Jeff said, ActiveTcl already supports {}[...] notation instead of
> {expand}.
Maybe this is a stupid question, but is there more than 1 Tcl; ActiveTcl and
something else?
Jeff Hobbs
ActiveTcl is a batteries included setup (much more than just the core).
It can vary slightly from the CVS core code base, but generally doesn't.
Don Porter
> As Jeff said, ActiveTcl already supports {}[...] notation instead of
> {expand}.
In addition to, not instead of.
Simplest way to close the fork is to make official source release also
support both syntaxes.
DGP
Tom Conner
"Jeff Hobbs" <je...@activestate.com> wrote in message
news:453C3633...@activestate.com...
I used to hand install Tcl 8.x, Tcllib, and Expect, but now I always use the
ActiveTcl install since it makes life easier for installing Tcl, Tcllib and
Expect. I always assumed I was getting the same programs in ActiveTcl as
when I collected the individual programs.
Anyway, to me, the statement, "ActiveTcl already supports {}[...] notation
instead of {expand}", sounds as if stand-alone Tcl 8.5 doesn't support
"{}[...] notation". Obviously, that would be terrible if true.
So, I thought I would check the Tcl 8.5 documentation, but didn't see
anything about {expand} at http://www.tcl.tk/man/tcl8.5/TclCmd/contents.htm
Under what keyword is {expand} explained?
Neil Madden
...
>
> So, I thought I would check the Tcl 8.5 documentation, but didn't see
> anything about {expand} at http://www.tcl.tk/man/tcl8.5/TclCmd/contents.htm
> Under what keyword is {expand} explained?
It's on the main Tcl.n page: http://www.tcl.tk/man/tcl8.5/TclCmd/Tcl.htm#M9
Uwe Klein
The only environment i know of where chopping of your legs
is the way to greatness is management and big business.
uwe
Andreas Leitgeb
I find it a bad idea, because:
- we shouldn't add (again) new syntax for things that
are already perfectly well and safely doable now.
- it generates further (believed) demand for
new syntax to allow for non-const indices.
I don't have any opinion about {} versus {expand}.
while {} was my original proposal, I *do* accept
the reasoning, that "{}$var" can just too likely
result from an omitted space.
Andreas Leitgeb
> And right there is the problem. If we can ever go to 9.0, raising the
> major version says that it won't be compatible. Then all is good with
> redefining the golden rules.
It's the wrong approach.
Going to 9.0 means putting lots and lots of scripts - not only
those made by developers (who could just ship a new version),
but also those made by users! - into a risk of no longer working.
We shouldn't ask if we "can" go to 9.0, but perhaps in the context
of some really important deep changes, we might instead realize that
we "must" go to 9.0
I'm not aware of any currently proposed changes that would
justify a step to 9.0. Just having a nicer syntax for expansion
doesn't imho.
"9.0" is not the cheap permission for incompatible changes,
"9.0" is an indicator for others when such changes really
had to be done.
PS: I don't know, though, whether all previous major-version changes
(1 to 8) really were made necessary due to incompatible changes ...
Don Porter
> I'm not aware of any currently proposed changes that would
> justify a step to 9.0.
There are some TIPs in place targetting version 9. Search the collection.
> "9.0" is not the cheap permission for incompatible changes,
> "9.0" is an indicator for others when such changes really
> had to be done.
This is correct. We want a new version of the same language, not an
entirely new language. If a large fraction of scripts do not carry over
then we'll have written a new language.
--
| Don Porter Mathematical and Computational Sciences Division |
| donald...@nist.gov Information Technology Laboratory |
| http://math.nist.gov/~DPorter/ NIST |
|______________________________________________________________________|
Cameron Laird
Tom Conner <tco...@olopha.net> wrote:
.
.
.
>Maybe this is a stupid question, but is there more than 1 Tcl; ActiveTcl and
>something else?
>
>
<URL: http://wiki.tcl.tk/references/13992! >
Don Porter
> Anyway, to me, the statement, "ActiveTcl already supports {}[...] notation
> instead of {expand}", sounds as if stand-alone Tcl 8.5 doesn't support
> "{}[...] notation". Obviously, that would be terrible if true
It is true. On this point, the beta ActiveTcl distributed by Active
State is a fork of the TCT source code.
And to repeat the important distinction: ActiveTcl supports the {}
syntax in addition to, not instead of the {expand} syntax.
Glenn Jackman
> Tom Conner wrote:
> > Anyway, to me, the statement, "ActiveTcl already supports {}[...] notation
> > instead of {expand}", sounds as if stand-alone Tcl 8.5 doesn't support
> > "{}[...] notation". Obviously, that would be terrible if true
>
> It is true. On this point, the beta ActiveTcl distributed by Active
> State is a fork of the TCT source code.
>
> And to repeat the important distinction: ActiveTcl supports the {}
> syntax in addition to, not instead of the {expand} syntax.
That leads me to a coding style principle about Tcl's allowable
abbreviations. Just because, for example, "package req foo" works and
can be convenient in an interactive session, programs shouldn't rely on
it. Not everone using your code will be using ActiveTcl. By all means,
use "{}[...]" in ActiveTcl 8.5's tkcon, but your source files should
contain "{expand}[...]".
Just as you write documentation for someone else to read, write code
like someone else will have to maintain it.
--
Glenn Jackman
Ulterior Designer
David Gravereaux
> Andreas Leitgeb wrote:
>> I'm not aware of any currently proposed changes that would
>> justify a step to 9.0.
>
> There are some TIPs in place targetting version 9. Search the collection.
>
>> "9.0" is not the cheap permission for incompatible changes,
>> "9.0" is an indicator for others when such changes really
>> had to be done.
>
> This is correct. We want a new version of the same language, not an
> entirely new language. If a large fraction of scripts do not carry over
> then we'll have written a new language.
>
Did this much controversy happen when dollar expansion was added? If
for 9.0, "@" becomes our new expand token as in:
exec @[auto_execok start] $url
All it takes to port 8.x scripts to 9.0 is to check them to see @ isn't
a stray character at command or variable boundaries. This isn't as
difficult as the "other camp" thinks it is. And quite a fair change for
a new and highly useful language token.
Make an executive decision, for a better language.
Gerald W. Lester
> Don Porter wrote:
>> Andreas Leitgeb wrote:
>>> I'm not aware of any currently proposed changes that would
>>> justify a step to 9.0.
>> There are some TIPs in place targetting version 9. Search the collection.
>>
>>> "9.0" is not the cheap permission for incompatible changes,
>>> "9.0" is an indicator for others when such changes really
>>> had to be done.
>> This is correct. We want a new version of the same language, not an
>> entirely new language. If a large fraction of scripts do not carry over
>> then we'll have written a new language.
>>
>
>
> Did this much controversy happen when dollar expansion was added?
No, there were very few written scripts when dollar expansion was added.
Today there are several hundred million lines of Tcl code in production
around the world -- some in applications you **REALLY DO NOT WANT BREAKING**.
> ...
--
+--------------------------------+---------------------------------------+
| Gerald W. Lester |
|"The man who fights for his ideals is the man who is alive." - Cervantes|
+------------------------------------------------------------------------+
Don Porter
> No, there were very few written scripts when dollar expansion was added.
> Today there are several hundred million lines of Tcl code in production
> around the world -- some in applications you **REALLY DO NOT WANT
> BREAKING**.
That's a concern too, but one advantage of placing the incompatibilities
at a major release is that those millions of lines can stick with the
old release if they must.
It's a balancing act with judgments to be made. I only posted to this
thread to counter the "break anything!" spirit that seemed to be forming.
Don Porter
> Did this much controversy happen when dollar expansion was added? If
> for 9.0, "@" becomes our new expand token as in:
>
> exec @[auto_execok start] $url
There's no reason to start from scratch on this. See TIP 103 for a
brief summary of some candidates and the type of conflicts they would
create. Also see
http://aspn.activestate.com/ASPN/Mail/Message/Tcl-core/1791605
Concern about @ syntax was that Tk is already using it.
David Gravereaux
> David Gravereaux wrote:
>> Did this much controversy happen when dollar expansion was added? If
>> for 9.0, "@" becomes our new expand token as in:
>>
>> exec @[auto_execok start] $url
>
> There's no reason to start from scratch on this. See TIP 103 for a
> brief summary of some candidates and the type of conflicts they would
> create. Also see
> http://aspn.activestate.com/ASPN/Mail/Message/Tcl-core/1791605
>
> Concern about @ syntax was that Tk is already using it.
It is? Where? I don't write much, if any, Tk. There's TIP#202
http://www.tcl.tk/cgi-bin/tct/tip/202 but doesn't appear to have any
interaction.
Donald Arseneau
> Don Porter wrote:
> > Concern about @ syntax was that Tk is already using it.
>
> It is? Where?
@ prefix is used for indices in canvas, entry, listbox, menu, spinbox, and text.
+ prefix is used for bind scripts
# prefix is used for comments, uplevel, and rgb colors.
% prefix is used for bindings substitution
(I do like % for {expand} because the glyph visually suggests separating
objects.)
--
Donald Arseneau as...@triumf.ca
Donal K. Fellows
> It is? Where? I don't write much, if any, Tk. There's TIP#202
> http://www.tcl.tk/cgi-bin/tct/tip/202 but doesn't appear to have any
> interaction.
FYI, Tk uses @ in general cursor and bitmap handling, and also for
coordinate-relative indices in several widgets.
Donal.
David Gravereaux
tcl_src\library\clock.tcl(3586): binary scan $d @${seek}a${nChar} abbrs
That's one line that would get messed-up..
tk_src\tests\canvPsBmap.tcl(31): -bitmap @[file join
$canvPsBmapImageDir flagdown.xbm] \
Same for that one.. It wouldn't be hard to change, if @ were upgraded to
a token:
-bitmap \@[file join $canvPsBmapImageDir flagdown.xbm] \
There's going to be pain no matter what, so pick the solution that doesn't
make Tcl look like a hack job 10 years from now.
Jeff Hobbs
> Donal K. Fellows <donal.k...@man.ac.uk> wrote:
>> Jeff Hobbs wrote:
>>> One recommendation I got was to use {*} as in:
>>> exec {*}[auto_execok start] $url
>>> which means expand all the items, if you naturally lead from that to
>>> allowing things like {1}$value to be equivalent to [lindex $value 1].
>> Hmm, interesting...
>
> I find it a bad idea, because:
> - we shouldn't add (again) new syntax for things that
> are already perfectly well and safely doable now.
> - it generates further (believed) demand for
> new syntax to allow for non-const indices.
There are many TIPs that propose alternatives to existing syntax in
order to provide an "improved" coding experience.
Jeff Hobbs
And all those are used a LOT, so you would be breaking almost all Tk
code if you go picking one of the above.
Ralf Fassel
| Just as you write documentation for someone else to read, write code
| like someone else will have to maintain it.
QOTW...
Reminds me of
Eagleson's Law:
Any code of your own that you haven't looked at for six or more
months, might as well have been written by someone else. (Eagleson is
an optimist, the real number is more like 3 weeks.)
R'
Donal K. Fellows
> There's going to be pain no matter what, so pick the solution that doesn't
> make Tcl look like a hack job 10 years from now.
We did a survey of this sort of thing way back[*], and backtick (`) is
the only ASCII printable character that isn't going to attract masses of
problems. (The only problem with it is probably in the generation of
shell scripts or in some kinds of string processing, both of which are
cases where it is far more likely to be quoted already anyway.)
Changing its processing category from "not special at all" to "very
special indeed" would have been an incompatible change though and would
have forced us to release Tcl 9.0 and not 8.5, which several TCT members
(not including myself) were unhappy about doing at the time. The
advantage of what was selected is that it makes no existing correct
script fail to work unless it relies on specific failure modes; we've
shied away from defining those for good reason. :-)
Donal.
[* I forget exactly when; maybe summer of 2003? ]
Fredderic
David Gravereaux <davy...@pobox.com> wrote:
> >> I really wanted backtick, but that would definitely not be
> >> syntactically compatible
> > A backtick would be bad... It's introducing a whole new
> > substitution token..!
> And right there is the problem. If we can ever go to 9.0, raising the
> major version says that it won't be compatible. Then all is good with
> redefining the golden rules.
I'd sill hate to see a whole new substitution token introduced at this
point (even for 9.0). An unlikely extra character (ie. the backtick)
added immediately after the $ substitution token, however, would still
fit in with both the purpose of the $ token, and golden rules. "$`" is
also far more noticeable than this tiny little backtick all on its own
in front of a heap of text. I noticed that a lot when I was doing
LISP, although it's far more common there, so you tend to be looking
out for it...
Fredderic
Andreas Leitgeb
... is still hardly visible at all in most fonts.
Also, what would have been your choice for doing expanded
command-substitution? I can't think of anything analoguous
to $<newchar>varname ...
> "$`" is also far more noticeable than this tiny little backtick
> all on its own in front of a heap of text.
That's right, of course, but imho still not enough.
Fredderic
Andreas Leitgeb <a...@gamma.logic.tuwien.ac.at> wrote:
> Fredderic <put_my_n...@optusnet.com.au> wrote:
> > An unlikely extra character (ie. the backtick)
> > added immediately after the $ substitution token,...
> ... is still hardly visible at all in most fonts.
But it's far more visible following a $-sign, than a space. Dollar
signs aren't often followed by space, so one tends to look a little
closer. At least, that's what I've found.
> Also, what would have been your choice for doing expanded
> command-substitution? I can't think of anything analoguous
> to $<newchar>varname ...
Heck, why not just the same thing? Why does there HAVE to be a
uniquely command-based equivalent? Commands are a duel-token recursive
syntax, where {expand} isn't, and nor is the $-sign. So just make it
a direct replacement of {expand}... It's not 100% intuitive, but then
neither would be the equally strange interpretation of trying to expand
a literal word as a list. Personally, I'd feel quite comfortable with
$`[command].
> > "$`" is also far more noticeable than this tiny little backtick
> > all on its own in front of a heap of text.
> That's right, of course, but imho still not enough.
Well, I think the point of this thread, at least for me, was to not end
up with too much. ;)
It's frequently stated that the $ token itself has always been a
short-cut to [set], rather than a distinctly TCLish entity. It already
has its own semantics that distinguish it from its command roots. It's
already defined to have very simple and limited syntax. And there's
not that many things that tend to follow a $-sign naturally. It's also
very nearly universal from what I can tell, to anyone who's done any
form of basic, shell scripting, any of several scripting languages,
etc. It's there, it's visible, it's already outside of the usual TCL
idioms, and I've never in my life, seen the string "$`" used in output.
Fredderic
Fredderic
By the sounds of it, ActiveTCL's {} syntax is an uncertainty anyhow,
since someone mentioned it was wrapped by a #ifdef...
So now that TCL has settled on their syntax, ActiveTCL can simply mark
it as a early starter idea that has been replaced by the more heavily
debated and agreed apon one from the main tree. Then in a few
versions, they can either drop the {} syntax entirely, or maintain it
as a deviant extension.
Fredderic
Fredderic
> > And with {1:end}$value ? something like lrange, and it would look a
> > bit like python...
> It would let you use something like [list {1..end}$value] to
> replace [lrange] though.
I think that's going a little too far, personally... But it is an
interesting idea...
But I DO often find myself using a rather ugly number of [lindex]'s all
over the place. {n} where n is a constant integer (I wouldn't even
entertain the idea of substitution in such a place), could indeed be
useful. I'd advocate leaving off the "end", and just using negative
indicies for that purpose. It would mesh in rather well with {*} as an
{expand} operator.
One way to resolve the big problem (as I see it) with {1:end} or
{1..end}, is whether the list of words should be split ala {expand}, or
simply substituted ala [lrange]. That COULD be resolved similar to the
bash shell, by way of {n@m} (or {n*m}, etc.) meaning {expand}[lrange],
where {n:m} would be simply [lrange]. This might indeed be useful,
though I don't know that it's useful enough.
Finally, the last variant on this theme that I can think of, and
one that I see as being rather useful, would be {n,m,o,p,etc}, where a
list of incicies can be given. Combined with foreach, it would be most
helpful for plucking out several distinct terms from a list. I've been
doing things like [foreach {abc def . . . ghi . . jkl} $list {break}],
where this would allow me to do [foreach {abc def ghi jkl}
{0,1,5,8}$list {break}].
You could possibly combine the last two, forming a notation effectively
equivalent to a series of [lindex], [lrange] and {expand}[lrange]'s,
all wrapped up in a [list].
But again, I'd strongly insist on constant indicies only, no
substitution. That stipulation should keep it readily optimisable, and
also keep it easy to both read and parse.
Fredderic
Bruce Hartweg
And you think that tons (and I really mean tons) of code that have
to be "fixed" with ugly backslashes (as well as tons of new code)
is somehow "pretty"?
take a breath. count to ten. let it go.
Bruce
Don Porter
> By the sounds of it, ActiveTCL's {} syntax is an uncertainty anyhow,
> since someone mentioned it was wrapped by a #ifdef...
ActiveTcl distributes binaries, not source code. You get the #ifdef's
that ActiveState has chosen to enable.
Don Porter
> I'd sill hate to see a whole new substitution token introduced at this
> point (even for 9.0).
It is important to recognize that the {expand} prefix is not a
substitution token, but a general word-expanding syntax flagging a word
to be broken into multiple words after any substitutions in it (if any)
are complete.
David Gravereaux
wrote:
>And you think that tons (and I really mean tons) of code that have
>to be "fixed" with ugly backslashes (as well as tons of new code)
>is somehow "pretty"?
Tcl the language, yes.. Sorry for Tk.
Like Donal says, "Changing its processing category from "not special at
all" to "very special indeed" would have been an incompatible change
though and would have forced us to release Tcl 9.0 and not 8.5"
And to extend that, the choice of what character to use is quite a
problem. '~^ don't appear at first glance to have special meaning already
to the windowing extension.
^ visually implies "raise-up". A quick grep finds them safe within
curlies for REs, not on command boundaries.
exec $cmd ^$args ^[getFileNames]
That's not ugly at all. A whole lot better than:
exec $cmd {expand}$args {expand}[getFileNames]
>take a breath. count to ten. let it go.
Can't. We need a new special token in 9.0, not an ugly political hack job
compromise in a convenient syntax error hole.
Maybe Larry McVoy is right to replace Tcl's face, given that it is so
stuck in historical cement.
Donal K. Fellows
> Maybe Larry McVoy is right to replace Tcl's face, given that it is so
> stuck in historical cement.
Larry's right a lot of the time, which is terrible since he really rubs
me up the wrong way. :-)
Right now, the plan (written faintly in pencil on the back of an
envelope) is to start work on 9.0 as soon as we can, which probably
means either when we've reached the point of believing that we've got
8.5.0 release candidates about. Before then, we (the core maintainers)
are probably going to be too busy to fiddle around with doing new
features. But I'm terrible at release schedules, so don't take my word
for it.
Donal.
TCL Warrior
> ^ visually implies "raise-up". A quick grep finds them safe within
> curlies for REs, not on command boundaries.
> exec $cmd ^$args ^[getFileNames]
> That's not ugly at all. A whole lot better than:
> exec $cmd {expand}$args {expand}[getFileNames]
> >take a breath. count to ten. let it go.
I agree with the above a lot, but I would like to add my own suggestion
which is very similar
since
> exec $cmd {expand}$args {expand}[getFileNames]
And since Active tcl support
> exec $cmd {}$args {}[getFileNames]
I suggest
> exec $cmd {^}$args {^}[getFileNames]
or what I furthuer prefer
> exec $cmd {%}$args {%}[getFileNames]
In the next release 8.5
Some suggest above that % is used in Tk a lot, so maybe we wont be able
to use % instead of ^, I still suggested it because I prefer a lot how
it looks
Anyway, in later release we can support dropping the parentheses so
{^}, can become ^
and for the variables I suggest we even drom the $, this is kinda why I
was hopping for % instead of ^, so the command will look like
> exec $cmd ^args ^[getFileNames]
or
> exec $cmd %args %[getFileNames]
or a mix % can mean ^$
> exec $cmd %args ^[getFileNames]
Anyway even if we never go this way {^} is not so bad, actually even
more I find {%} very cute even if the never drop the parentheses
> exec $cmd {%}args {%}[getFileNames]
Not bad at all !
Glenn Jackman
> > exec $cmd ^$args ^[getFileNames]
> > exec $cmd {^}$args {^}[getFileNames]
Truly, beauty is in the eye of the beholder.
Jeff Hobbs
If the {expand} were reduced to a single character like {%} or {*}, then
it would be much better than {expand}. In that sense, I don't see a big
issue in using {}something as a metasyntactic element. However, forcing
{pleaseexpandthenextargument}foo on users was a bad compromise.
Jeff Hobbs
What makes you think that ActiveTcl will keep the {barf^Wexpand}...
syntax instead of the more concise {}... form?
Fredderic
Glenn Jackman <gle...@ncf.ca> wrote:
Errr, yeah. They're ALL ugly. ;)
{} is easy to do by accident, but then so are many others. {expand} is
too bloody long, especially when you need to use it three or four times
in the one command. And adding a new substitution token is just an evil
road to head down. Which brings me to two minds:
Throwing a small "flag" token after the existing variable substitution
shortcut token (ala $), gives it something of its very own to do at
least. ;) So either $` or $^ indicating that the next variable or
command substitution should be word-expanded.
$`variable :: Expands the variable, dropping each word in individually.
The existing $ is easy for any TCLer to understand. They all know that
there'll be a variable name after it.
$`[command] :: Not extraordinarily beautiful, and doesn't quite ring
with the idea of $[command] which is a literal $-sign before the result
of [command], but since $ has funny rules about character ranges
already, I'm sure we could get used to it.
$`{literal word list} :: Just doesn't make sense to me at all. So I
don't think there's any clash with the idea of {}'s still being used to
break out of $'s limited character acceptance.
OTOH... The {expand} metatoken kind of suggests that it has something
to do with lists. Which may be beneficial in itself. But
unfortunately, it begs to be expanded upon later. I think I've already
mentioned my ideas on that just yesterday...
{n} :: pluck out the n's word of whatever it is we're expanding.
{-n} :: same as {n}, but working from the other end. Note that in an
[lindex] command, the index could be calculated, meaning that using
sign would require scripts checking manually for overflow. I would
detest seeing substitution allowed within tokens of this variety; if
you want regular substitution, use the regular command tools provided.
A short-hand should be just that, short. In that context, the "end"
becomes redundant, and is just extra clutter, IMHO (also odd since
there's no "start" or something).
{n:m} :: Essentially just short-hand for [lrange]. "end" would
probably be suitable here, Even "5:end-3", would be easier to interpret
than "5:-3"...
{n*m} :: or thereabouts, could then be the {expand}[lrange] version,
which is where it seriously becomes useful. And if the n and m are
optional, it reduces naturally to just {*} which is more obvious than
{}, and not as ugly as the whopper {expand}.
{a,b,c} :: A series of word tokens to extract from the list. There is
still an issue with extraction as a sub-list, or as individual tokens.
On the other hand, it's not hard to wrap it in a [list] to re-fold it
into a sub-list, and there's room for other arguments forming implicit
concatenation, so I don't see that as a huge problem. Unless, of
course, if you had two characters for this purpose too. One indicating
a word-break as opposed to concatenation.
Oh, the reason I'm not particularly worried about sub-list generation by
a list of word indicies, but I am about sub-ranges, is if the two
features are combined, it allows a consecutive series of words to be
easily ripped out with the * notataion, or for part of the old list to
be kept as its own sub-list, among the other words extracted.
Beyond that, perhaps some basic "upper" and "lower", or something,
might be nice shorthands. But nothing with arguments (except the
obvious single value argument), and nothing that would tend to lend
itself to being nested too eagerly. {upper}{1,3*5,7}somevar is already
bad enough. This could get mighty freaky, mighty quick. ;)
My vote at this point, is to stick with the [lindex] and [lrange] curly
shorthands, with the [lrange] one reducing to a shorter form of
{expand}.
Fredderic
Tom Conner
"Don Porter" <d...@nist.gov> wrote in message
news:4q3v0pF...@individual.net...
> Tom Conner wrote:
> > Anyway, to me, the statement, "ActiveTcl already supports {}[...]
notation
> > instead of {expand}", sounds as if stand-alone Tcl 8.5 doesn't support
> > "{}[...] notation". Obviously, that would be terrible if true
>
> It is true. On this point, the beta ActiveTcl distributed by Active
> State is a fork of the TCT source code.
>
> And to repeat the important distinction: ActiveTcl supports the {}
> syntax in addition to, not instead of the {expand} syntax.
>
I didn't see this response since the title was changed, but are you really
saying that there are two "official" versions of Tcl 8.5? If so, this means
that someone can write a program in Tcl 8.5 that will not run in some other
Tcl 8.5 environment. To me, that doesn't make any sense. Hopefully, this
will get resolved before the final release.
Tom Conner
"TCL Warrior" <tclwa...@myway.com> wrote in message
news:1161735180....@i42g2000cwa.googlegroups.com...
Why not use $$, as in
exec $cmd $$args $$[getFileNames]
Uwe Klein
> OTOH... The {expand} metatoken kind of suggests that it has something
> to do with lists. Which may be beneficial in itself. But
> unfortunately, it begs to be expanded upon later. I think I've already
> mentioned my ideas on that just yesterday...
>
................................
> {a,b,c} :: A series of word tokens to extract from the list. There is
> still an issue with extraction as a sub-list, or as individual tokens.
> On the other hand, it's not hard to wrap it in a [list] to re-fold it
> into a sub-list, and there's room for other arguments forming implicit
> concatenation, so I don't see that as a huge problem. Unless, of
> course, if you had two characters for this purpose too. One indicating
> a word-break as opposed to concatenation.
>
> Oh, the reason I'm not particularly worried about sub-list generation by
> a list of word indicies, but I am about sub-ranges, is if the two
> features are combined, it allows a consecutive series of words to be
> easily ripped out with the * notataion, or for part of the old list to
> be kept as its own sub-list, among the other words extracted.
>
Hi Fredderic,
what i miss with the expand feature is something like the reserved commandspace
of the 68k processors. i.e. having a hook to "expand" on expand.
would it be possible to leverage the namespace stuff and tcl introspection?
allow in a general way: {somestuff}$variable and {somestuff}[script ..]
and then:
namespace eval ::expand {
proc dispatcher {pattern result} {
# a reqexp switch fed with two argument
# the pre$ stuff {...} and the result of $ or [] term.
}
proc addpattern {pattern action} ...
proc delpattern pattern ....
proc unknown {pattern res} ....;# starts with a plain [return ${pattern}$res]
proc expand_plain ;# returns $res
proc expand_dont ;- returns [ list $res]
.....
addpattern expand expand_plain
}
add the return lconcat-fashion to the script thas is being assembled.
uwe
Fredderic
Jeff Hobbs <je...@activestate.com> wrote:
> Fredderic wrote:
> > By the sounds of it, ActiveTCL's {} syntax is an uncertainty anyhow,
> > since someone mentioned it was wrapped by a #ifdef...
> >
> > So now that TCL has settled on their syntax, ActiveTCL can simply
> > mark it as a early starter idea that has been replaced by the more
> > heavily debated and agreed apon one from the main tree. Then in a
> > few versions, they can either drop the {} syntax entirely, or
> > maintain it as a deviant extension.
>
> What makes you think that ActiveTcl will keep the {barf^Wexpand}...
> syntax instead of the more concise {}... form?
*shrug* I don't. Though I'd hope they would...
I was, however, responding essentially to what seemed to be someone
else's assertion that TCL should adopt the ActiveTCL way to resolve
ActiveTCL's problem. Which is like expecting the sun to turn itself
down because we've got a whole in the ozone layer.
I've never used it, but from what I've picked up through this
thread, it sounds as though ActiveTCL wanted to get the feature in
early (not uncommon for a commercial product). That kind of action
does, though, often lead to just this kind of issue, and anyone using
such a feature should be doing so on the understanding that it may
change.
Furthermore, if ActiveTCL intends to remain TCL rather than drifting
off into its own little world entirely, they should probably defer to
the main TCL tree wherever possible. That doesn't mean they can't
support both, but accepting whatever comes through in TCL when it's
released would ease their maintenance burden. Which makes sense to me.
In the end, it's just as valid an assertion as the one I was responding
to.
Fredderic
Ralf Fassel
| I suggest
| > exec $cmd {^}$args {^}[getFileNames]
|
| or what I furthuer prefer
| > exec $cmd {%}$args {%}[getFileNames]
This would be ok since {%}$something is invalid code right now, so it
won't break/change current scripts.
| Anyway, in later release we can support dropping the parentheses so
| {^}, can become ^ and for the variables I suggest we even drom the
| $, this is kinda why I was hopping for % instead of ^, so the
| command will look like
|
| > exec $cmd ^args ^[getFileNames]
| or
| > exec $cmd %args %[getFileNames]
This might break current code, as in
set s [list a b]
format %s $s
The plain "^" has special meaning in Tk also (grid command).
So the {} will have to stay IMHO...
R'
Donal K. Fellows
> Why not use $$, as in
> exec $cmd $$args $$[getFileNames]
If we ever change the behaviour of that, it will be to a
double-dereference operation. Anything else is just too strange.
Donal.
Fredderic
Ralf Fassel <ral...@gmx.de> wrote:
> * "TCL Warrior" <tclwa...@myway.com>
> | I suggest
> | > exec $cmd {^}$args {^}[getFileNames]
> | or what I furthuer prefer
> | > exec $cmd {%}$args {%}[getFileNames]
> This would be ok since {%}$something is invalid code right now, so it
> won't break/change current scripts.
> So the {} will have to stay IMHO...
*sigh* It does seem that way, doesn't it...
I like the idea of a single character in place of the word "expand".
Especially if it has an optional start and end value on each side! ;)
Fredderic
Fredderic
Uwe Klein <uwe_klein_...@t-online.de> wrote:
> Fredderic wrote:
> > OTOH... The {expand} metatoken kind of suggests that it has
> > something to do with lists. Which may be beneficial in itself. But
> > unfortunately, it begs to be expanded upon later. I think I've
> > already mentioned my ideas on that just yesterday...
>
> what i miss with the expand feature is something like the reserved
> commandspace of the 68k processors. i.e. having a hook to "expand" on
> expand.
One of my worries, is keeping the braces close enough together that's
it's obvious what's going on. Otherwise, someone trying to track down
a bug will see all this stuff within the braces, and no space after it,
and thinking they know more than they actually do, will go, "AH HUH!
There's the problem!", and add in a space. ;)
It would be interesting to be able to stick all sorts of things in
there... But like my half-regretted comments about {upper} and stuff,
what's the real difference between {upper}[command] and [upper
[command]] where [upper] is a quick proc/alias to [string upper]...?
It might be handy for quickly rolling up short identifier strings
and things, but I'd hate to see it being used any more generally
without a whole new notation that clearly marks it for what it is.
There's plenty of list mapping functions and stuff..... I'm just
interested in the basic case; I can't count the number of procedures I
have that start with a whole bunch of "set x [lindex $l 3]" type lines.
Those [foreach ... break]s are good, but only where the words you want
are in a single fairly neat cluster and it's a strict one word one
variable match up. As it is, I've often had to use a [foreach] with a
couple .'s thrown in as scrap variables, and then still had to pluck
out one or two other terms using the [set] method. eg. terms that are
counted from the end of a $args, or where you want a small cluster of
two or three words as a list. Another common case I face, is where I
want to substitute the first argument of a list, and then [eval] it.
It's not too hard to do with [lreplace], but it'd be easier to be able
to say something like: eval [foo {1}$arglist] extra-arg {1*}$arglist.
So some BASIC list processing would allow you to readily re-arrange
those words you want, and then dump them through to a [foreach]
(or [lset] or whatever) command for collection. Or, another similar
case is when you've wrapped a function that takes a few arguments.
Sometimes you need to slip in an extra argument, or swap two arguments,
or whatever, and that can be a pain to do normally. Say you had a
six-argument command you were wrapping, but you needed to swap the
first and last terms;
command {5,1*4,0,6*end}$arguments
(using * in that context isn't too pretty though)
Fredderic
Uwe Klein
should we start small and write a TIP to
expand [lrange] to accept more than start and end?
or a new list command
[lcut] that accepts things like 1,2,3,4,8-10,end
now having some egg on our faces we could well continue with
lpaste <assemblyinstruction> lista listb ...
i.e.
set la [ list a b c d e f g ]
set ln [ list 1 2 3 4 5 6 7 ]
lpaste {{0 1} {1 1} {1 3-4} {0 4-6}} $la $ln
--> a 1 4 5 e f g
uwe
Robert Hicks
Jeff Hobbs wrote:
> Fredderic wrote:
<snip>
>
> What makes you think that ActiveTcl will keep the {barf^Wexpand}...
> syntax instead of the more concise {}... form?
>
I am not of an opinion about {expand} as I don't do enough Tcl yet. I
would like a clarification though. If (and I guess it is) {expand} is
it and becomes part of the Tcl language are you saying ActiveState
might change that in their distro? Or did I miss you meaning?
Robert
suchenwi
Robert Hicks schrieb:
> I would like a clarification though. If (and I guess it is) {expand} is
> it and becomes part of the Tcl language are you saying ActiveState
> might change that in their distro? Or did I miss you meaning?
>
write {} for {expand}.
Robert Hicks
Okay...my hackles are down now. : )
Robert
TCL Warrior
the only) way to improve the {expand} syntax is to reduce to a single
character inside the {}
So I think what we remains is to decide on this single char. We can
make the character choice a convention, not a rule, Users will be
allowed to write anything inside {}.
so pick your fave
{@} {+} {-} {_} {^} {%} {$} {*} {E} {e} {X} {x} {?} {!}
{ex} {pa} {&}
{.} {|}
I vote for three {+} or {%} or {&}
David Gravereaux
> However, forcing
> {pleaseexpandthenextargument}foo on users was a bad compromise.
exec $cmd {pleaseexpandthenextargument}$args \
{pleaseexpandthenextargument}[getFileNames]
My neck is stuck.. can't turn head.. need to see a chiropractor.
--
David Gravereaux <davy...@pobox.com>
[species:human; planet:earth,milkyway(western spiral arm),alpha sector]
Andreas Leitgeb
> Glenn Jackman <gle...@ncf.ca> wrote:
>> At 2006-10-24 08:13PM, "TCL Warrior" wrote:
>> > > exec $cmd {%}$args {%}[getFileNames]
> Errr, yeah. They're ALL ugly. ;)
Now seeing it proposed a few times I don't find {%} all that bad.
Maybe add it (together with {expand}), then verbosity-preferrers
use {expand} whereas verbosity-avoiders use {%} ...
> {n} :: pluck out the n's word of whatever it is we're expanding.
These proposals look to me as if what is really needed was
some kind of: lpick {<some syntax>} $list]
which then would mostly be used without {%} or {expand}:
lassign [lpick {0,4-6,e10-*} $somelist] v0 v4 v5 v6
--> sets vars and returns last 11 elements.
In those rare cases, where the result of such an lpick is to
be immediately expanded, {%}[lpick ...] isn't too much to ask for.
PS: along with some "human-readable" specification format,
lpick should also accept some kind of list-of-indices,
or list of lists of up to two indices each (for ranges).
Alternatively, lrange could be extended for that.
PPS: I really want to keep separate expansion from extraction.
Mixing these up will lead people to do [list {...}$xyz]
which I find rather a morony (not so much on users part,
but more by the language: by coupling extraction to
expansion and thus make people undo the expansion part with list).
Ralf Fassel
| We can make the character choice a convention, not a rule, Users
| will be allowed to write anything inside {}.
I would not recommend this.
We can use {} now since it was not taken before. This would not be
possible if TCL decided earlier to treat the empty list {} as a 'de
facto non-existing token', reducing '{}foo' to 'foo' during the
parsing stage.
Likewise, if you now allow anything in {} to mean 'expansion', it will
not be possible to introduce other features later which also use {}.
R'
David Gravereaux
> On 24 Oct 2006 11:19:55 GMT,
> Andreas Leitgeb <a...@gamma.logic.tuwien.ac.at> wrote:
>
>> Fredderic <put_my_n...@optusnet.com.au> wrote:
>>> An unlikely extra character (ie. the backtick)
>>> added immediately after the $ substitution token,...
>> ... is still hardly visible at all in most fonts.
>
> But it's far more visible following a $-sign, than a space. Dollar
> signs aren't often followed by space, so one tends to look a little
> closer. At least, that's what I've found.
>
>
>> Also, what would have been your choice for doing expanded
>> command-substitution? I can't think of anything analoguous
>> to $<newchar>varname ...
>
> Heck, why not just the same thing? Why does there HAVE to be a
> uniquely command-based equivalent? Commands are a duel-token recursive
> syntax, where {expand} isn't, and nor is the $-sign. So just make it
> a direct replacement of {expand}... It's not 100% intuitive, but then
> neither would be the equally strange interpretation of trying to expand
> a literal word as a list. Personally, I'd feel quite comfortable with
> $`[command].
>
>
>>> "$`" is also far more noticeable than this tiny little backtick
>>> all on its own in front of a heap of text.
>> That's right, of course, but imho still not enough.
>
> Well, I think the point of this thread, at least for me, was to not end
> up with too much. ;)
>
> It's frequently stated that the $ token itself has always been a
> short-cut to [set], rather than a distinctly TCLish entity. It already
> has its own semantics that distinguish it from its command roots. It's
> already defined to have very simple and limited syntax. And there's
> not that many things that tend to follow a $-sign naturally. It's also
> very nearly universal from what I can tell, to anyone who's done any
> form of basic, shell scripting, any of several scripting languages,
> etc. It's there, it's visible, it's already outside of the usual TCL
> idioms, and I've never in my life, seen the string "$`" used in output.
>
>
> Fredderic
I like your idea. $* or $^ or $@ come to mind first off for me. Are
variable names limited to alpha numerics for the first char like in C?
If so, it might be an easy squeeze. Is it an easy shoehorn into the parser?
% set * foo
foo
% puts $*
$*
% set *
foo
%
Hmm.. It works the command way, but dollar substitution doesn't work.
There might be a hole to fill with new behavior in this space after all.
Fredderic
Uwe Klein <uwe_klein_...@t-online.de> wrote:
> or a new list command
> [lcut] that accepts things like 1,2,3,4,8-10,end
Well, in that case, it wouldn't need to have commas, would it?
lcut $list 1-4 8-10 end
Might be a handy command, actually. Though I suspect in most cases
where I'd use such a command, doing it the old fashioned manual way
would still be quicker. It'd need to be TIP'd to go into core where
it can be heavily optimised.
I still think it'd be a great addition to plug in ala {expand}...
People have proposed array-like access to lists before, but I don't
think $list{4} is a good idea. {4}$list at least won't break anything,
for the same reasons {expand}$list wouldn't.
> now having some egg on our faces we could well continue with
Personally, I use napkins at times like that. Never go on the internet
without one. That's a good idea too. ;)
> lpaste <assemblyinstruction> lista listb ...
Assembly instruction? Gee. And there I thought you were being
serious. ;)
Fredderic
Uwe Klein
> On Wed, 25 Oct 2006 13:26:06 +0200,
> Uwe Klein <uwe_klein_...@t-online.de> wrote:
>>now having some egg on our faces we could well continue with
>
>
> Personally, I use napkins at times like that. Never go on the internet
> without one. That's a good idea too. ;)
being bearded, my menu is never far away.
Fredderic
Andreas Leitgeb <a...@gamma.logic.tuwien.ac.at> wrote:
> Fredderic <put_my_n...@optusnet.com.au> wrote:
> > Glenn Jackman <gle...@ncf.ca> wrote:
> >> At 2006-10-24 08:13PM, "TCL Warrior" wrote:
> >> > > exec $cmd {%}$args {%}[getFileNames]
> > Errr, yeah. They're ALL ugly. ;)
>
> Now seeing it proposed a few times I don't find {%} all that bad.
> Maybe add it (together with {expand}), then verbosity-preferrers
> use {expand} whereas verbosity-avoiders use {%} ...
I have to say, if there's enough rejection of a useful element-ripper
format, then either {%} or {*} would have to be my favourite
alternative to {expand} too... Personally, though, I'd go for {*}...
> > {n} :: pluck out the n's word of whatever it is we're expanding.
> These proposals look to me as if what is really needed was
> some kind of: lpick {<some syntax>} $list]
> which then would mostly be used without {%} or {expand}:
> lassign [lpick {0,4-6,e10-*} $somelist] v0 v4 v5 v6
> --> sets vars and returns last 11 elements.
> In those rare cases, where the result of such an lpick is to
> be immediately expanded, {%}[lpick ...] isn't too much to ask for.
I agree... It'd probably work quite well. Though I'd put the index
list at the end ala [lindex] and [lrange], and do away with the commas.
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.
> PS: along with some "human-readable" specification format,
> lpick should also accept some kind of list-of-indices,
> or list of lists of up to two indices each (for ranges).
> Alternatively, lrange could be extended for that.
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.
> PPS: I really want to keep separate expansion from extraction.
> Mixing these up will lead people to do [list {...}$xyz]
> which I find rather a morony (not so much on users part,
> but more by the language: by coupling extraction to
> expansion and thus make people undo the expansion part with list).
Heck. They'll do that anyhow. And that [list] example makes more sense
when you start adding more variables into the mix.
Mind you, I do agree with your point about not mixing them... The
{...} notation, whatever it is, should always result in a bunch of
words being expanded on the argument list. Which makes my idea of
[foreach] slightly flawed... You'd need to wrap it back into a list
like that. 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
(I've got one script which is absolutely full of that sort of thing..!)
Fredderic
Fredderic
Uwe Klein <uwe_klein_...@t-online.de> wrote:
> Fredderic wrote:
> > On Wed, 25 Oct 2006 13:26:06 +0200,
> > Uwe Klein <uwe_klein_...@t-online.de> wrote:
> >>now having some egg on our faces we could well continue with
> > Personally, I use napkins at times like that. Never go on the
> > internet without one. That's a good idea too. ;)
> being bearded, my menu is never far away.
Ahhh yes. Wouldn't want anyone to catch you hiding your food for later.
Fredderic
Fredderic
Ralf Fassel <ral...@gmx.de> wrote:
> * "TCL Warrior" <tclwa...@myway.com>
> | We can make the character choice a convention, not a rule, Users
> | will be allowed to write anything inside {}.
> I would not recommend this.
Have to agree there... In very big writing, too!
> Likewise, if you now allow anything in {} to mean 'expansion', it will
> not be possible to introduce other features later which also use {}.
Not that it matters much... Many people are too scared of using it
anyhow.
Fredderic
Donald Arseneau
> * "TCL Warrior" <tclwa...@myway.com>
> | > exec $cmd ^args ^[getFileNames]
>
> The plain "^" has special meaning in Tk also (grid command).
That does not conflict, because for grid, the ^ is the entire word,
not a prefix.
--
Donald Arseneau as...@triumf.ca
Andreas Leitgeb
> 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...
>> 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 :-) 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)
>> 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]
> 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
First you're comparing no-expansion-at-all-syntax with
your proposed change of 8.5-expansion-syntax. That's unfair
because the "up to 8.4"-way *IS* ugly.
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!
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.
Fredderic
Andreas Leitgeb <a...@gamma.logic.tuwien.ac.at> wrote:
> Fredderic <put_my_n...@optusnet.com.au> 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
Kaitzschu
> On 25 Oct 2006 19:13:29 GMT, Andreas Leitgeb
> <a...@gamma.logic.tuwien.ac.at> wrote:
>
> > Fredderic <put_my_n...@optusnet.com.au> wrote:
> > >
> > > 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.
Yes, but the [eval] in the beginning would tear your expanded thingies
apart and do its magic. Unless you didn't mean there to be an [eval].
--
-Kaitzschu
s="TCL ";while true;do echo -en "\r$s";s=${s:1:${#s}}${s:0:1};sleep .1;done
Donal K. Fellows
> 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.
You seem to be very confused. Let's examine that example, which can be
rewritten like this:
set foo "{expand}"; set bar [concat command $foo\$list]; eval $bar
That will do exactly the same thing, except for leaving the
intermediate script in a variable where we can look at it. If we do
just that, we see that it contains this:
command {expand}$list
When that's run through the interpreter (which is what [eval] does)
then the expansion is going to happen (and the resulting list will end
up as argument to the command [command] of course). The interpreter
does not know or care that the {expand} wasn't a literal in the
original script; you explicitly told it to evaluate the string as a
script. :-)
Donal.
Fredderic
> Fredderic wrote:
> > 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.
> You seem to be very confused. Let's examine that example, which can be
> rewritten like this:
> set foo "{expand}"; set bar [concat command $foo\$list]; eval $bar
*nods* I seemed to have a mind-lapse that day with regard to the
[eval] command... ;) (Probably because I've been working exclusively
in C for about the past month.)
Is *IS* doing what I believed it should be doing, and isn't doing what
I was afraid the previous poster was suggesting. What I was thinking
was being said, was that it would work without that [eval] in front. ie.
just "command $foo\$list" would {expand} $list since foo contains the
text "{expand}", and that possibly he was suggesting that the \$ would
cause some kind of black magic to occur, or something. ;)
> When that's run through the interpreter (which is what [eval] does)
> then the expansion is going to happen. The interpreter does not know
> or care that the {expand} wasn't a literal in the original script;
> you explicitly told it to evaluate the string as a script. :-)
*nods* I hear an announcement in the distance... " The Infinite
Improbability drive has been shut down, normality is restored, Mr.
Penguin. Now off we go to those buildings, washing up and down in the
distance..... " Ahhh..... All's well again. :)
Mr. Penguin
Andreas Leitgeb
> 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
Exactly this is the case with 8.5, but *only* because you added
the "eval" before "command". I read the subthread already,
where you pointed out the misunderstanding :-)
> 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.
There is another subtle misconception:
You seem to think (or: have thought) that what the parser does
itself is automatically faster, than when it is done through a
command.
The bytecompiler can even bytecode-compile a phrase like
[expr {$a+1}] to direct bytecode.
If the parser could handle {1-4}$list more efficient than
{expand}[lrange $list 1 4], then it could also bytecompile
the latter to former's equivalent.
Whether the shorter code is enough to justify the new syntax,
is ultimately TCT's judgement. But it's not a question of
speed of generated bytecode.
Fredderic
Andreas Leitgeb <a...@gamma.logic.tuwien.ac.at> wrote:
> Fredderic <put_my_n...@optusnet.com.au> wrote:
> > 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.
> The bytecompiler can even bytecode-compile a phrase like
> [expr {$a+1}] to direct bytecode.
> If the parser could handle {1-4}$list more efficient than
> {expand}[lrange $list 1 4], then it could also bytecompile
> the latter to former's equivalent.
Hmmm..... Perhaps. Still, while I firmly believe the structure
{1-4}$list would be rather handy to have available, I personally dread
seeing:
set from-here 1
set to-here 4
puts {${from-here}-${to-here}}$list
or
set sub-range 1-4
puts {${sub-range}}$list
popping up in scripts... Even if it's not a matter of efficiency... :)
It's my opinion that the {} construct should be used for more than JUST
{expand}, but not much more, and it should be kept painfully clear what
it IS doing. The only way to do that, is to ensure that if people want
to use variable substitution within it, then they do so using the
regular commands (or convoluted string manipulations and the [eval]
command, in which case nothing they do will be legible anyhow ;) ).
Fredderic
Andreas Leitgeb
> and it should be kept painfully clear what it IS doing.
Now that (purposefully deprived of its context :-) could be
taken as a vote for "current {expand} and nothing else" :-)
This statement would even vote against {%}...
I wouldn't exclude the possibility that at some time
someone comes up with a good idea as to what else
to do in "curly-syntax".
The Gap finally closed with {expand} is more than 10 years old.
(back in 1995 I proposed &var for expanding var-subst - I didn't
care enough much about command-substitution and compatibility back
then)
So I boldly assume it might take at least another 5 years starting
only at the point when another real gap is identified, until it is
closed with a new syntax. :-)
Fredderic
Andreas Leitgeb <a...@gamma.logic.tuwien.ac.at> wrote:
> Fredderic <put_my_n...@optusnet.com.au> wrote:
> > and it should be kept painfully clear what it IS doing.
> Now that (purposefully deprived of its context :-) could be
> taken as a vote for "current {expand} and nothing else" :-)
> This statement would even vote against {%}...
You're an evil, evil person...
I didn't mean so simple the monkeys in the zoo can figure it out. Just
that if it's going to be used, keep it short and concise. A few
numbers and a sprinkling of punctuation within curly braces, but
absolutely no variable/command substitution and such.
Anyhow... I think this thread's been about talked out now... It's
been fun. :)
Fredderic
Fredderic
Fredderic <put_my_n...@optusnet.com.au> wrote:
> On 30 Oct 2006 17:43:17 GMT,
> Andreas Leitgeb <a...@gamma.logic.tuwien.ac.at> wrote:
>
> > Fredderic <put_my_n...@optusnet.com.au> wrote:
> > > and it should be kept painfully clear what it IS doing.
> > Now that (purposefully deprived of its context :-) could be
> > taken as a vote for "current {expand} and nothing else" :-)
> > This statement would even vote against {%}...
Oh, there is one point that just came to mind. There's talk of
extending the end-n notation in [lindex] and [lrange] (and others) for
general substitution and offset. It's mostly in the spirit of those
changes that I originally started arguing this thread.
I likewise appreciate the idea, and will most certainly find it very
useful, but am none the less hoping [lindex] doesn't start supporting
$a-$b*$c+$d as its index. :)
Fredderic
Andreas Leitgeb
> Oh, there is one point that just came to mind. There's talk of
> extending the end-n notation in [lindex] and [lrange] (and others) for
> general substitution and offset. It's mostly in the spirit of those
> changes that I originally started arguing this thread.
>
> I likewise appreciate the idea, and will most certainly find it very
> useful, but am none the less hoping [lindex] doesn't start supporting
> $a-$b*$c+$d as its index. :)
Afaik, this is limited to single "+" and "-" operations with
possibly signed arguments. e.g -5+42, 2--4, ...
There are two things I'd like to see for lrange:
1.) allow to give more ranges, that are concat'ed
[lrange {a b c d e} 0 1 3 4] -> {a b d e}
2.) allow "relative" end-indices:
[lrange {a b c d e} 2 s+1] -> {c d}
"s" being an anchor like "end", but referring to the
previously given start-index. Based on my own code,
this would not only save lots of [expr]'ing already,
but also lots of intermediate saving to vars:
set v [...]; ... [lrange $list $var [expr {$var+42}]];
PS: this subthread is no longer about tcl-syntax.