Why need $ in expr?
Chang Li
The expr uses the C expression rather than standard Tcl way.
Are there any reasons to use $ alone with $x in the expr?
It is difficult to read and easy to make mistake.
I'd like to write a new cexpr without the $ symbol,
any suggestions?
Chang
Don Porter
> The expr uses the C expression rather than standard Tcl way.
> Are there any reasons to use $ alone with $x in the expr?
A "bare word" within an argument to [expr] gets interpreted as a
function name. For example, the "sin" in [expr sin(0.0)]. Because
Tcl's [expr] command lets you define new functions (at the C level),
you don't want to interpret any bare word as a variable to be
substituted.
> I'd like to write a new cexpr without the $ symbol,
> any suggestions?
Go for it. Tcl's meant to be extended with commands that serve your
needs. If it serves other's needs as well, then by all means make it
available as a package.
I'd pick a different name, but that's just me, and not terribly
important.
--
| Don Porter Mathematical and Computational Sciences Division |
| donald...@nist.gov Information Technology Laboratory |
| http://math.nist.gov/~DPorter/ NIST |
|______________________________________________________________________|
Roy Terry
the best example I could find:
http://www.elf.org/etc/tcl-expr-patch.html
Donal K. Fellows
> The expr uses the C expression rather than standard Tcl way.
> Are there any reasons to use $ alone with $x in the expr?
> It is difficult to read and easy to make mistake.
>
> I'd like to write a new cexpr without the $ symbol,
> any suggestions?
Supposing you changed it. How do I read from the variable called 'false' or the
variable called 'this is a silly name for a variable'? Those are both
completely valid variable names (though the second is self-defining... ;^)
Donal.
--
Donal K. Fellows http://www.cs.man.ac.uk/~fellowsd/ donal....@man.ac.uk
-- I'm curious; where does this statistic come from? Does its home, perchance,
ever see sunlight? -- Jason A Williams <jason+...@compsoc.man.ac.uk>
Chang Li
Thank you very much for the reference.
The author said "All the changes have no effect on existing code."
I think it is better to create as a new command.
Chang
Larry Smith
He makes a good argument, I must say. I'd like to
see a lot of it in tcl 9.0. In the meantime, a
Tcl-only solution "compute" can be found at:
http://www.wildopensource.com/larry-projects/others.html
as part of the tcl-tools package. Documentation is at:
http://www.wildopensource.com/larry-projects/tcl-tools.html#compute/
--
.-. .-. .---. .---. .-..-. | Wild Open Source Inc.
| |__ / | \| |-< | |-< > / | "Making the bazaar just a
`----'`-^-'`-'`-'`-'`-' `-' | little more commonplace."
home: www.smith-house.org | work: www.wildopensource.com
Chang Li
> Supposing you changed it. How do I read from the variable called 'false' or the
> variable called 'this is a silly name for a variable'? Those are both
> completely valid variable names (though the second is self-defining... ;^)
>
I added Roger E Critchlow's Tcl Expr patch in the Tcl 8.3.4.
Until now it worked for all my tests. This patch is cute.
You can still use your old expr as well. To answer your
question, I tested two examples:
# test boolean
set false 0; # without this set there is a error to think false as a variable.
set x(boolean) [expr false]
% 0
# test string
set a 256
set {this is a silly name for a variable} $a
set x(name) [expr ${this is a silly name for a variable}]
% 256
Without $ in the expr there is a syntax error in expression.
But the new expr worked fine for C-style expression.
So if I limited expr in the numerial computing it is fine.
The expr is a C expresion interpreter. That is wonderful.
This example tells me that we could do further to reduce the
use of the $. For example,
* if {$x < $y} ...
if (x < y) ...
* for {set i 0} {$i < $n} {incr n} ...
for (set i 0} {i < n} {incr n}
* while {$i < $n) ...
while {i < n} ...
This could reduce many errors.
Chang
> Donal.
Don Porter
> This example tells me that we could do further to reduce the
> use of the $. For example,
>
> * if {$x < $y} ...
> if (x < y) ...
>
> * for {set i 0} {$i < $n} {incr n} ...
> for (set i 0} {i < n} {incr n}
>
> * while {$i < $n) ...
> while {i < n} ...
>
> This could reduce many errors.
...and cause great confusion.
"Do What I Mean" languages are always really "Do What You Guess I Mean"
implementations, and turn into "Program What I Guess The Language Is
Guessing I Mean" exercises. No, thanks. Just give me a clear way to
say what I mean, and let me say it.
Bryan Oakley
> This example tells me that we could do further to reduce the
> use of the $.
Why is that important?
I can't see how this improves the language one whit. It merely adds an
inconsistency where one doesn't presently exist. With the change,
sometimes you dereference using $, sometimes not. As it stands today,
you always need $ to dereference a variable. Makes much more sense to me.
David N. Welton
> I can't see how this improves the language one whit. It merely adds
> an inconsistency where one doesn't presently exist. With the change,
> sometimes you dereference using $, sometimes not. As it stands
> today, you always need $ to dereference a variable. Makes much more
> sense to me.
expr itself is an inconsistency. I wish that at least the simple
operations, + - / * and % were low level Tcl byte-code commands.
Actually, I wouldn't mind if expr dissappeared completely. I think
it's ugly.
--
David N. Welton
Consulting: http://www.dedasys.com/
Personal: http://www.dedasys.com/davidw/
Free Software: http://www.dedasys.com/freesoftware/
Apache Tcl: http://tcl.apache.org/
Michael A. Cleverly
> Actually, I wouldn't mind if expr dissappeared completely. I think
> it's ugly.
Well, there is always:
rename expr {}
;-)
Donald Arseneau
That would break existing code. For backwards compatibility:
rename expr {}
proc expr { args } {
return 42
}
renaming [expr] doesn't fix those commands (like [if]) that
use the expression calculator, but not [expr]. Someone should
report this bug.
(Just in case: ;-)
Donald Arseneau as...@triumf.ca
Chang Li
> He makes a good argument, I must say. I'd like to
> see a lot of it in tcl 9.0. In the meantime, a
> Tcl-only solution "compute" can be found at:
> http://www.wildopensource.com/larry-projects/others.html
> as part of the tcl-tools package. Documentation is at:
> http://www.wildopensource.com/larry-projects/tcl-tools.html#compute/
>
I have no patience to wait for 9.0. I have used it in my codes.
The expr patch is backward compatible. You can use $ as well.
To expr the performance is more important than other commands.
By using the C-like expression we can even generate assembly
code on-the-fly for these expressions. Deal, that will be another
reason to use Tcl.
Chang
Chang Li
> This example tells me that we could do further to reduce the
> use of the $. For example,
>
> * if {$x < $y} ...
> if (x < y) ...
>
> * for {set i 0} {$i < $n} {incr n} ...
> for (set i 0} {i < n} {incr n}
>
> * while {$i < $n) ...
> while {i < n} ...
>
Above usage has been tested and worked.
A glitch is to distinguish the use of array element
and math function. So I have to use $ary(index)
to avoid the use of ary(index) in expr and the
boolean expression in if, for, and while.
I am very happy on the improvement of readiblity
of Tcl and keeping the writing errors from my C root.
Chang
>
> Chang
>
> > Donal.
et...@yahoo.com
I know I am working with data and not verbs. I believe this improves
structure and useability. I'de love to see support for $$Var and
$n$Var, viz.
set a b
set b c
set c 1
set d $$$a
as opposed to
set a b
set b c
set c 1
set d [set [set $a]]
It would certainly help with multi-dimensional and recursive coding.
Yes, I agreed would be dangerous if not properly structured. Yes, I
know there are ways to do this using procs. Yes, I realise its
frivolous, pointless even.
CHA...@neatware.com (Chang Li) wrote in message news:<d5224ea3.0209...@posting.google.com>...
Don Porter
> renaming [expr] doesn't fix those commands (like [if]) that
> use the expression calculator, but not [expr]. Someone should
> report this bug.
I think the idea is that if you're replacing [expr], you will be
replacing [if], [while], [for], as well, if that's what you're after.
That seems a better approach than having [if], etc. auto-magically
changing behavior.
Chang Li
expr is related to if, while, for commands in kernel.
so it is consistency to allow new expr expression
where the arguments are Tcl_ExprObj.
Tcl is full of inconsistency in some levels.
The $ itself is an example.
Why use $x rather than [set x]? Why use [if {$i < $n} ...]
instead of [if {[< $i $n]} ...]? To reduce the use of $
service the same purpose: make a language easy to use.
Chang
Bryan Oakley
> Tcl is full of inconsistency in some levels.
> The $ itself is an example.
> Why use $x rather than [set x]? Why use [if {$i < $n} ...]
> instead of [if {[< $i $n]} ...]? To reduce the use of $
> service the same purpose: make a language easy to use.
I guess "easy to use" is in the eye of the beholder. I much prefer the
current situation where $var always dereferences the variable. I
wouldn't like some commands to require the $, some not.
What if I do this:
set 1 "10"
set 2 "20"
expr {1+2}
How would the computer know, in your scheme, whether I want the literal
value 1, or the variable named 1? This is a rhetorical question; I know
it is impossible for the computer to know what I intend, which is why I
like to be explicit about my variables.
While it is true that tcl has some inconsistencies, I don't see that as
a good reason to add more. But the beauty of tcl is, you can extend it
however you like. Just because I don't like a feature doesn't mean you
can't implement it for yourself.
Tom Wilkason
news:eb20d1d3.02091...@posting.google.com...
> I tend to rely on the fact that when I see a $ (regardless of context)
> I know I am working with data and not verbs. I believe this improves
> structure and useability. I'de love to see support for $$Var and
> $n$Var, viz.
>
> set a b
> set b c
> set c 1
> set d $$$a
>
> as opposed to
>
> set a b
> set b c
> set c 1
> set d [set [set $a]]
>
> It would certainly help with multi-dimensional and recursive coding.
> Yes, I agreed would be dangerous if not properly structured. Yes, I
> know there are ways to do this using procs. Yes, I realise its
> frivolous, pointless even.
>
This is consistent with the way I think of $ (kind of like the way I think
of * in C). I think this would be a useful addition.
Tom Wilkason
Joe English
>> This example tells me that we could do further to reduce the
>Above usage has been tested and worked.
>
>A glitch is to distinguish the use of array element
>and math function. So I have to use $ary(index)
>to avoid the use of ary(index) in expr and the
>boolean expression in if, for, and while.
>
>I am very happy on the improvement of readiblity
>of Tcl and keeping the writing errors from my C root.
I know the feeling; I can't count the number of times
I've accidentally written stuff like:
foreach x $xs {
(set! ys (cons (f x) ys)
}
or
if {(not . null . concatMap f) xs} {
++count
}
when programming Tcl.
Oh, wait, yes I can. Zero.
Donal K. Fellows
> I tend to rely on the fact that when I see a $ (regardless of context)
> I know I am working with data and not verbs. I believe this improves
> structure and useability. I'de love to see support for $$Var and
> $n$Var, viz.
> as opposed to
Experience says that it is usually easier to use either arrays or [upvar] when
doing that sort of thing, at least in the language as it currently is. BTW,
what were you interpreting $n$var to mean? The current behaviour - concatenate
the contents of two variables - is rather useful to a lot of people (myself
included)...
Chang Li
> What if I do this:
>
> set 1 "10"
> set 2 "20"
> expr {1+2}
>
If they are constants they are considerd as constants at first.
The expr {1+2} returns 3. The expr {$1+$2} returns another result 30.
Chang
Larry Smith
> I know the feeling; I can't count the number of times
> I've accidentally written stuff like:
>
> foreach x $xs {
> (set! ys (cons (f x) ys)
> }
>
> or
>
> if {(not . null . concatMap f) xs} {
> ++count
> }
>
> when programming Tcl.
The ++ and -- notation from C made me cringe when I
first encountered it, but it is handy to provide a
visual marker for the increment/decrement point. By
comparison the "incr foo" and "incr foo -1" are not
very user friendly. This is why I designed "let" to
work the way it does. "let x ++" or "let x --" gives
you back that visual marker, and lets you forget about
the "incr" keyword.
http://www.wildopensource.com/larry-projects/tcl-tools.html#let/
http://www.wildopensource.com/larry-projects/others.html
Chang Li
> Joe English wrote:
> The ++ and -- notation from C made me cringe when I
> first encountered it, but it is handy to provide a
> visual marker for the increment/decrement point. By
> comparison the "incr foo" and "incr foo -1" are not
> very user friendly. This is why I designed "let" to
> work the way it does. "let x ++" or "let x --" gives
> you back that visual marker, and lets you forget about
> the "incr" keyword.
>
I do not like the [incr x] either. I prefer the
[++ x], [-- x], [+= x $v] [-= x $v]
It is handy than current [incr x]. I do not know how many
people learn C, but even Java/C# has used the C-like
expression. For the expression the main languages are
unified. Could not understand why Tcl away from that.
Maybe in history.
Chang
> http://www.wildopensource.com/larry-projects/tcl-tools.html#let/
> http://www.wildopensource.com/larry-projects/others.html
lvi...@yahoo.com
According to Chang Li <CHA...@neatware.com>:
:* if {$x < $y} ...
: if (x < y) ...
How, in the second case, do you tell whether the statement means:
compare $x to $y
or
compare "x" to $y
or
compare "x" to "y"
or
compare "$x" to "y"
? As long as tcl treats barewords as strings in some cases, variables in
some cases, and functions in some cases, there will be combinations that
are confusing.
--
Tcl'2002 Sept 16, 2002, Vancouver, BC http://www.tcl.tk/community/tcl2002/
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
:instead of [if {[< $i $n]} ...]?
Yikes! How ugly that second notation is!
It might work just fine for computer types, but for the non-technical
users that I have, the second notation would be terribly inconvenient.
They WANT infix algebraic expressions - and frankly, even as a computer
type, I want them as well.
Kristoffer Lawson
>
> According to Chang Li <CHA...@neatware.com>:
> : Why use [if {$i < $n} ...]
> :instead of [if {[< $i $n]} ...]?
>
> Yikes! How ugly that second notation is!
>
> It might work just fine for computer types, but for the non-technical
> users that I have, the second notation would be terribly inconvenient.
> They WANT infix algebraic expressions - and frankly, even as a computer
> type, I want them as well.
I can understand that, but I also find them somehow un-Tclish. I have
a set of commands for mathematical operations that I use. The following is
clearer
set x [+ $a b]
than
set x [expr {$a + $b}]
especially in the midst of other commands.
What I don't like at all is having things like sin, cos, rand and other
mathematical functions as part of expr with a totally different syntax.
Why not just normal procedures?
et...@yahoo.com
together but sparingly. If the facility is there then I use it, but
code maintainability is important to me. $$$$ just seems a very clean
and simple syntax. I simply have to determine the values nth
dimensions down, which quite often is simpler than it seems.
Don. Cruickshank
"Donal K. Fellows" <donal.k...@man.ac.uk> wrote in message news:<3D81A942...@man.ac.uk>...
Glenn Jackman
> I can understand that, but I also find them somehow un-Tclish. I have
> a set of commands for mathematical operations that I use. The following is
> clearer
>
> set x [+ $a b]
>
> than
>
> set x [expr {$a + $b}]
>
> especially in the midst of other commands.
>
> What I don't like at all is having things like sin, cos, rand and other
> mathematical functions as part of expr with a totally different syntax.
> Why not just normal procedures?
Perhaps: http://wiki.tcl.tk/4085
--
Glenn Jackman
gle...@ncf.ca