eval is evil (for spreading list-arguments)
Andreas Leitgeb
Just now, reading the docs for MetaKit, I stumbled over the
following example:
puts [eval format {%-20s %d} [mk::get db.phonebook!2 name date]]
See the mistake ?
At first glance, or just because I indicated that there is one ?
The format-specifier also gets torn apart by eval.
It would require doubled brace-quoting for use with eval.
--
Nichts ist schlimmer als zu wissen, wie das Unheil sich entwickelt,
und voll Ohnmacht zusehn muessen - das macht mich voellig krank...
-- (Musical Elisabeth; "Die Schatten werden laenger")
Ralf Fassel
| The format-specifier also gets torn apart by eval.
| It would require doubled brace-quoting for use with eval.
But is `eval' to blame for that? Or rather the programmer who does
not do his homework?
R'
Jeffrey Hobbs
> Yes, it's a frequently recurring topic.
>
> Just now, reading the docs for MetaKit, I stumbled over the
> following example:
> puts [eval format {%-20s %d} [mk::get db.phonebook!2 name date]]
>
> See the mistake ?
> At first glance, or just because I indicated that there is one ?
Well, I saw the mistake immediately, which is why I always write my
evals now pedantically, like so:
eval [list format {%-20s %d}] [mk::get get db.phonebook!2 name date]
Anything that should not be broken apart should be list'ed.
--
Jeff Hobbs The Tcl Guy
Senior Developer http://www.ActiveState.com/
Tcl Support and Productivity Solutions
Andreas Leitgeb
Are pitfalls to blame, or just those people who fall into them ?
(And it shows, that it's not only newbies who fall, but also
long-term tcl-seniors, who just happen to have been less than
hard-concentrating while using "eval")
A few years ago, a proposal has been made to alleviate this particular
pitfall, by adding some new syntax to the Tcl-core (backwards-compatibly).
Not only would that offer an obvious way *around* this pitfall
(compared to the "eval-way" leading *straight over* it, expecting you
to jump over it), it would also offer object-safety in many cases where
eval still does not. Also, using it adds less visual "line-noise"
than [list ...]-wrapping.
There have been long threads about it, in the past. From time to time,
if some sighting of someone falling into that pitfall triggers me, I
cast another poll here to see, if time is finally mature for improving
tcl-syntax.
PS: there are also safe and useful uses for "eval".
Expansion of lists, however, is a dangerous one.
Ralf Fassel
| Are pitfalls to blame, or just those people who fall into them ?
If you fall once, blame the pitfall, and remember the pit. If you
fall often into the same pit, well... ;-)
| A few years ago, a proposal has been made to alleviate this
| particular pitfall, by adding some new syntax to the Tcl-core
| (backwards-compatibly).
Would be fine with me. Just make it obvious enough so that someone
who is used to the current behaviour does not easily fall into *that*
pit. If I have to add extra arguments or simply use a new name, that
should be enough to trigger my attention to not double-list the
`new-eval' arguments, for example.
| Also, using it adds less visual "line-noise" than [list
| ...]-wrapping.
Well, in this particular example,
eval format {{%d foo}} [some_other_func]
is not too much line-noise IMHO. But of course, there are other cases
where you have to use an extra `list'.
| PS: there are also safe and useful uses for "eval".
| Expansion of lists, however, is a dangerous one.
Expanding lists is the primary use of `eval' for me :-/
Why would I use `eval' otherwise?
R'
Andreas Leitgeb
> * Andreas Leitgeb <Andreas...@siemens.at>
>| Are pitfalls to blame, or just those people who fall into them ?
> If you fall once, blame the pitfall, and remember the pit. If you
> fall often into the same pit, well... ;-)
watching many others (and surely not only newbies) fall in.
Doing Tcl for almost 10 years now, I'm kind of used to it, too.
I still find eval-lines ugly, however.
>| A few years ago, a proposal has been made to alleviate this
>| particular pitfall,
> should be enough to trigger my attention to not double-list the
> `new-eval' arguments, for example.
You seem to be relatively new to this group :-)
Based on the observation that with eval, programmers *really often*
protect too little rather than too much, the proposal was primarily
about "doing something" with the args that should be *expanded*, rather
than protecting all that is to be left as is.
Then, as it is not allowed in current tcl to have trailing characters
after a close-brace, compatibility is guaranteed, if the special
behaviour is triggered by something like {}$ or {}[...].
(Other suggestions were to use e.g. &varname as the "expanding
version of $varname", but that would have caused lots of
migration-headaches) Thus, the first proposal was to add
new syntax {}[command_returning_a_list] and {}$list_variable
to expand the values to multiple arguments.
Various commands that take an arbitrary number of arguments could
then be directly passed a list, spread out into several separate
arguments.
Further discussions showed a general preference to something less
noisy than three special-chars in a row (which seemed too perl'ish),
which led to the still pending proposal of {expand}$varname and
{expand}[command...]
instead of
eval [list command $all [the] $non-expanding [arguments]] $list
one would write:
command $all [the] $non-expanding [arguments] {expand}$list
and gain the following advantages:
a) the "real" command is back at the start of the line, rather than
obscured from sight by eval&list
b) in many cases conversion to and from string can be avoided
(keyword: object-safety). Meanwhile the "eval" has evolved
to avoid this conversion, too, but special care must be taken
to not accidentally thwart it. (That's why the old example uses
[list ...] rather than curlies.)
c) it's much more *un*likely to make a mistake by specifying
{expand} too often, than to list-protect to little.
Most often, in practise you'll find above example written as:
eval command $all [the] $non-expanding [arguments] $list
under the weak assumption, that each of the other vars or commands
evaluate to "nice" values immune to eval's reparsing. Such mistakes
happen easily, and are Tcl's weak point just like wild pointers
are C-programs' #1-cause for random failure.
Recently, TIP #103 has gone some way in the right direction,
but failed to provide advantage "a)" (see above).
>| PS: there are also safe and useful uses for "eval".
>| Expansion of lists, however, is a dangerous one.
> Expanding lists is the primary use of `eval' for me :-/
> Why would I use `eval' otherwise?
For interpreting real scripts. Tk-widget bindings make frequent
use of eval. Outside these uses, I cannot currently think of
any other, but surely there exist more.
It is used for argument expansion, because, as of now, no other
way exists to do argument expansion.
se...@fishpool.com
>
> A few years ago, a proposal has been made to alleviate this particular
> pitfall, by adding some new syntax to the Tcl-core (backwards-compatibly).
> Not only would that offer an obvious way *around* this pitfall
> (compared to the "eval-way" leading *straight over* it, expecting you
> to jump over it), it would also offer object-safety in many cases where
> eval still does not. Also, using it adds less visual "line-noise"
> than [list ...]-wrapping.
Who was it who suggested the following form for expand?
expand <list>
I think the idea was that this works partly like eval, but no variable
subtitution or anything is done for <list>. Ie. one level is dropped
off and that's it. So the following would always work as espected:
set foo {puts blah}
expand $foo
Seemed to take care of most issues.
Andreas Leitgeb
While argument-expansion really is not much more than "dropping
off a level of quoting", the important difference is the scope.
To be really useful, the flattening must only happen to those
arguments, for which it is explicitly "requested", rather than
to all that aren't explicitly protected.
Dan Smart
news:slrnb6hk1s.ddm....@pcc524.gud.siemens.at:
> time, if some sighting of someone falling into that pitfall triggers
> me, I cast another poll here to see, if time is finally mature for
> improving tcl-syntax.
Actually you are looking for a significant change in TCL's *semantics*.
</pedant>
And the proposed syntax (constrained as it is by backwards compatibility)
is an ugly wart, not an "improvement".
>
> PS: there are also safe and useful uses for "eval".
> Expansion of lists, however, is a dangerous one.
All uses of eval require care, even with a perfectly well formed list, if
the first word is 'exec', you may still not be safe.
Dan "eval [list [file delete [info script]]]" Smart
--
Dan Smart. C++ Programming and Mentoring.
cpp...@dansmart.com
ADDvantaged
Donald Arseneau
> Andreas Leitgeb <Andreas...@siemens.at> wrote:
> >
> > A few years ago, a proposal has been made to alleviate this particular
> > pitfall, by adding some new syntax to the Tcl-core (backwards-compatibly).
> > Not only would that offer an obvious way *around* this pitfall
> > (compared to the "eval-way" leading *straight over* it, expecting you
> > to jump over it), it would also offer object-safety in many cases where
> > eval still does not. Also, using it adds less visual "line-noise"
> > than [list ...]-wrapping.
>
> Who was it who suggested the following form for expand?
>
> expand <list>
There has been much discussion (use google/groups), and a minimalist
solution proposed by Peter Spjuth and Donal K. Fellows:
TIP #103: Argument Expansion Command,
http://www.tcl.tk/cgi-bin/tct/tip/103.html
Please have a look at how that would affect the present pitfall, and
provide some feedback for the Tip. I think it would be written
puts [expand {format {%-20s %d} @[mk::get db.phonebook!2 name date]} ]
to work successfully.
Donald Arseneau as...@triumf.ca
Suchenwi
>PS: there are also safe and useful uses for "eval".
> Expansion of lists, however, is a dangerous one.
Well, but before we have extended the Tcl syntax with an "expand" construct,
it's the only half-ways readable way...
Consider the great idiom:
eval pack [winfo children $w]
This can only be done with explicit eval. I think one avoids most pitfalls by
remembering that [eval] just like [join] removes one level of grouping, so just
add one level with [list ...] where necessary.
Best regards, Richard Suchenwirth
se...@fishpool.com
> se...@fishpool.com <se...@fishpool.com> wrote:
>> Ie. one level is dropped off and that's it.
>> Seemed to take care of most issues.
> Nope, it didn't.
>
> While argument-expansion really is not much more than "dropping
> off a level of quoting", the important difference is the scope.
>
> To be really useful, the flattening must only happen to those
> arguments, for which it is explicitly "requested", rather than
> to all that aren't explicitly protected.
And how does the explained not do that? Only the first list level is
opened up. No other expansion was done in that model.
expand [list button .b] $options
The above should do what we expect in all situations. The $options list
is opened up once as arguments, but nothing inside it is ever expanded.
Surely it's a matter of taste whether it's better to explicitly mark
areas for expansion or for protection? The above system avoids having
new magic characters.
se...@fishpool.com
>>
>> Who was it who suggested the following form for expand?
>>
>> expand <list>
>
> There has been much discussion (use google/groups), and a minimalist
> solution proposed by Peter Spjuth and Donal K. Fellows:
> TIP #103: Argument Expansion Command,
> http://www.tcl.tk/cgi-bin/tct/tip/103.html
Yes, I've seen the TIP and followed the discussion ;-)
>
> Please have a look at how that would affect the present pitfall, and
> provide some feedback for the Tip. I think it would be written
>
> puts [expand {format {%-20s %d} @[mk::get db.phonebook!2 name date]} ]
With the other expand proposal that would work:
puts [expand [list format {%-20s %d}] [mk::get db.phonebook!2 name date]]
Not quite sure what you wanted commented in the TIP. I could add the above
suggestion there, but I'd prefer if the original inventor did that so I
don't get it wrong. I just can't remember who was talking about it on
IRC.
Andreas Leitgeb
> Andreas Leitgeb <Andreas...@siemens.at> wrote:
>> To be really useful, the flattening must only happen to those
>> arguments, for which it is explicitly "requested", rather than
>> to all that aren't explicitly protected.
Was it really that unintellegible ?
The misinterpretations might stem from my programmer's view to
it, as opposed to the Tcl-interpreter's view to it:
For Tcl, the first argument to eval in
% eval [list destroy] [winfo children .]
is just plain the result of the list-command. Nothing special.
One level of *everything* is dropped, so what finally gets to
work is the original "destroy" and each of the returned child-widget
names separately.
For a programmer, otoh, this [list ...] is a protection-wrapper
around the string "destroy", to make eval see it as a list.
For the programmer, this [list ...] construct is not part of
the program's logic. It's some magic salt that he has learnt
to add, to make things work.
In the programmer's mind there is the command "destroy", and
the command that returns the list of .'s childs. To tie these
together, he now has to add one list-level to all those parts
that already were at the "correct" quoting-level before, and then
let eval remove one level of *all* the arguments, merely undoing
the "protection" for the "destroy".
For the programmer it would be like "avoiding a detour" to be able
to express: "I want only the widget-list spreaded, the rest untouched."
This part of the whole story fortunately got addressed with
TIP 103 as in: expand {destroy @[winfo children .]}
The other part, namely getting the "destroy" command to
the start of the line, is something, TIP 103 does not
address.
As it seems, TIP 103 is at least the best we can get to for the time.
> No other expansion was done in that model.
> expand [list button .b] $options
This would be practically equivalent to the "eval"-approach.
The pitfall would be indeed a tiny bit narrower, but still large enough
for the example in the first posting of this thread to still fall in.
Btw., that example was not that of a newbie, but taken from the
documentation of "MK4tcl", the Tcl-bindings to metakit.
> Surely it's a matter of taste whether it's better to explicitly mark
> areas for expansion or for protection?
Not a matter of taste, but a matter of narrowing a pitfall,
... of making Tcl programmer-friendlier.
And that's the whole point of this thread, by the way.
> The above system avoids having new magic characters.
Braces were "magic" even before :-)
Otoh, the "@" as used in TIP 103 wasn't magic in Tcl before.
The association of "@" with "list" is entirely perl'ish ;-)
Andreas Leitgeb
> There has been much discussion (use google/groups), and a minimalist
> solution proposed by Peter Spjuth and Donal K. Fellows:
> TIP #103: Argument Expansion Command,
> http://www.tcl.tk/cgi-bin/tct/tip/103.html
>
> Please have a look at how that would affect the present pitfall,
Yes, it would definitely fix it.
> and provide some feedback for the Tip.
I'd even prefer {}$var instead of @$var inside the braced argument
of expand, for it's "*forward*-compatibility" (see TIP), but with
"@" it is still much better than nothing.
Any estimates about when this TIP will undergo the judgement of
the TCT ?
Bryan Oakley
> Donald Arseneau <as...@triumf.ca> wrote:
>
>>There has been much discussion (use google/groups), and a minimalist
>>solution proposed by Peter Spjuth and Donal K. Fellows:
>>TIP #103: Argument Expansion Command,
>> http://www.tcl.tk/cgi-bin/tct/tip/103.html
>>
>>puts [expand {format {%-20s %d} @[mk::get db.phonebook!2 name date]} ]
>
> It's *much* better than the current status quo.
>
>
>>Please have a look at how that would affect the present pitfall,
>
> Yes, it would definitely fix it.
How would it fix it? It would still be available for people who choose
to use it. The proposal simply provides an alternative to the "pitfall";
it doesn't remove or fix the pitfall.
Donal K. Fellows
> There have been long threads about it, in the past. From time to time,
> if some sighting of someone falling into that pitfall triggers me, I
> cast another poll here to see, if time is finally mature for improving
> tcl-syntax.
Having thought about this long and hard (including looking through the possible
alternatives) my favoured alternative is a single extra rule added to Tcl(n):
If the first character of a word is back-quote (```'') then the rest of
the word (as determined by the other rules, including the double-quote
and open brace rules) is interpreted as a list and each of the words is
appended to the list of words to be passed to the command as a separate
word. No further expansion is performed on those words, and nor is the
back-quote character part of any word.
The idea is that this allows for expansion to be performed exactly where the
programmer wants, and nowhere else, as well as putting the emphasis clearly on
what is being executed for real instead of the machinery to make everything be
expanded as we want. It's also much prettier than the {} hack. In the current
example of the hour, this would allow things to be written as:
format {%-20s %d} `[mk::get get db.phonebook!2 name date]
The choice of back-quote? This is enforced by the fact that most other
characters are far more common in Tcl scripts (e.g. @ is used for a number of
things throughout Tk, as well as being commonplace in places like email
addresses...)
Bet someone's going to hate this idea though. C'est la vie.
> PS: there are also safe and useful uses for "eval".
> Expansion of lists, however, is a dangerous one.
Minor correction: It's safe, but only if you're seriously paranoid.
Donal.
--
Donal K. Fellows http://www.cs.man.ac.uk/~fellowsd/ donal....@man.ac.uk
"If RedHat are so purblind that they think computing is about ever fancier
'desktop themes', they are in the interior design business, and as everyone
knows, if you can piss you can paint." -- Steve Blinkhorn
Andreas Leitgeb
>> Yes, it would definitely fix it.
> How would it fix it? It would still be available for people who choose
> to use it. The proposal simply provides an alternative to the "pitfall";
> it doesn't remove or fix the pitfall.
You're right. This requires overloading of the verb "fix" as:
to fix a pitfall :=
to offer an obvious alternative way around the pitfall.
;-)
Roy Terry
> If the first character of a word is back-quote (```'') then the rest of
> the word (as determined by the other rules, including the double-quote
> and open brace rules) is interpreted as a list and each of the words is
> appended to the list of words to be passed to the command as a separate
> word. No further expansion is performed on those words, and nor is the
> back-quote character part of any word.
>
The following ought to be a high priority for
any programming language that aspires to ease of use
and certainly Tcl qualifies:
> The idea is that this allows for expansion to be performed exactly where the
> programmer wants, and nowhere else,
> format {%-20s %d} `[mk::get get db.phonebook!2 name date]
>
> The choice of back-quote? This is enforced by the fact that most other
> characters are far more common in Tcl scripts (e.g. @ is used for a number of
> things throughout Tk, as well as being commonplace in places like email
> addresses...)
>
Hhmm. At first I didn't like this but on second look it gets better
and better. Grepping 100K lines of nearby Tcl code turns up only a one
backquotes and not at word beginning. It's definitely way better than
adding a new command, which is merely a crutch and a bandaid,
and it really assists writing concise code.
IOW: A big win.
Roy
(Cheers and waves from sidelines ;*)
se...@fishpool.com
> For Tcl, the first argument to eval in
> % eval [list destroy] [winfo children .]
> is just plain the result of the list-command. Nothing special.
> One level of *everything* is dropped, so what finally gets to
> work is the original "destroy" and each of the returned child-widget
> names separately.
Just in case it wasn't clear, with the proposed [expand] you would
not need a [list] around the destroy there. I don't find it particularly
confusing to have the idea "remove one list level and execute command".
I do, however, accept your reasoning for the reverse. I just have a natural
fear of adding new special characters (even though they are only
command-specific) -- can end up in nasty mistakes when you're not expecting
it: a variable starts with @ and the programmer doesn't know it.
lvi...@yahoo.com
According to Donal K. Fellows <donal.k...@man.ac.uk>:
:Having thought about this long and hard (including looking through the possible
:alternatives) my favoured alternative is a single extra rule added to Tcl(n):
Hmm - along with adding this rule, some code has to be added to the interpreter
to deal with the back quote, right?
--
Join us at the Tenth Annual Tcl/Tk Conference <URL: http://mini.net/tcl/6274 >
Even if explicitly stated to the contrary, nothing in this posting
should be construed as representing my employer's opinions.
<URL: mailto:lvi...@yahoo.com > <URL: http://www.purl.org/NET/lvirden/ >
Bryan Oakley
> Andreas Leitgeb wrote:
>
>>There have been long threads about it, in the past. From time to time,
>>if some sighting of someone falling into that pitfall triggers me, I
>>cast another poll here to see, if time is finally mature for improving
>>tcl-syntax.
>
>
> Having thought about this long and hard (including looking through the possible
> alternatives) my favoured alternative is a single extra rule added to Tcl(n):
>
> If the first character of a word is back-quote (```'') then the rest of
> the word (as determined by the other rules, including the double-quote
> and open brace rules) is interpreted as a list and each of the words is
> appended to the list of words to be passed to the command as a separate
> word. No further expansion is performed on those words, and nor is the
> back-quote character part of any word.
Is there a reason you chose a single leading character rather than a
pair of characters, such as a pair of single quotes, or pair of
backquotes (eg: command foo '$bar' baz) There's precidence for either ($
is a single char, "", {} and [] are used in pairs).
Tom Wilkason
news:3E6C9E26...@man.ac.uk...
arguments rather than the other way around (i.e. specifying the ones that
shouldn't be).
Has anyone looked into the core to see if something like this a relatively
easy solution to implement? When I first thought about this problem I
thought a good way to handle it would be something like:
format {%-20s %d} [unlist [mk::get get db.phonebook!2 name date]]
But from an implementation point of view I don't think it is feasable since
all function calls are structured to return a single object.
Another consideration, what should be the result of:
set A `[mk::get get db.phonebook!2 name date]
Should it throw a syntax error such as "set a 1 2 3" would?
Tom Wilkason
Suchenwi
>Another consideration, what should be the result of:
>set A `[mk::get get db.phonebook!2 name date]
>Should it throw a syntax error such as "set a 1 2 3" would?
Yes, I strongly think so - substitution is a separate step from command
invocation, so it should react (with the same error message) as
eval [list set A] [mk::get get db.phonebook!2 name date]
does now.
--
Best regards, Richard Suchenwirth
Donal K. Fellows
> Hmm - along with adding this rule, some code has to be added to the
> interpreter to deal with the back quote, right?
No, the english specification in Tcl(n) just magically manifests itself as
implementation. :^D
Donal.
--
Donal K. Fellows http://www.cs.man.ac.uk/~fellowsd/ donal....@man.ac.uk
-- Thanks, but I only sleep with sentient lifeforms. Anything else is merely
a less sanitary form of masturbation.
-- Alistair J. R. Young <avatar...@arkane.demon.co.uk>
Donal K. Fellows
> Is there a reason you chose a single leading character rather than a
> pair of characters, such as a pair of single quotes, or pair of
> backquotes (eg: command foo '$bar' baz) There's precidence for either ($
> is a single char, "", {} and [] are used in pairs).
Personal preference and the fact that I think of ` as flagging the word for
different treatment (as opposed to `` containing different treatment of a word.)
In fact, if you have something that "brackets" things, then you have to state
what happens if you have more than one word inside.
*thinks*
I suppose you could make `` act like double quotes except with expand-to-words
behaviour. That'd work...
Donal.
--
Donal K. Fellows http://www.cs.man.ac.uk/~fellowsd/ donal....@man.ac.uk
Peter.DeRijk
> Andreas Leitgeb wrote:
>> Yes, it's a frequently recurring topic.
>>
>> Just now, reading the docs for MetaKit, I stumbled over the
>> following example:
>> puts [eval format {%-20s %d} [mk::get db.phonebook!2 name date]]
>>
>> See the mistake ?
>> At first glance, or just because I indicated that there is one ?
> Well, I saw the mistake immediately, which is why I always write my
> evals now pedantically, like so:
> eval [list format {%-20s %d}] [mk::get get db.phonebook!2 name date]
> Anything that should not be broken apart should be list'ed.
Is there a reason for not doing it this way:
eval {format {%-20s %d}} [mk::get get db.phonebook!2 name date]
This has less noise, and also seems to work nicely to protect i
variables from expanding, eg.
set format {%-20s %d}
eval {format $format} [mk::get get db.phonebook!2 name date]
--
Peter De Rijk der...@uia.ua.ac.be
<a href="http://rrna.uia.ac.be/~peter/">Peter</a>
To achieve the impossible, one must think the absurd.
to look where everyone else has looked, but to see what no one else has seen.
Jeffrey Hobbs
> Jeffrey Hobbs wrote:
>>Well, I saw the mistake immediately, which is why I always write my
>>evals now pedantically, like so:
>> eval [list format {%-20s %d}] [mk::get get db.phonebook!2 name date]
>>Anything that should not be broken apart should be list'ed.
> Is there a reason for not doing it this way:
> eval {format {%-20s %d}} [mk::get get db.phonebook!2 name date]
> This has less noise, and also seems to work nicely to protect i
The solution with lists is more pedantically correct, but just using {}s
works just as well (that's Brent Welch's preferred method, BTW). The
small added advantage with [list] is that special internal optimizations
will make it a bit faster in some cases than using {}s.
Andreas Leitgeb
> I suppose you could make `` act like double quotes except with expand-to-words
> behaviour. That'd work...
You mean something like the following ?
command $arg `$arglist`
There are some issues & caveats that need to be dealt with:
`"$arglist"` ? (does not make too much sense, anyway, does it ?)
`"$arglist`" ? (should be a syntax-error. Likely the only
bad thing is the trailing non-whitespace
after the closing backtick, as doublequotes
wouldn't have a special meaning inside)
`[command `$arglist`]` ? (unquoted nesting via [], as with "'s)
Under which limitations is object-safety possible ?
(I'd guess, if no concatenation of values happens between the
backticks, but then, would `$arg ` thwart objects ?)
One thing not to forget (it occurred to me while in an email-discussion
with setok): if ` becomes a special character, then [list] will have to
protect it. (it currently doesn't)
Even if TIP 103 (with @ as the special char only for expand) gets done
instead of this, it would be a good thing to have list protect @-chars.
I'd really love to see this latest suggestion added to Tcl.
With backticks it looks cleaner and more consistent (Tcl'ish)
than my previous {}$ and {}[-approaches.
Cameron Laird
Andreas Leitgeb <a...@logic.at> wrote:
.
.
.
>> Expanding lists is the primary use of `eval' for me :-/
>> Why would I use `eval' otherwise?
>For interpreting real scripts. Tk-widget bindings make frequent
> use of eval. Outside these uses, I cannot currently think of
> any other, but surely there exist more.
>It is used for argument expansion, because, as of now, no other
> way exists to do argument expansion.
.
.
Yes.
I just want to add my own emphasis to this accurate description.
Many, many Tcl applications do NOT need [eval], or only need it
for argument expansion, as we've been discussing. This deserves
repetition, as, during Tcl's early history, it was more widely
thought that "interpretation of synthesized scripts" was a good
and necessary Tcl style. This turns out to have been largely a
"dead end".
So, yes, it's for "interpreting real scripts". If we understand
'real' in sufficient generality, that's it's only proper use;
there are no others.
Tangential point: eval is formally redundant; it's only an abbre-
viation for [uplevel 0 ...]
--
Cameron Laird <Cam...@Lairds.com>
Business: http://www.Phaseit.net
Personal: http://phaseit.net/claird/home.html
lvi...@yahoo.com
According to Cameron Laird <cla...@phaseit.net>:
:Many, many Tcl applications do NOT need [eval], or only need it
:for argument expansion, as we've been discussing.
Cameron - is the need for argument expansion some artifact of Tcl?
If not, then what do other languages do about the issue?
Volker Hetzer
<lvi...@yahoo.com> wrote in message news:b4q9ll$8ne$2...@srv38.cas.org...
>
> According to Cameron Laird <cla...@phaseit.net>:
> :Many, many Tcl applications do NOT need [eval], or only need it
> :for argument expansion, as we've been discussing.
>
> Cameron - is the need for argument expansion some artifact of Tcl?
> If not, then what do other languages do about the issue?
They demand everything expanded into complex data structures.
Greetings!
Volker
Darren New
> is the need for argument expansion some artifact of Tcl?
> If not, then what do other languages do about the issue?
Some languages distinguish argument expansion from evaluation. So you'd
pass a list of arguments and it would be assigned to the variables, but
not via evaluation. Formally, this is known as the "apply" operation.
Joe English
>According to Cameron Laird:
>:Many, many Tcl applications do NOT need [eval], or only need it
>:for argument expansion, as we've been discussing.
>
>Cameron - is the need for argument expansion some artifact of Tcl?
>If not, then what do other languages do about the issue?
The need for argument expansion can arise for any command
that takes a variable number of arguments instead of a
single list-valued argument. Some of these could have
been avoided by using a better-designed interface (e.g.,
[file join]), but not all.
Many (most?) other languages don't even support variadic procedures.
Those that do often also provide either an "apply" procedure
(Scheme, Lisp), or an alternate fixed-argument entry point
for all variadic procedures (e.g., sprintf/vsprintf in C).
Another common use of [eval] is to expand command _prefixes_:
[eval $callback [list $arg1 $arg2 $arg3]], where $callback
is a user-supplied script with a command name and optional
initial arguments.
Other languages handle this use case with closures (Lisp-family FPLs),
curried functions (ML/Haskell-family FPLs), or idiomatically
(e.g., callback functions that take an additional 'void
*ClientData' argument in C).
--Joe English
Donald Arseneau
> According to Cameron Laird <cla...@phaseit.net>:
> :Many, many Tcl applications do NOT need [eval], or only need it
> :for argument expansion, as we've been discussing.
>
> Cameron - is the need for argument expansion some artifact of Tcl?
> If not, then what do other languages do about the issue?
The worlds cleanest programming language uses \expandafter ):->
Donald Arseneau as...@triumf.ca
lvi...@yahoo.com
According to Joe English <jeng...@flightlab.com>:
:lvirden wrote:
:>According to Cameron Laird:
:>:Many, many Tcl applications do NOT need [eval], or only need it
:>:for argument expansion, as we've been discussing.
:>
:>Cameron - is the need for argument expansion some artifact of Tcl?
:>If not, then what do other languages do about the issue?
:
:The need for argument expansion can arise for any command
:that takes a variable number of arguments
:Many (most?) other languages don't even support variadic procedures.
The reason I am trying to couch this branch of the thread in terms of
other languages is to see if some other language's solution might fit
Tcl. It may be that it is not possible. I'm hoping that it is.
ksh and perl, for instance, allow one to create functions which take variable
number of arguments.
:Those that do often also provide either an "apply" procedure
:(Scheme, Lisp), or an alternate fixed-argument entry point
:for all variadic procedures (e.g., sprintf/vsprintf in C).
I don't know how either perl or ksh solve the problem - perl probably has
the apply type procedure.
:Other languages handle this use case with closures (Lisp-family FPLs),
:curried functions (ML/Haskell-family FPLs), or idiomatically
:(e.g., callback functions that take an additional 'void
:*ClientData' argument in C).
So, of the at least 5 solutions you mention Joe, are any of these ones
that might be a fit for Tcl?
Andreas Leitgeb
> The reason I am trying to couch this branch of the thread in terms of
> other languages is to see if some other language's solution might fit
> Tcl. It may be that it is not possible. I'm hoping that it is.
to allow for a solution of another language to be applied to it.
> ksh
ksh has the proposed backtick-semantics automatical. You need to
double-quote variable- or command-substitutions to avoid having
the substituted values be torn apart.
x="1 2 3"; argcount() { echo $#; }
argcount $x -> 3
argcount "$x" -> 1
> and perl,
perl flattens all lists (references to lists are not lists)
@x=(1,2,3)
print 0,@x,4,5 -> print sees only one flat list, namely (0,1,2,3,4,5)
> So, of the at least 5 solutions you mention Joe, are any of these ones
> that might be a fit for Tcl?
The 6th one, suggested by Donal K. Fellows :-)
% set x {1 2 3}
% argcount `$x` -> 3
% argcount $x -> 1
Bryan Oakley
> lvi...@yahoo.com <lvi...@yahoo.com> wrote:
>
>>So, of the at least 5 solutions you mention Joe, are any of these ones
>>that might be a fit for Tcl?
>
>
> The 6th one, suggested by Donal K. Fellows :-)
> % set x {1 2 3}
> % argcount `$x` -> 3
> % argcount $x -> 1
>
Didn't Donal suggest a single leading backquote (eg: `$x)? I asked why
he chose a single leading quote rather than a pair. Personally, I'm
partial to the pair, but could live with either.
I like this approach _much_ better than the {}$x solution proposed a
year or two ago. I feel silly saying that, though. Really, why should it
matter that `$x` is "prettier" than {}$x? And yet, to me it does matter.
In my head I dismissed the {}$x solution as a hack, yet consider `$x or
`$x` to be good solutions. Go figure.
Perhaps it has to do with the fact I perceive {}$foo as an exception to
the normal {} processing rules, whereas `$foo` is a new, simple(ish)
rule. I like the fact that, generally speaking, Tcl has no exceptions to
it's rules.
bo...@aol.com
*pair* of backticks. To me it makes better sense to use just one and
consider it as a modifier to $ and [ substitution. There is already a
precedent for this since we do $<var-name> not $<var-name>$. In a
context where substitution is done, `$ calls for the list elements to
be substituted and $ substitutes the value. This is a minimal
solution and does only what is needed and nothing more.
Using a pair of backticks does more than is needed (not the 'tcl way')
and introduces unwanted behaviors more rules to be aware of. Making
the result look like some other language should be a non-goal. In
this case the pair of backquotes looks like a ksh feature, but does
something entirely different (the worst kind of similarity!).
bob
Andreas Leitgeb <Andreas...@siemens.at> wrote in message news:<slrnb70pf3.ddm....@pcc524.gud.siemens.at>...
Roy Terry
guaranteed to break some existing scripts. The {}$ {}[ solution was
specifically proposed because it used a previously illegal construct.
Frankly, it is a puzzle to me that we all seem to be lining up behind
an incompatible change as opposed to a basically compatible change
(unless
you consider *not* causing an error a *basic* imcompatibility)
As to making the backquotes come in a pair, I think that opens a
huge can of worms re escaping embedded backquotes and throws open
the meaning of "" and {} inside backquotes. We absolutely don't want
to go there! Anyway, the idea of expansion is not to introduce a new
quoting mechanism but to mark conventional words for the parser to
expand. For that purpose the single leading ` is both easer to use and
easier to implement and explain I think.
I hope the TCT will have the forward-looking courage to let this
change in and solve a fundamental weakness in the Tcl language.
( Either {} or ` would do and the sooner the better)
Cheers,
Roy
PS: I don't have any (known) args with leading ` so the incompability
doesn't touch my code. How about others?
John E. Perry
"Roy Terry" <royt...@earthlink.net> wrote in message
news:3E724019...@earthlink.net...
> Bryan Oakley wrote:
> >
> > Andreas Leitgeb wrote:
> > > lvi...@yahoo.com <lvi...@yahoo.com> wrote:
> > >
> >
> > Didn't Donal suggest a single leading backquote (eg: `$x)? I asked why
> > he chose a single leading quote rather than a pair. Personally, I'm
> > partial to the pair, but could live with either.
> >
Am I the only one reading this list who feels _very_ uncomfortable with
unmatched quote marks -- front, back, or whatever? Aren't there some
characters available that don't almost _mandate_ matching co-characters?
John Perry
AS&M
Donald Arseneau
> he chose a single leading quote rather than a pair. Personally, I'm
> partial to the pair, but could live with either.
I think a great strength of Tcl is its use of matching { } for
verbatim quoting (where "shell" uses ' ') and [ ] for execution
(like ` `). Tcl does have " " for weak quoting though. I
wouldn't want to add another case of pairing identical
characters wih ` ` for expansion. Moreover, in the argument
expansion proposal, the argument is clearly delimited already
by the variable name or matched [ ]. A lone ` prefix is
preferable.
As for the "backwards compatible" {} prefix, that isn't really
backwards compatible for the reason stated: removing an error
condition *is* an incompatible change. This falls into the
common trap for language extenders -- fitting new features into
previously illegal syntax. Doing that corrupts the regularity
of the language; and regularity is the prime ingrediant for
ease of use (for all but the most expert). Also, a good language
should have a sparse syntax, so errors can be recognized as such,
and not masquerade as some unintended command. A {} prefix is
the epitome of this mistake by making an easy typgraphic error
({} [foo] typed as {}[foo]) into legal syntax.
If I were voting, I'd vote for the syntax change with ` prefix.
Donald Arseneau as...@triumf.ca
Bryan Oakley
> Frankly, it is a puzzle to me that we all seem to be lining up behind
> an incompatible change as opposed to a basically compatible change
> (unless
> you consider *not* causing an error a *basic* imcompatibility)
Weird, isn't it? I agree with your observation -- {}$foo provides less
(well, no) backwards compatibility issues, yet I still personally would
go for the backtick.
Sometimes beauty wins over truth :-)
> ...
>
> I hope the TCT will have the forward-looking courage to let this
> change in and solve a fundamental weakness in the Tcl language.
I wouldn't go so far as to say this is a fundamental weakness. A mild
inconvenience perhaps. This feature is mostly just syntactic sugar to
make certain constructs a bit more palatable. Still, it's very nice sugar.
Jean-Claude Wippler
> If the first character of a word is back-quote (```'') then the rest of
> the word (as determined by the other rules, including the double-quote
> and open brace rules) is interpreted as a list and each of the words is
> appended to the list of words to be passed to the command as a separate
> word. No further expansion is performed on those words, and nor is the
> back-quote character part of any word.
>
> The idea is that this allows for expansion to be performed exactly where the
> programmer wants, and nowhere else, as well as putting the emphasis clearly on
> what is being executed for real instead of the machinery to make everything be
I admit that {}blah, and especially `blah both look appealing.
But I wonder more and more if it's the best way forward - long term...
(Warning: very rough & raw ponderings ahead...)
In Tcl, "everything is a string" (EIAS). Types are introduced by
context-of-use, and cached. With all the tricky consequences of
shimmering, and all the benefits of dual object representations. Both
shimmering and caching are about performance, conceptually everything
is *still* a string.
Aggregation in Tcl is treated in the same way, whether something
consists of N things or not is a matter of using list operators such
as llength, lindex, and lset.
There is a good reason for this: by sticking to the EIAS mantra, we
get the ability to display/store/transmit aggregate data in the same
uniform way as everything else. It's why one could argue that Tcl
also follows the "everything is an object" model.
But it comes at a price. I dare state that Tcl's weakest side is the
way it deals with non-trivial data structures, starting with lists,
but also hashes/maps/arrays/associaitions, all the way up to nested
combinations thereof. Because of the lack of even the distiction
between values and aggregation of values, we *always* have to apply
list commands to lists. Hence all the code with zillions of lindex,
lappend, lsearch, etc commands.
In theory, EIAS is a brilliant simplification. In practice, I find
EIAS one step too much. There are far, *far*, *FAR* more cases where
one treats data as a scalar (string, int, float, handle, whatever)
*or* as an aggregate. Sure, it's extremely useful to have lossless
mappings between those two categories, but that's of the same order as
having a way to display all values in text form. Great for data
interchange - i.e. UI's as well as for transport and storage
The whole EIAS concept has some arbitrariness to it btw - a string is,
after all, an aggregate of characters. So we already have a built-in
concept of aggregation. In fact it was altered in a very fundamental
way not so long ago, when Unicode was introduced. Now, strings have a
length (number of chars) as well as a distinct representation (UTF-8),
which in turn has a "bytelength" (an octet count).
So in a way, Tcl also follows the "everything is an aggregate" model.
After all, you can use the "string length" command on anything. And
there are explicit conversions between strings and lists, in the form
of [split ... {}] and [join ... { }].
Back to ticks, eh, I mean backticks...
In today's Tcl model, since aggregation or arbitrary elements is not
supported as fundamental operation, when a function returns something,
the caller has no way to find out whether the returned data is a
scalar or an aggregate. We need to decide at the *caller* location
what to do with the result and how to treat it.
Hence the proposal to introduce a new convenient notation such as:
foo 1 2 `[bar] 5 6
With bar returning data perhaps using this:
return [list 3 4]
But what if Tcl 9 were to break with this tradition and introduce a
distinct non-shimmering aspect of data, being its dimension?
It would make the backtick issue go away, allowing:
foo 1 2 [bar] 5 6
The reasoning being that a return value is either a scalar (no
dimension) or a list (with a length).
There are some biiiig issues with such a change. For one, eval would
not be needed much (allowing much better bytecode compilation, I
expect). The "interp alias" trick to introduce args ("currying") can
be replaced by list:
set lsi [list lsearch -integer $mylist]
... [$lsi $key] ...
If the "namespaces are ensembles" TIP is adopted, this would make the
"::" namespace separator redundant ("a::b::c" becomes [list a b c]).
There is also a lot of trouble ahead: the "list" command needs to
return its value as a 1-element list of a list, to avoid nullifying
its effect. The "foreach" command, and tons of other commands would
need to be reviewed, to see how automatic expansion affects them.
Despite the extreme impact of such a change, I think it's very much
worth trying to think this through. Because the underlying issue
still holds: aggregation is IMO not a datatype, as ints and floats and
dates are. By introducing aggregation as separate concept (which it
already is, but only for unicode chars), a *lot* of software
complexity might just go away.
Maybe Tcl can evolve to "everything is an aggregate", of chars *and*
of other things? It might just turn out to unify length, index,
append, range enough to make the distinction between strings and lists
go away. Arrays (i.e. hashes/maps) can easily be built on top, which
means this would open the door to arrays-as-first-class values. And
quite a bit more, but I feel that this ramble is already over the
top... :)
-jcw
PS. None of the above need affect the core concepts of Tcl IMO, such
as copy-on-write and the ability to treat everything as a string for
display, storage, and transport.
PPS. One could consider introducing "cardinality" even, i.e. dealing
with 0..N dimensions, which would open the door to making Tcl a
data-manipulation powerhouse. But that's of less importance, since it
can be simulated with uni-dimensional aggregation.
Joe English
>Yes the single back tick has some appeal. It also is virtually
>guaranteed to break some existing scripts. The {}$ {}[ solution was
>specifically proposed because it used a previously illegal construct.
>
>Frankly, it is a puzzle to me that we all seem to be lining up behind
>an incompatible change as opposed to a basically compatible change
My main objection to {}$ is aesthetic. Specifically,
I think the principle of extending a language's syntax
by using currently-illegal constructs is a Really Bad Idea.
Witness C++ :-)
I prefer the leading backtick syntax, but not until Tcl 9.
--Joe English
Derk Gwen
# worth trying to think this through. Because the underlying issue
Alternatively, define a script language which can be loaded with
Tcl and which can Tcl procs and is callable from Tcl procs.
--
Derk Gwen http://derkgwen.250free.com/html/index.html
But I do believe in this.
Lars Hellström
>Bryan Oakley wrote:
>
>>Andreas Leitgeb wrote:
>>
>>>lvi...@yahoo.com <lvi...@yahoo.com> wrote:
>>>
>>>>So, of the at least 5 solutions you mention Joe, are any of these ones
>>>>that might be a fit for Tcl?
>>>>
>>>
>>>The 6th one, suggested by Donal K. Fellows :-)
>>>% set x {1 2 3}
>>>% argcount `$x` -> 3
>>>% argcount $x -> 1
>>>
>>Didn't Donal suggest a single leading backquote (eg: `$x)? I asked why
>>he chose a single leading quote rather than a pair. Personally, I'm
>>partial to the pair, but could live with either.
>>
>>I like this approach _much_ better than the {}$x solution proposed a
>>year or two ago. I feel silly saying that, though. Really, why should it
>>matter that `$x` is "prettier" than {}$x? And yet, to me it does matter.
>>In my head I dismissed the {}$x solution as a hack, yet consider `$x or
>>`$x` to be good solutions. Go figure.
>>
My aestethic feeling about these methods are actually quite opposite. In
{}$x, the braces look a bit like arrows that aim to break up the $x in
smaller pieces, which is precisely what the expansion does. In `$x, the
quote mainly looks as if it is there by error. But Donal has a point
that {}$x may prevent certain typos from being caught by the interpreter.
>>
>>Perhaps it has to do with the fact I perceive {}$foo as an exception to
>>the normal {} processing rules, whereas `$foo` is a new, simple(ish)
>>rule. I like the fact that, generally speaking, Tcl has no exceptions to
>>it's rules.
>>
>Yes the single back tick has some appeal. It also is virtually
>guaranteed to break some existing scripts. The {}$ {}[ solution was
>specifically proposed because it used a previously illegal construct.
>
>Frankly, it is a puzzle to me that we all seem to be lining up behind
>an incompatible change as opposed to a basically compatible change
>(unless
>you consider *not* causing an error a *basic* imcompatibility)
>
Allow me to present another syntax suggestion for this. The fundamental
problem with ` is that it makes another character special which didn't
use to be, and therefore creates a danger where there didn't use to be
any. It is however perfectly possible to introduce a single character
expand syntax without "activating" another character, since the space of
$ substitutions hasn't been fully claimed. The Tcl syntax rules say
[7] If a word contains a dollar-sign (``$'') then Tcl
performs variable substitution: the dollar-sign
and the following characters are replaced in the
word by the value of a variable.
but the rest of that rule only defines what happens when the $ is
followed by a a letter, digit, underscore, left brace, or left
parenthesis; nothing is said about what happens when the next char is
e.g. another $ or a left bracket. Currently Tcl won't substitute on such
a $, but I'm pretty sure Tcl programmers anyway escape the dollar in
those cases where there wouldn't be any substitution (writing [set a
\$$b] rather than [set a $$b]) because they feel "$ signs which aren't
to be substituted must be escaped."
Hence it shouldn't be a large conceptual difference if $$ and $[ were
defined to mean $ and [ respectively, but expanded. Then one could write
the four [eval] examples
eval lappend someList $moreItems
eval destroy [winfo children .]
eval button .b $stdargs -text \$mytext -bd \$border
eval exec \$prog $opts1 [getMoreopts] \$file1 \$file2
as
lappend someList $$moreItems
destroy $[winfo children .]
button .b $$stdargs -text $mytext -bd $border
exec $prog $$opts1 $[getMoreopts] $file1 $file2
Lars Hellström
Andreas Leitgeb
of the change was principially frowned upon by most, I'm very
glad now to see, that it is generally accepted.
Discussion has now shifted from "why do we need it?" to
"how shall we make it?"
Since not everyone reads every posting, I'll post a small
summary about what I've gathered in the thread:
Suggestions:
- {}$varname and {}[command]
(my "original" proposal from years ago.)
pro: theoretically 100% compatible
con: looks ugly ("like a hack")
con: {}$ can easily be a typo, caused by a forgotten blank.
- `$varname and `[command]
(Donal K. Fellows' first followup to this thread)
pro: virtually no compatibility-issues, as backtick
almost never appears as first char of a word.
pro: looks better than {}$...
con: some classify the backtick as a pairwise-operator (see next)
- `$varname` and `[command]` and even more: `whatever ...`
(Donal K. Fellows' considered alternative in a second followup)
pro: <like above.>
con: some classify the backtick as a non-pairwise-operator (see prev.)
- $$varname and $[command]
pro: currently rarely used. (hardly any compatibility-issues)
pro: prefix-operator with no pairing/enclosing associations.
con: $$ implies double-dereference (as in perl).
- @$varname and @[command]
(as suggested in TIP 103 limited to the argument of expand)
con: @ appears too often in existing tcl-scripts.
(not an issue for non-global syntax, as with TIP 103)
pro: ... no pairing/enclosing associations.
- big change having real lists automatically spread themselves,
con: this is a really fundamental change. It's no longer Tcl then :-/
The apostrophe is used as a singleton quite often in english language,
isn't it ?-)
I'm not sure about singleton backtick-occurrences, but I for myself
would classify apostrophe and backtick equally, thus considering
the backtick also as a valid prefix-operator.
"Quoting" chars apostrophe('), backtick(`) and double-quote("), that
are paired up with themselves are often the source of all kinds
of quoting-hell, especially if they can appear nested. With double-
quotes we're mostly used to it, but it's probably not the kind of
thing we'd newly introduce.
Donald Arseneau <as...@triumf.ca> wrote:
> If I were voting, I'd vote for the syntax change with ` prefix.
Me, too.
And I would also be happy with any of these solutions, whichever
gets implemented in the core, as long as at least one of them does.
Apropos voting: does there still exist the regular quick-poll ?
Shall we update TIP 103 to reflect the dismissal of the expand-command
and change of the prefix-char ?
Donal K. Fellows
> I prefer the leading backtick syntax, but not until Tcl 9.
I concur with that, though I'm not currently sure whether to go for a single
(leading) backtick or a double (enclosing) backtick proposal. Both would work
about equally well.
Donal.
--
"Understanding leads to tolerance, which in turn leads to acceptance. And from
there, it's just a quick hop to speeding in Ohio, chewing peyote, and
frottage in the woods with a family of moose. And I just want to claim my
part of the credit." -- bunnythor <bunn...@uswest.net>
Donal K. Fellows
> Even if TIP 103 (with @ as the special char only for expand) gets done
> instead of this, it would be a good thing to have list protect @-chars.
Two points.
Firstly, rest assured that [list] will protect any new special characters. I
think that's pretty much implicit in everyone's suggestions...
Secondly, leading @ has problems with cursor specifications in Tk, and widget
configuration is one of the areas where you might realistically expect this sort
of thing to be found.
Donal K. Fellows
> There is also a lot of trouble ahead: the "list" command needs to
> return its value as a 1-element list of a list, to avoid nullifying
> its effect. The "foreach" command, and tons of other commands would
> need to be reviewed, to see how automatic expansion affects them.
>
> Despite the extreme impact of such a change, I think it's very much
> worth trying to think this through. Because the underlying issue
> still holds: aggregation is IMO not a datatype, as ints and floats and
> dates are. By introducing aggregation as separate concept (which it
> already is, but only for unicode chars), a *lot* of software
> complexity might just go away.
No, you've just turned everything on its head in effect; i.e. you'd need to add
something like [list] whenever you wanted to stop expansion. I'm not really
convinced that'd be much better, and it would definitely be deeply incompatible
with a large fraction of existing scripts.
Programmers need control of when aggregation and deaggregation happen, and how
they happen. I don't want to take that away; I just want it to be easier (i.e.
shorter and sweeter) to write down.
se...@fishpool.com
> Joe English wrote:
>> I prefer the leading backtick syntax, but not until Tcl 9.
>
> I concur with that, though I'm not currently sure whether to go for a single
> (leading) backtick or a double (enclosing) backtick proposal. Both would work
> about equally well.
Are thre no other chars we could use to do that? Somehow I find the
backtick, at least a single one, not quite as natural as say "<" or "^".
Unfortunately [expr] has stolen far too many nice chars.
I think backticks should probably come in pairs. Define it so that
if they contain many words, they are all expanded.
Tom Wilkason
news:24mda.154$143....@reader1.news.jippii.net...
> Donal K. Fellows <donal.k...@man.ac.uk> wrote:
> > Joe English wrote:
> >> I prefer the leading backtick syntax, but not until Tcl 9.
> backtick, at least a single one, not quite as natural as say "<" or "^".
> Unfortunately [expr] has stolen far too many nice chars.
>
> I think backticks should probably come in pairs. Define it so that
> if they contain many words, they are all expanded.
>
> --
> / http://www.fishpool.com/~setok/
As an alternative to `, I can't think of a reason why the | char won't work,
it is used in expressions and exec/open commands for different things
already.
lappend thelist |$manyItems $lastitem
Tom Wilkason
Don Porter
> - {}$varname and {}[command]
> (my "original" proposal from years ago.)
> pro: theoretically 100% compatible
> con: looks ugly ("like a hack")
> con: {}$ can easily be a typo, caused by a forgotten blank.
This has been my favorite, because "100% compatible" means "can
be accomplished in a Tcl 8.X release".
However...
After some recent forays into Tcl's parse and substitution routines,
I must report that the accurate description must be "100% script compatible"
and that's not the only compatibility to be concerned about.
Without going into all the details right now (it's late) trust me
that this cannot be accomplished without introducing incompatibilities
in Tcl's public C API (notably the Tcl_Parse* routines), so if we
observe strict compatibility constraints (which we haven't always), even
this cannot be done for an 8.X release.
So, I'm pulling away from {}$ and its cousin {expand}[]. Instead, I'm
resigning to not having this as a real syntax change until Tcl 9. Given
that, the current argument about the right syntax among a freer set
of choices is the right one to have.
Once we *know* what Tcl 9 will have, then I think TIP 103's proposal
to have a command for Tcl 8 that simulates it will be helpful for
bridging the gap.
--
| Don Porter Mathematical and Computational Sciences Division |
| donald...@nist.gov Information Technology Laboratory |
| http://math.nist.gov/~DPorter/ NIST |
|______________________________________________________________________|
Don Porter
> I concur with that, though I'm not currently sure whether to go for a single
> (leading) backtick or a double (enclosing) backtick proposal. Both would work
> about equally well.
I don't think so.
Paired characters are good for delimiting things. Here is the beginning;
here is the end.
But this whole thread is not about new ways to delimit things. It is
about indicating a boolean choice: expand or do not expand a word
into multiple words.
Whatever character (sequence) is chosen to be that indicator, it should
be a single, leading one. No pairs.
If the backtick makes people uncomfortable without using it as a pair,
that indicates the backtick is a poor choice for the expansion indicator.
Donal K. Fellows
> - @$varname and @[command]
> (as suggested in TIP 103 limited to the argument of expand)
> con: @ appears too often in existing tcl-scripts.
> (not an issue for non-global syntax, as with TIP 103)
> pro: ... no pairing/enclosing associations.
The problem is that one of the non-global syntax places is in the syntax of Tk
cursor specifications. And an area that it is expected that will make heavy use
of expansion will be Tk's widget configuration. This means that we have an
*expected* conflict, even if @ remains just local syntax...
> - big change having real lists automatically spread themselves,
> con: this is a really fundamental change. It's no longer Tcl then :-/
It makes my head ache trying to figure out the consequences. Not a good sign...
> The apostrophe is used as a singleton quite often in english language,
> isn't it ?-)
Yes, but that's also heavily used in Tcler's Wiki syntax. :^)
> "Quoting" chars apostrophe('), backtick(`) and double-quote("), that
> are paired up with themselves are often the source of all kinds
> of quoting-hell, especially if they can appear nested. With double-
> quotes we're mostly used to it, but it's probably not the kind of
> thing we'd newly introduce.
That's why I'm currently preferring backtick as a singleton. Singleton marks
are probably the easiest solution, especially if we don't permit nesting of
singletons.
> Shall we update TIP 103 to reflect the dismissal of the expand-command
> and change of the prefix-char ?
Maybe, maybe not. Syntactic updates will, frankly, not have a chance of getting
into the core except at a major version change. Or at least I can say for sure
that *I* will vote against them. And any modification of 103 will keep the fact
that it is an expansion command that asks to go in at a minor version, which is
fine for a new command, but not an update to the Endecalogue. I believe that
the other TCT members will agree with me on this.
A better solution would be a new TIP that obsoletes 103.
Donal.
--
"Everyone else is envisioning a future of 32-bit deep bump-mapped lizard-skin
scrollbars that adapt to the lusers mood by imperceptibly alpha-blending
through a range of chromatic combinations not repeating in 3^18 years. Needs
hardware acceleration, anaglyptic glasses, and 2 aspirin." -- Phil Ehrens
Donal K. Fellows
[...]
> but the rest of that rule only defines what happens when the $ is
> followed by a a letter, digit, underscore, left brace, or left
> parenthesis; nothing is said about what happens when the next char is
> e.g. another $ or a left bracket. Currently Tcl won't substitute on such
> a $, but I'm pretty sure Tcl programmers anyway escape the dollar in
> those cases where there wouldn't be any substitution (writing [set a
> \$$b] rather than [set a $$b]) because they feel "$ signs which aren't
> to be substituted must be escaped."
My only objection to this is that there are a substantial body of people coming
to Tcl who think that $$ does double dereferencing. OK, neither of us are
proposing that it should do, but I think that the current behaviour (the first $
is literal) is slightly less surprising, and as the people who have this
misconception are newcomers to the language, we shouldn't frighten them off.
The main thing I like about the backtick proposal is that I can also define what
happens if a backtick precedes some other kind of word (i.e. a "bareword", a
double-quoted word, or a brace-quoted word) whereas these have fundamental
differences in the $ proposal (and must continue to do so, for backward
compatability reasons.) This makes the rules for $ more complex and harder to
learn, whereas ` has a single rule whose effects can be stated simply.
Andreas Leitgeb
> <se...@fishpool.com> wrote in message
>> Are thre no other chars we could use to do that? Somehow I find the
>> backtick, at least a single one, not quite as natural as say "<" or "^".
>> Unfortunately [expr] has stolen far too many nice chars.
You're advised and expected to place the whole expression
into braces anyway, so any, even leading "^" wouldn't be affected.
Those, who write [expr 0xff ^ $x] are and always were on the
dangerous side.
The ^ is instead "killed" by regexp/regsub, as ^ is quite common at
the start of a regular expression.
> As an alternative to `, I can't think of a reason why the | char won't work,
> it is used in expressions and exec/open commands for different things
> already.
"exec" and "open" are much more of a "magic-char killer":
exec whatever </dev/null >/dev/null &
open |whatever r
I always write the arguments to open in doublequotes, as this looks
better for my eyes, but I cannot claim this to be general practise.
These (relatively common) examples kind of lock out <,>,| and & as
candidates for the new magic character, in order to open as few
compatibility issues as possible.
PS: As of now, the single backtick is still my favourite...
Just like the apostrophe, it's not too bound to be used pairwise.
PPS: it's not that we'd lock out every character, that can appear at
word-start, but only those that have a higher tendency to do so.
Hemang Lavana
> Whatever character (sequence) is chosen to be that indicator, it should
> be a single, leading one. No pairs.
>
> If the backtick makes people uncomfortable without using it as a pair,
> that indicates the backtick is a poor choice for the expansion indicator.
How about ~ (tilda) character? It can give the impression of expansion,
but it may be currently used as leading char for filenames (on unix) and
also in expr. I don't know how often it occurs in the scripts though.
Hemang.
Volker Hetzer
> an incompatible change as opposed to a basically compatible change
> (unless
> you consider *not* causing an error a *basic* imcompatibility)
> As to making the backquotes come in a pair, I think that opens a
> huge can of worms re escaping embedded backquotes and throws open
> the meaning of "" and {} inside backquotes. We absolutely don't want
> to go there! Anyway, the idea of expansion is not to introduce a new
> quoting mechanism but to mark conventional words for the parser to
> expand. For that purpose the single leading ` is both easer to use and
> easier to implement and explain I think.
>
> I hope the TCT will have the forward-looking courage to let this
> change in and solve a fundamental weakness in the Tcl language.
> ( Either {} or ` would do and the sooner the better)
I hope the TCT will finally lay this thing to rest as IMHO there's
no need for introducing new syntax.
People've got eval, they've got subst so what?
Eval being a dangerous command? Hey, Tcl/Tk *is* a powerful
language, it's bound to have dangerous things in them.
If people want a partial substitution, why not a subst-type command
with a few more command line options, like
subst -eval -quotechar ` {Script}
?
That way we'd stay in the syntax known in tcl.
Greetings!
Volker
Volker Hetzer
"Jeffrey Hobbs" <Je...@ActiveState.com> wrote in message news:3E68C6C8...@ActiveState.com...
> Andreas Leitgeb wrote:
> > Yes, it's a frequently recurring topic.
> >
> > Just now, reading the docs for MetaKit, I stumbled over the
> > following example:
> > puts [eval format {%-20s %d} [mk::get db.phonebook!2 name date]]
> >
> > See the mistake ?
> > At first glance, or just because I indicated that there is one ?
>
> Well, I saw the mistake immediately, which is why I always write my
> evals now pedantically, like so:
>
> eval [list format {%-20s %d}] [mk::get get db.phonebook!2 name date]
>
> Anything that should not be broken apart should be list'ed.
Exactly!
Maybe a line like that in the eval manpage could solve most of the problems
requiring new syntax?
Greetings!
Volker
lvi...@yahoo.com
According to Donal K. Fellows <donal.k...@man.ac.uk>:
:[...] I can also define what
:happens if a backtick precedes some other kind of word
This triggered the following thoughts:
Currently tcl has two forms for variables:
o the name of a variable:
set abc "command"
set def [list value1 value2]
set gji [list [list 123 456] xyz]
o the value of variable, expanded:
puts $abc
What if there were a third form for the variable:
exec $abc `def $xyz
where the new form performs this new type of functionality everyone's
discussing...
--
Join us at the Tenth Annual Tcl/Tk Conference <URL: http://mini.net/tcl/6274 >
Even if explicitly stated to the contrary, nothing in this posting
should be construed as representing my employer's opinions.
<URL: mailto:lvi...@yahoo.com > <URL: http://www.purl.org/NET/lvirden/ >
lvi...@yahoo.com
According to Volker Hetzer <volker...@ieee.org>:
:I hope the TCT will finally lay this thing to rest
Sorry, but it seems unlikely to happen until the people advocating
the feature get some form of it into Tcl.
Look how long people have been arguing to remove octal number formats...
Lars Hellström
>Lars Hellström wrote:
>[...]
>
>>but the rest of that rule only defines what happens when the $ is
>>followed by a a letter, digit, underscore, left brace, or left
>>parenthesis; nothing is said about what happens when the next char is
>>e.g. another $ or a left bracket. Currently Tcl won't substitute on such
>>a $, but I'm pretty sure Tcl programmers anyway escape the dollar in
>>those cases where there wouldn't be any substitution (writing [set a
>>\$$b] rather than [set a $$b]) because they feel "$ signs which aren't
>>to be substituted must be escaped."
>>
>
>My only objection to this is that there are a substantial body of people coming to Tcl who think that $$ does double dereferencing.
>
Where from? I don't know any language where $$ does double
dereferencing. (If they're coming from Perl then we seem to have hit
some kind Catch 22 for Tcl syntax discussions: if something is
similar to Perl then it can't be done, and things that are
different from Perl cannot be done either. :-} )
> OK, neither of us are proposing that it should do, but I think that the current behaviour (the first $ is literal) is slightly less surprising, and as the people who have this misconception are newcomers to the language, we shouldn't frighten them off.
>
Newcomers should at least be expected to read the Endecalogue.
Some of the rules in it are often not fully understood by
newcomers, but I doubt the rules concerning substitution belong
to that category, since these almost take the form of explicit
examples. If there was a case $$name in the rules then I believe
people would get it.
>
>
>The main thing I like about the backtick proposal is that I can also define what happens if a backtick precedes some other kind of word (i.e. a "bareword", a double-quoted word, or a brace-quoted word)
>
Well, what should happen in these cases, then? Is there any need to
expand something which is not the result of a variable or command
substitution? I don't see that there is.
Lars Hellström
Dan Smart
news:3E75A55...@math.umu.se:
<Much snippage>
>
> Hence it shouldn't be a large conceptual difference if $$ and $[ were
> defined to mean $ and [ respectively, but expanded.
Not a good idea....
puts "If I had a $[format %7.0f 1E6], I'd be rich"
Dan 'set price .02 ; puts "Just my $$price worth"' Smart
--
Dan Smart. C++ Programming and Mentoring.
cpp...@dansmart.com
ADDvantaged
Dan Smart
news:3E75E19F...@man.ac.uk:
> Andreas Leitgeb wrote:
>> Even if TIP 103 (with @ as the special char only for expand) gets
>> done instead of this, it would be a good thing to have list protect
>> @-chars.
>
> Two points.
>
> Firstly, rest assured that [list] will protect any new special
> characters. I think that's pretty much implicit in everyone's
> suggestions...
Does it have to :-(
Can't we please get away from 'list means quote', particularly as it
doesn't work (doesn't protect <,>,% etc).
Note that I've stayed pretty much out of this so far, I find ` the least
offensive proposal I've seen, although its a trifle 'subtle'. (As in it
lacks visual impact, is easily lost).
Three closely related things I've been thinking about, that I'll expand at
or before the weekend:
1) [lsubst] A list safe form of [subst]
This returns a true list, and possibly only substitutes whole words.
% set bah humbug
% set foo [list 1 2 \$bah 3\$2]
% lsubst $foo
1 2 humbug {3$2}
2) [leval] An extended eval
This expects a list of lists.
3) Add ' as an almost antonym for `
Protects the next word like [list word] but more so.
[join [split word {}] \\]
((-: Ha Ha - Only Serious :-))
> Donal.
Dan "Still hanging around the purple courtesy phone" Smart
Dan Smart
news:slrnb7bg16.ddm....@pcc524.gud.siemens.at:
> While in prior discussions about argument-expansion the usefulness
> of the change was principially frowned upon by most, I'm very
> glad now to see, that it is generally accepted.
>
No, I'm just busier than usual :-)
> Discussion has now shifted from "why do we need it?" to
> "how shall we make it?"
>
Why do we need it?
What percentage of existing code would be improved?
How many people will actually use the new syntax in preference to existing
methods?
(OK, so in part I'm being contrary :-)
> Since not everyone reads every posting, I'll post a small
> summary about what I've gathered in the thread:
>
> Suggestions:
- Add a "-list" configuration option to all Tk Widgets whose argument
is a list of configuration options.
pro: Guaranteed 100% compatible
pro: Eliminates 90% of the demand for something more complex.
con: I suspect that the remaining 10% are the noisy ones.
<Much snippage>
>
> And I would also be happy with any of these solutions, whichever
> gets implemented in the core, as long as at least one of them does.
>
> Apropos voting: does there still exist the regular quick-poll ?
>
> Shall we update TIP 103 to reflect the dismissal of the expand-command
> and change of the prefix-char ?
>
No, the expand command is a useful proof of the value of the syntax.
Dan "If we have to have this, ` is the best so far" Smart
Dan Smart
> Joe English wrote:
>> I prefer the leading backtick syntax, but not until Tcl 9.
>
> I concur with that, though I'm not currently sure whether to go for a
> single (leading) backtick or a double (enclosing) backtick proposal.
> Both would work about equally well.
>
> Donal.
What does the following mean:
% `$word some arguments
if $word is a list ?
if $word is a list of lists?
if $word is a list that starts #?
if $word is a #?
Dan "Limerick Man" Smart
<!*''#
^@`$$-
!*'$_
%*>#4
&)../
|={~~NFS server screech not responding still trying
Volker Hetzer
<lvi...@yahoo.com> wrote in message news:b57put$k4o$3...@srv38.cas.org...
>
> According to Volker Hetzer <volker...@ieee.org>:
> :I hope the TCT will finally lay this thing to rest
>
> Sorry, but it seems unlikely to happen until the people advocating
> the feature get some form of it into Tcl.
>
> Look how long people have been arguing to remove octal number formats...
and could not live with a different notion, like 0o or something?
OTOH, by making the backtick special you take another character out
of the set of useable characters in strings.
And, as it happens, one that gets used heavily when tcl is used to throw
stuff at a shell to execute.
Btw, so far, people have advocated `$... or `$...`.
What about $`...?
I think not many people have used the tick in a variable name, by reading the code
it is clear that a variable dereferencing is requested and it does solve the splitting
of a token into several tokens.
Greetings!
Volker
Andreas Leitgeb
> puts "If I had a $[format %7.0f 1E6], I'd be rich"
This is based on a misunderstanding!
Any of the discussed new magic-chars for argument-expansion would
only come to action, if it occurs at the beginning of a word.
Thus whatever happens *inside* double-quotes is not at the start
of a word, and therefore not affected by the proposed change.
Subthread ends here.
Volker Hetzer
"Andreas Leitgeb" <Andreas...@siemens.at> wrote in message news:slrnb7gbic.ddm....@pcc524.gud.siemens.at...
> Dan Smart <cpp...@dansmart.com> wrote:
> > puts "If I had a $[format %7.0f 1E6], I'd be rich"
>
> This is based on a misunderstanding!
>
> Any of the discussed new magic-chars for argument-expansion would
> only come to action, if it occurs at the beginning of a word.
Ok, that makes a big difference.
if puts "/bin/sh -ec `cat .login`" still works as expected,
(and puts $Handle "\`cat .login`" too) then it shouldn't break
that many scripts.
Greetings!
Volker
Peter Spjuth
Don Porter wrote:
> Paired characters are good for delimiting things. Here is the beginning;
> here is the end.
>
> But this whole thread is not about new ways to delimit things. It is
> about indicating a boolean choice: expand or do not expand a word
> into multiple words.
>
> Whatever character (sequence) is chosen to be that indicator, it should
> be a single, leading one. No pairs.
I agree totally. I used your words in the TIP, hope you don't mind.
> So, I'm pulling away from {}$ and its cousin {expand}[]. Instead, I'm
> resigning to not having this as a real syntax change until Tcl 9. Given
> that, the current argument about the right syntax among a freer set
> of choices is the right one to have.
Still agreeing.
> Once we *know* what Tcl 9 will have, then I think TIP 103's proposal
> to have a command for Tcl 8 that simulates it will be helpful for
> bridging the gap.
Actually I don't think we have to *know*, just know is enough ;-).
Having an expand command in 8.5 means we get an improvement within a
reasonable time frame, and we get the chance to try it out in practice.
Even if it is an ugly thing to do it is possible to select another
syntax
in 9.0 in the unlikely event that real usage shows that we made a bad
choise. But of course we should do our best to reach *know*.
I have updated the TIP to suggest the backtick, since I belive
that is the best suggestion sofar.
/Peter, currently up to his neck with an ASIC Tapeout but trying to
follow the discussion
Andreas Leitgeb
>> Firstly, rest assured that [list] will protect any new special
>> characters. I think that's pretty much implicit in everyone's
>> suggestions...
> Does it have to :-(
> Can't we please get away from 'list means quote', particularly as it
> doesn't work (doesn't protect <,>,% etc).
list is defined to do two jobs:
- protect arbitrary strings such that they are recognized
as a single item in a list.
- protect characters special to eval, such that running
eval on a (pure) list doesn't interpret special chars
inside the list-items.
This doesn't call for protecting <,>,%, but it will call for
protecting the backtick if that should become special.
this eval-list cooperation will be used much rarer as soon
as argument-expansion is available, but even then, it will
still be used.
> 1) [lsubst] A list safe form of [subst]
> This returns a true list, and possibly only substitutes whole words.
> % set bah humbug
> % set foo [list 1 2 \$bah 3\$2]
> % lsubst $foo
> 1 2 humbug {3$2}
What does this (even together with leval) really gain us ?
I cannot think of any useful application of a lsubst & leval
like described above. I'd really like to know one ...
> 3) Add ' as an almost antonym for `
> Protects the next word like [list word] but more so.
> [join [split word {}] \\]
This at least makes sense (to me, that is).
However, I don't think it gives us even nearly as much as the
proposed backtick, and probably isn't really worth the trouble.
Andreas Leitgeb
the past and now accept the backtick syntax. That's what I was
glad about.
> Why do we need it?
to get rid of evil, dangerous & ugly eval :-)
(reread the thread, I don't want to repeat the arguments all over, again.)
> What percentage of existing code would be improved?
I guess, at least 95% of all current occurrences of eval.
> How many people will actually use the new syntax in preference to existing
> methods?
How many people will actually use _any_ change, such a new commands etc.
How many make use of new features in 8.4 ?
How many restrict themselves to features already present in 7.X or
sooner ?
I guess it's just a question of time.
I'll probably start using `-syntax, as soon as I have a Tcl-
interpreter of the new version (9.?) for each of the platforms
relevant for me.
> - Add a "-list" configuration option to all Tk Widgets whose argument
> is a list of configuration options.
> pro: Guaranteed 100% compatible
> pro: Eliminates 90% of the demand for something more complex.
> con: I suspect that the remaining 10% are the noisy ones.
Agree, especially on the con, but also on the pro's.
Rather than modifying hundreds of commands to accept lists,
(which is not always possible, anyway), I'd prefer `-syntax
to do it one level below.
> Dan "If we have to have this, ` is the best so far" Smart
Andreas "I think we have to have this" Leitgeb :-)
Andreas Leitgeb
> "Andreas Leitgeb" <Andreas...@siemens.at> wrote:
>> > puts "If I had a $[format %7.0f 1E6], I'd be rich"
>> only come to action, if it occurs at the beginning of a word.
> Ok, that makes a big difference.
It sure does !
> if puts "/bin/sh -ec `cat .login`" still works as expected,
> (and puts $Handle "\`cat .login`" too) then it shouldn't break
> that many scripts.
yes, they'll still work as before.
Of what use would an argument-expanding-feature be, anyway,
if used embedded in a string ... ?
Again, each of "`$hello", \`$hello, "\`$hello", {`$Dollar' or `Euro'?}
and many more variants will behave same as they do now.
Only `$hello and `[hello] would behave differently.
Andreas Leitgeb
> What if there were a third form for the variable:
> exec $abc `def $xyz
> where the new form performs this new type of functionality everyone's
> discussing...
What to use for expanding []-substitutions then ?
PS: So far I still prefer `$var and `[cmd] but I am open for other
alternatives.
Andreas Leitgeb
> % `$word some arguments
this example applied to following values of $word ...
> if $word is a list ?
set word [list command first second]
-> the same as: command first second some arguments
> if $word is a list of lists?
set word [list [list my proc] [list $x $y]]
-> the same as: [list my proc] [list $x $y] sme arguments
> if $word is a list that starts #?
A pure list cannot possible start with a #-char, believe me.
> if $word is a #?
set word {# foo bar}
-> I must admit I'm not 100% sure. Implementation will show :-)
I'd however strongly expect (that means: 99% sure) the
"#" *not* to trigger comment-behaviour.
Volker Hetzer
"Andreas Leitgeb" <Andreas...@siemens.at> wrote in message news:slrnb7gldh.ddm....@pcc524.gud.siemens.at...
> Volker Hetzer <volker...@ieee.org> wrote:
> > "Andreas Leitgeb" <Andreas...@siemens.at> wrote:
> >> > puts "If I had a $[format %7.0f 1E6], I'd be rich"
> >> Any of the discussed new magic-chars for argument-expansion would
> >> only come to action, if it occurs at the beginning of a word.
>
> > Ok, that makes a big difference.
> It sure does !
> > if puts "/bin/sh -ec `cat .login`" still works as expected,
> > (and puts $Handle "\`cat .login`" too) then it shouldn't break
> > that many scripts.
> yes, they'll still work as before.
>
> Of what use would an argument-expanding-feature be, anyway,
> if used embedded in a string ... ?
puts "A B [xyz `$V]" ?
IMHO $V should be expanded, right?
Greetings!
Volker
--
Das meiste Geld habe ich fuer exklusive Restaurants, schnelle Autos und
teure Frauen ausgegeben. Den Rest habe ich verplempert.
Kevin Kenny
>
> What about
> puts "A B [xyz `$V]" ?
> IMHO $V should be expanded, right?
Certainly, but it's expanded as part of evaluating the expansion
of [xyz `$V], at which point it's no longer embedded in a string.
--
73 de ke9tv/2, Kevin
Volker Hetzer
"Kevin Kenny" <ken...@acm.org> wrote in message news:3E787A22...@acm.org...
Greetings!
Volker
Bob Techentin
>
> Again, each of "`$hello", \`$hello, "\`$hello", {`$Dollar' or
`Euro'?}
> and many more variants will behave same as they do now.
> Only `$hello and `[hello] would behave differently.
Wouldn't '"Hello World!" and '{Hello World!} also get expanded?
Bob
--
Bob Techentin techenti...@NOSPAMmayo.edu
Mayo Foundation (507) 538-5495
200 First St. SW FAX (507) 284-9171
Rochester MN, 55901 USA http://www.mayo.edu/sppdg/
Kevin Kenny
> Wouldn't '"Hello World!" and '{Hello World!} also get expanded?
That's less useful than `$foo and `[command], but I favor it for
ease of explanation. `hello\ world also should expand to two words.
Peter Spjuth
I can't really see how it makes explanation easier.
The TIP says: "Any word starting with ` and followed by a single
variable or command substitution ..."
Is that unclear?
One thing it sure does is complicating implementation since the parser
needs to be changed. And since it is a useless feature I don't think it
is worth it.
/Peter
Peter Spjuth
Andreas Leitgeb wrote:
>
> > if $word is a #?
> set word {# foo bar}
> -> I must admit I'm not 100% sure. Implementation will show :-)
> I'd however strongly expect (that means: 99% sure) the
> "#" *not* to trigger comment-behaviour.
It does not trigger comment-behaviour. It works just like
today when the first word is a substitution.
% set word #
#
% $word apa
invalid command name "#"
% set word "# hej hopp"
# hej hopp
% [lindex $word 0] apa
invalid command name "#"
/Peter
Lars Hellström
>OTOH, by making the backtick special you take another character out
>of the set of useable characters in strings.
>
This is indeed why it would be better to make do with the characters we
already have declared as special, such as $.
>
>And, as it happens, one that gets used heavily when tcl is used to throw
>stuff at a shell to execute.
>
>Btw, so far, people have advocated `$... or `$...`.
>What about $`...?
>
This would work for variable expansion, for the same reason as my $$...
suggestion would: the only defined cases of variable substitution is
when $ is followed by a letter, underscore, digit, left brace or left
parenthesis. A problem with $` is however that it has no obvious
counterpart for command substitution, since the first char after [ is
part of the command, whereas $$ has $[ as command substitution counterpart.
>
>I think not many people have used the tick in a variable name,
>
For that they would have had to write ${`...}, since ` isn't a letter.
Lars Hellström
Lars Hellström
>Since not everyone reads every posting, I'll post a small
>summary about what I've gathered in the thread:
>
>Suggestions:
> - {}$varname and {}[command]
> (my "original" proposal from years ago.)
> pro: theoretically 100% compatible
> con: looks ugly ("like a hack")
> con: {}$ can easily be a typo, caused by a forgotten blank.
> - `$varname and `[command]
> (Donal K. Fellows' first followup to this thread)
> pro: virtually no compatibility-issues, as backtick
> almost never appears as first char of a word.
> pro: looks better than {}$...
> con: some classify the backtick as a pairwise-operator (see next)
> - `$varname` and `[command]` and even more: `whatever ...`
> (Donal K. Fellows' considered alternative in a second followup)
> pro: <like above.>
> con: some classify the backtick as a non-pairwise-operator (see prev.)
> - $$varname and $[command]
> pro: currently rarely used. (hardly any compatibility-issues)
> pro: prefix-operator with no pairing/enclosing associations.
> con: $$ implies double-dereference (as in perl).
>
This is a somewhat curious summary, although I suppose that is because
you wanted to say something "pro" and something "con" about everything
while keeping it fairly short. However, if it is the most important
"con" of $$varname that it seems to imply double-dereference then surely
it must similarly be a major "con" of `$varname` that it seems to imply
quoting, when expansion is rather about the direct opposite? `$varname
should also get some demerits from this.
Furthermore, I took some time to study Perl today, and I can't see that
the hint of double-dereference really is a "con" for $$, since Perl's
double-dereference sort of corresponds to what expansion is supposed to
achieve! There are some differences, since the syntaxes
>
> - @$varname and @[command]
> (as suggested in TIP 103 limited to the argument of expand)
>
would have a closer correspondence to Perl, but OTOH the difference
between $ and @ in Perl is mostly that $ is for scalar values whereas @
is for array values, and since Tcl doesn't make this distinction we can
make do with only $.
Now, what is the argument that double-dereference corresponds to list
expansion? Well, Tcl doesn't have hard references to begin with, so in
order to make sense of any idea of dereferencing one would have to work
in a context where there are references. One way of doing this would be
to imagine someone "Playing Tcl" in Perl, while trying to make use of
the native datatypes there (rather than relying on the fact that
Everything Is A String).
How could one mimic Tcl lists in Perl? Since the two Tcl commands
list 1 2 3
and
list [list 1 2] 3
do not produce the same results (Tcl lists are not as Perl arrays
automatically flattened), someone trying to understand Tcl from a Perl
perspective would have to conclude that [list] and friends to not return
Perl arrays, but references to Perl arrays. A command such as
set x [list 1 2 3]
would therefore make $x a reference to a Perl array value, and hence the
doubly dereferenced $$x should indeed be the underlying Perl array value
and therefore in context be seen as a sequence of words rather than a
single word. This is precisely what expansion is meant to do, and it
also makes equal sense for the command counterpart $[command]!
Lars Hellström
Joe English
>Donal K. Fellows wrote:
>> Andreas Leitgeb wrote:
>>> Even if TIP 103 (with @ as the special char only for expand) gets
>>> done instead of this, it would be a good thing to have list protect
>>> @-chars.
>> characters. I think that's pretty much implicit in everyone's
>> suggestions...
>
>Does it have to :-(
Yes, it has to work that way.
>Can't we please get away from 'list means quote',
Since there is no [quote] that means 'quote', *something*
else has to implement 'quote'. List-producing commands
([list], [linsert], [lreplace], etc.) have been used for
this purpose since the beginning; it would be unwise to
change that. Granted, it lacks orthogonality, but this is
really a fundamental feature of the language.
> particularly as it
>doesn't work (doesn't protect <,>,% etc).
It works as advertised: it escapes characters that
matter to the Tcl parser as defined in the Endekalogue.
To escape characters that matter to [exec], [regexp],
[bind], [expr], or any of the other subsyntaxes, you
need something else...
--Joe English
Dan Smart
> Dan Smart <cpp...@dansmart.com> wrote:
>> puts "If I had a $[format %7.0f 1E6], I'd be rich"
>
> This is based on a misunderstanding!
>
Possibly, but not by me.
> Any of the discussed new magic-chars for argument-expansion would
> only come to action, if it occurs at the beginning of a word.
>
> Thus whatever happens *inside* double-quotes is not at the start
> of a word, and therefore not affected by the proposed change.
>
> Subthread ends here.
The sub thread failed to end there...
proc BareNakedLadies {sumOfCurrency} {
puts "If I had a $sumOfCurrency, I'd be rich"
}
BareNakedLadies $[format %7.0f 1E6]
Dan "Misunderstand That" Smart
Dan Smart
> Dan Smart <cpp...@dansmart.com> wrote:
>>> Firstly, rest assured that [list] will protect any new special
>>> characters. I think that's pretty much implicit in everyone's
>>> suggestions...
>> Does it have to :-(
> yes, it does.
>> Can't we please get away from 'list means quote', particularly as it
>> doesn't work (doesn't protect <,>,% etc).
> It doesn't need to. Who should list protect it for ?
>
exec for instance.
> list is defined to do two jobs:
> - protect arbitrary strings such that they are recognized
> as a single item in a list.
Which was well and good when list == string, but has been a bogus pile of
poop ever since.
> - protect characters special to eval, such that running
> eval on a (pure) list doesn't interpret special chars
> inside the list-items.
Which has nothing at all to do with "listness".
The truth is of course more complicated...
I'll try and explain later.
> This doesn't call for protecting <,>,%, but it will call for
> protecting the backtick if that should become special.
>
> this eval-list cooperation will be used much rarer as soon
> as argument-expansion is available, but even then, it will
> still be used.
>
>> 1) [lsubst] A list safe form of [subst]
>> This returns a true list, and possibly only substitutes whole words.
>> % set bah humbug
>> % set foo [list 1 2 \$bah 3\$2]
>> % lsubst $foo
>> 1 2 humbug {3$2}
> What does this (even together with leval) really gain us ?
> I cannot think of any useful application of a lsubst & leval
> like described above. I'd really like to know one ...
Building and executing scripts efficiently and safely.
I'm prepared to accept I'm uncommon, but most of my uses of eval have
little to do with argument expansion, and lots to do with dynamic code
generation.
>
>> 3) Add ' as an almost antonym for `
>> Protects the next word like [list word] but more so.
>> [join [split word {}] \\]
> This at least makes sense (to me, that is).
> However, I don't think it gives us even nearly as much as the
> proposed backtick, and probably isn't really worth the trouble.
>
I suspect it gives us very nearly as much as backtick, it would eliminate
perhaps 25% of the 'exec' issues. I would have to admit that I don't see
backtick (or more accurately the functionality it would provide) being the
huge win its proponents suggest, I see more questions related to "why
doesn't [exec ls *] do what I thought" than I do about eval and list. I
would also have to admit that point (3) was a throw away.
Dan "who promises (if only for reasons of time) to drop this topic" Smart
Andreas Leitgeb
> ..., although I suppose that is because
> while keeping it fairly short.
You're also right, that the mentioned "pro"s and "con"s were
not thought to necessarily weigh even nearly same.
> However, if it is the most important
> "con" of $$varname that it seems to imply double-dereference then surely
> it must similarly be a major "con" of `$varname` that it seems to imply
> quoting, when expansion is rather about the direct opposite? `$varname
> should also get some demerits from this.
makes sense, indeed.
With "dereference" I actually meant the (abstract) operation,
that maps the name of a variable to it's value. Thus, double-
reference would mean: take the value of the variable, interpret
that as a variable-name and obtain this other variable's value.
Sorry for not making my thoughts clear in advance.
Newbies often think, $$varname will do double-reference
(as in my definition, that is), but newbies also often try
$trunc$subindex, which surely will *not* be changed in
any foreseeable future, so perhaps we shouldn't overvalue
this argument afterall.
Snipped the perl-reference discussion, because I think it takes
us too far, and is (while being entirely true) not exactly the
kind of argument that the decision should be based on :-)
Although I personally still prefer `-syntax; $$varname (and $[cmd])
is one of those alternatives, that I'd like to see presented
to the TCT for final judgement.
Andreas Leitgeb
>> Dan Smart <cpp...@dansmart.com> wrote:
[failing example:]
>>> puts "If I had a $[format %7.0f 1E6], I'd be rich"
> proc BareNakedLadies {sumOfCurrency} {
> puts "If I had a $sumOfCurrency, I'd be rich"
> }
> BareNakedLadies $[format %7.0f 1E6]
While you're right, that this new example would behave differently
than it does now, I also think you will not deny that this pattern
will show up an big order of magnitude less often than your first
example.
Based on the small number of these issues, it might be acceptable
to force the writers to change the last line to:
> BareNakedLadies \$[format %7.0f 1E6]
or:
> BareNakedLadies "$[format %7.0f 1E6]"
or even:
> BareNakedLadies "\$[format %7.0f 1E6]"
which would have been nicer style in the first place, anyway ;-)
lvi...@yahoo.com
According to Andreas Leitgeb <a...@logic.at>:
:lvi...@yahoo.com <lvi...@yahoo.com> wrote:
:> What if there were a third form for the variable:
:> exec $abc `def $xyz
:> where the new form performs this new type of functionality everyone's
:> discussing...
:
:What to use for expanding []-substitutions then ?
I'm sorry - I don't understand this question. Are you talking
about managing strings within the [] ? Or are you talking about
passing of [string] into a proc/command as a literal?
I think that, after all these years, what people want is still confusing.
Perhaps if someone listed some specific examples of command lines
they want to code, with descriptions when the effect they are going
for is not clear, would be of a lot of help for me and perhaps others.
--
Join us at the Tenth Annual Tcl/Tk Conference <URL: http://mini.net/tcl/6274 >
Even if explicitly stated to the contrary, nothing in this posting
should be construed as representing my employer's opinions.
<URL: mailto:lvi...@yahoo.com > <URL: http://www.purl.org/NET/lvirden/ >
lvi...@yahoo.com
According to Dan Smart <cpp...@dansmart.com>:
:"Donal K. Fellows" <donal.k...@man.ac.uk> wrote in
:Can't we please get away from 'list means quote', particularly as it
Maybe what someone should do is write a quote command.
By default, it would quote every special character to each part of
Tcl .
It would also have hooks to add callback custom procedures to quote
characters that are special to particular extensions - Tk's % for instance, etc.
It might also have minor subcommands like:
set stuff [quote regexp $mystring]
would only quote regular expression metas.
set stuff [quote list $mystring]
would only quote special things to list.
set stuff [quote exec $mystring]
would only quote special things to Tcl's exec - not $, but < , > , | , etc.
Bruce Hartweg
lvi...@yahoo.com wrote:
> According to Andreas Leitgeb <a...@logic.at>:
> :lvi...@yahoo.com <lvi...@yahoo.com> wrote:
> :> What if there were a third form for the variable:
> :> exec $abc `def $xyz
> :> where the new form performs this new type of functionality everyone's
> :> discussing...
> :
> :What to use for expanding []-substitutions then ?
>
> I'm sorry - I don't understand this question. Are you talking
> about managing strings within the [] ? Or are you talking about
> passing of [string] into a proc/command as a literal?
>
> I think that, after all these years, what people want is still confusing.
>
how to make a command that returns a list, be expeanded into words
exec $abc `def [someCommand]
with the backtick as a modifier, it'll work on both $ and [] subtitution
exec $abc `$def `[someCommand]
Bruce
Andreas Leitgeb
> exec for instance.
of arguments. Actually, there is *no* way, to persuade
exec not to treat a word starting with exec's magic chars
magically.
There has been some discussion about this already, but that
topic is not yet closed in my eyes.
>> list is defined to do two jobs:
>> - protect arbitrary strings such that they are recognized
>> as a single item in a list.
> Which was well and good when list == string, but has been a
> [nasty words snipped] ever since.
Even pure lists still get transferred to strings at some points.
So we cannot really neglect it. Btw, it's not the list-command
itself, that selectively does the character protection, but the
code that transforms a pure list to a string (on demand).
(I always mix it up myself, when I'm talking on the surface.)
>>> 1) [lsubst] A list safe form of [subst]
>>> This returns a true list, and possibly only substitutes whole words.
>>> % set bah humbug
>>> % set foo [list 1 2 \$bah 3\$2]
>>> % lsubst $foo
>>> 1 2 humbug {3$2}
> Building and executing scripts efficiently and safely.
> I'm prepared to accept I'm uncommon, but most of my uses of eval have
> little to do with argument expansion, and lots to do with dynamic code
> generation.
I do think I gathered what you were after, but I think the lsubst
as proposed doesn't really bring you nearer to *your* goal.
I think, the behaviour you actually long for can be achieved the
following (currently ugly) way:
proc retargs args {return $args}
proc lsubst args {eval [list uplevel 1 retargs] $args}
(or perhaps later: proc lsubst args {uplevel 1 retargs `$args}
With behaviour as shown in these examples:
% lsubst {$x [command arg]}
<value of x> <result of command with arg>
(as a two-element list)
% lsubst {"two words" {nested $var} \$nosubst "foo$var"}
{two words} {nested $var} {$nosubst} {foo<value of var>}
(as a four-element list)
I guess this is generally more predictable and usable.
Andreas "did I misunderstand you again?" Leitgeb.
se...@fishpool.com
>
> This is a somewhat curious summary, although I suppose that is because
> you wanted to say something "pro" and something "con" about everything
> while keeping it fairly short. However, if it is the most important
> "con" of $$varname that it seems to imply double-dereference then surely
> it must similarly be a major "con" of `$varname` that it seems to imply
> quoting, when expansion is rather about the direct opposite? `$varname
> should also get some demerits from this.
I have to agree here. One reason why I don't like the backtick syntax.
People often try to use $$ for double-dereference, so it's a valid point.
I do think that in the end it would probably be better to solve this
in a syntactical way, but I've not yet seen anything which immediately
hit me as being brilliant. Personally I'd still prefer something like
^, which at least looks like what you're trying to do (unlike $$ and
backtick).
se...@fishpool.com
>
> list is defined to do two jobs:
> - protect arbitrary strings such that they are recognized
> as a single item in a list.
> - protect characters special to eval, such that running
> eval on a (pure) list doesn't interpret special chars
> inside the list-items.
I tend to agree with Dan here, we need to get rid of the latter. It is
not inuitive that the [list] command does the above (and originally took
me quite a while to realise that). We really need a separate command that
can take care of all the nasty business.
se...@fishpool.com
>
> Since there is no [quote] that means 'quote', *something*
> else has to implement 'quote'. List-producing commands
> ([list], [linsert], [lreplace], etc.) have been used for
> this purpose since the beginning; it would be unwise to
> change that. Granted, it lacks orthogonality, but this is
> really a fundamental feature of the language.
That doesn't mean we can't add a [quote] command and mark the use
of list for protection as deprecated.
--
Heiner Marxen
Lars =?ISO-8859-1?Q?Hellstr=F6m?= <Lars.He...@math.umu.se> wrote:
>Volker Hetzer wrote:
>
>>OTOH, by making the backtick special you take another character out
>>of the set of useable characters in strings.
>>
>already have declared as special, such as $.
>
>>
>
>>stuff at a shell to execute.
>>
>>Btw, so far, people have advocated `$... or `$...`.
>>What about $`...?
>>
>suggestion would: the only defined cases of variable substitution is=20
>when $ is followed by a letter, underscore, digit, left brace or left=20
>parenthesis. A problem with $` is however that it has no obvious=20
>counterpart for command substitution, since the first char after [ is=20
>part of the command, whereas $$ has $[ as command substitution counterpar=
>t.
>
>>
>>I think not many people have used the tick in a variable name,
>>
>For that they would have had to write ${`...}, since ` isn't a letter.
I'm not sure, how Volker meant it exactly, but I took it this way:
instead of using just a single backtick as prefix...
`$varname `[command]
...use a two-character prefix, namely dollar followed by backtick:
$`$varname $`[command]
That way the backtick need not even be list-protected. It plays
a similar role as the parenthesis in array index notation (which
in fact are not list-protected, cf. Tcl_ScanCountedElement()).
The backtick now is part of a special rule for dollar-expansion,
and only magic after such a dollar, which already _is_ list protected.
IMHO, $` is even better than pure `.
( I'm still a beginner, so take the above with a pound of salt :-)
--
Heiner Marxen hei...@insel.de http://www.drb.insel.de/~heiner/
Andreas Leitgeb
I already wrote a followup correcting (or better: exactifying)
that quoted post of mine.
Just for short:
1) the command "list" actually doesn't quote anything!
2) As long as eval may be applied to lists (with or without
detour to strings), we will have to carry on this quoting-
burden *for compatibility* !
3) We may easily define a command that takes a pure list as argument,
and will create a string from it such, that a list can be uniquely
recovered, but "eval" applied to that string might have all kinds
of effects, which it wouldn't have had on the currently canonical
"over-quoted" string-rep for the list. What this new command
would really gain us, lies beyond my imagination.
For experimentation, a command as in "3)" could even be implemented
as a pure Tcl proc.