Syntax, expressiveness and the beauty of Tcl

[Stephan Kuhagen]

Good Morning Fellows

I just read the wiki-page about why Tcl syntax is so strange
(http://wiki.tcl.tk/2401). I already read it a while ago and the
discussion never really left my mind, since I'm often discussing and
comparing Tcl and Python with one of my colleagues.

My point is, that the very simple and straight syntax of Tcl (except,
maybe, for the very controversy {expand} in 8.5) makes it very simple
to learn the language for beginners. But only, I have to admit, if you
are not poisoned by other languages before. If you do not know any
other languages, IMO Tcl may be one of the most simple languages to
learn and understand. Very few syntax rules, very few different
concepts and a very clear semantics. It is so clear and simple, that I
often tend to write a complex expression (while programming in another
language or just when thinking about something) in a kind of pseudo
Tcl code, because of the clarity of Tcls expressiveness. It helps me
understanding, what I'm trying to think... (Nevertheless, there are
other reasons why it is hard today for beginners to learn and get used
to Tcl, but that was another thread here already)

+++

One point on the wiki-page was the syntax for math expressions like

x=a+b

in a "normal" language (whatever this means) which is

set x [expr $a+$b]

in Tcl. Okay, that _looks_ weird, but it isn't because it follows
perfectly the philosophy of Tcl. OTOH, when you have to write many
math expressions like this, the set-thing can be kind of
annoying. Some years ago, when it really annoyed me for one time, I
extended [unknown] to recognize math expressions and handle them with
expr, which was also suggested in the wiki. But that was _really_
strange... The most annoying thing about set... is, that it needs so
many finger movements, but the semantics is much clearer than the
first statement.

Anyway, in the wiki-article this was suggested to make it easier:

$ {c = a + b}

This looks very strange to me, since shell programming and Tcl in my
mind, always makes me think "$" is for variable substitution. Looking
at Perl or PHP where you can write

$c = $a+$b

really makes me sick. For me this is: set the variable, referenced by
the value of c to a+b. But the idea is interesting, only the syntax
does not fit into Tcl (IMHO). So i got the idea to do this:

---
proc : {args} {
if { [regexp {([^_0-9]\w*) *=} $args all vname] } {
uplevel set $vname [expr [string range $args [string length $all] end]]
} else {
uplevel eval expr $args
}
}
---

Now you can write:

: x = 10+10

or even

set result [: r=2+2]

which sets two variables at a time. I think I like that... - But stop,
what I really like here is not this new "syntax" extension. I will
stay with [set]. What I like is the flexibility of Tcl. This is, what
I really love.

+++

What Tcl makes really different for me compared to other languages is
the concept of having no keywords (yet...) and the very few syntax
rules which makes every statement as simple as possible. When I
learned programming, my first language was assembler (68k) and that
was very clear and obvious to me: You have one command with very few
arguments in one line. And a complete programm is simply (more or
less) a list of such statements. Remembering the old 68k days makes a
very warm and bright shimmering in my mind.

When I tried to learn C later, I simply did not get it. What do they
want from me? What kind of thinking is this? Struggling some years
with other languages and then being very pleased with the concepts of
Unix-Shells I found Tcl. That was a real enlightenment. This was the
way, programming should work: You have one command with some arguments
in one line (except for arguments which are lists) and a programm is
simply a list of such statements. Notice the similarity?

For me: Tcl is the assembler of scripting languages.

Nowadays I'm still programming in Tcl but most of the time in other
languages like C++ and Python and I like those languages, too. They
also have their beauty and I think, you should always choose a
language, that fits the problem. But looking at the beauty of the
languages itself, what is the philosophy of the concept behind it (if
any...) and the expressiveness of their statements, I often think:
This is really...kind of... weird cool...but why? I never think this
when looking at Tcl. Looking at Tcl, I'm often simply raptured about
it's beauty and how you can adapt Tcl to your structure of thinking
(or, for the serious programmer: to the structure of your problem).

+++

Well, never mind. Just some thoughts while waiting to get enough
motivation and wide awake to do something useful this early in the
morning...

Regards
Stephan

[suchenwi]

Stephan Kuhagen schrieb:

> Now you can write:
>
> : x = 10+10
>or even
> set result [: r=2+2]

I though assignment is optional, so:
set result [: 2+2]
would be a more interesting example. However, expressions specified
this way will be early evaluated by the Tcl parser. The speed advantage
of braced expressions (if they contain substitutions) gets lost. One
would better write
: x = {$y+$z}

[Stephan Kuhagen]

> I though assignment is optional, so:
> set result [: 2+2]
> would be a more interesting example.

It works this way also, but my point was to be able to write

: x=2+2

> However, expressions specified
> this way will be early evaluated by the Tcl parser. The speed advantage
> of braced expressions (if they contain substitutions) gets lost. One
> would better write
> : x = {$y+$z}

This does not work with my example, the result then is the string inside the
braces. But I did not intend to give a full blown implementation. I just
played around a little.

Regards
Stephan

[Donal K. Fellows]

Stephan Kuhagen wrote:
> It works this way also, but my point was to be able to write
> : x=2+2

We'd really rather you didn't use ":" as the command name. Almost
anything else (including control characters!) would be better. This is
because "::" is used for a namespace separator and ":" on its own gets
tangled in that. It might be better to use something like this instead:

|- x=2+2

since it looks like the turnstile operator from mathematics (OK, you
can use the real turnstile character too, but that's trickier to write
in most editors).

The other problem with the syntax as it seems to be at the moment is
that not putting braces around it means that variable substitutions
happen at "the wrong time", meaning that they can change the sequence
of operators. (This was a common problem with [expr] usage in Tcl
scripts in the 7.* days, BTW.) There are ways to fix - e.g. treating
barewords as variable names - but they in turn reduce the ability of
your code to intermix smoothly with Tcl's basic syntax and you'll end
up having to put braces round things a lot anyway.

BTW, if you're going to do assignment, don't repeat BCPL's mistakes.
Use ":=" as the assignment operator.

Donal.

[Stephan Kuhagen]

Donal K. Fellows wrote:

> We'd really rather you didn't use ":" as the command name. Almost
> anything else (including control characters!) would be better. This is
> because "::" is used for a namespace separator and ":" on its own gets
> tangled in that. It might be better to use something like this instead:
>
> |- x=2+2

"|" looks strange to me. But the name of the extended expr command does not
matter, I was just playing around. I think, one could and should use that
character, that fits best with his thinking. I know ":" is for namespaces,
but it gave me the impression of some kind of prompting. Maybe ">" would
the be a better choice, since it is only one character.

> The other problem with the syntax as it seems to be at the moment is
> that not putting braces around it means that variable substitutions
> happen at "the wrong time", meaning that they can change the sequence
> of operators. (This was a common problem with [expr] usage in Tcl
> scripts in the 7.* days, BTW.) There are ways to fix - e.g. treating
> barewords as variable names - but they in turn reduce the ability of
> your code to intermix smoothly with Tcl's basic syntax and you'll end
> up having to put braces round things a lot anyway.

Yes, as I said, I was just playing around while waiting to get fully awake.
I did not wanted to create a full blown package for math expressions. For
that, there are many things missing in my tiny extension. The ":" thingy
was just for having a possibility to type simple math expressions in a way,
that looks "normal", when you are used to other programming languages. I
think, if someone really wants to use Tcl, he should use [set] and [expr]
anyway.

> BTW, if you're going to do assignment, don't repeat BCPL's mistakes.
> Use ":=" as the assignment operator.

I think, it is not a question of mistakes or not today, but what you are
used to. If this little extension is meant to be used by someone who never
programmed Pascal or something like that, but Python or other languages
using "=" for assignment, then "=" is a good choice. In my early days, when
I learned programming on a pocket calculator, I used one of the first
graphics capable Casio pocket calculators, which came with it's very own
kind of language. The assignment there looked like this:

2+2 -> x

I like that very much until today, it looks logical to me. So the syntax of
such an extension does not matter to me. The point was just my enjoyment of
Tcls flexibility in such things. As I said, just playing around while
waiting to get really awake...

But if we take the discussion serious, my oppinion is to stick with real Tcl
syntax anyway. Using [set] and [expr] is not only faster and better, it is
also "the Tcl way". Using some visually hidden proc ":" or ">" can make a
user think, that "=" is really some kind of assignment instruction and
leads to confusion. Its good for a simple user interface for math
expressions, but not for programming. What I really wanted to say and show
with that, was written in the remaining part of my OP: Tcl is fun and a
beauty of a programming language.

Regards
Stephan

[suchenwi]

Stephan Kuhagen schrieb:

> proc : {args} {
> if { [regexp {([^_0-9]\w*) *=} $args all vname] } {
> uplevel set $vname [expr [string range $args [string length $all] end]]
> } else {
> uplevel eval expr $args
> }
> }

Are you aware that uplevel does an eval, and expr best evaluates its
arguments itself? So the poor "args" go through triple evaluation...
I'd write it like this:
proc xpr expn {
if {[regexp {(^[A-Za-z0-9_]+) *:=(.+)} $expn -> name expn]} {
uplevel 1 "set {$name} \[expr {$expn}\]"
} else {uplevel 1 [list expr $expn]}
}
% xpr 42/6
7
% xpr {x:=42/6}
7
% set x
7
% xpr {x := 6*7}
42

[Christian Gollwitzer]

Stephan Kuhagen wrote:
> One point on the wiki-page was the syntax for math expressions like
>
> x=a+b
>
> in a "normal" language (whatever this means) which is
>
> set x [expr $a+$b]

I also dislike expr in Tcl, if one has to do lots of math. Especially
that in 99% cases one needs to use additional braces. Set is OK. I'd
like to have a syntax like

${something}

as an equivalent to [expr {something}]

So one could write

set a ${$b+7}

to get this more compact. However, this not possible in Tcl withou
changing the language...

Christian

[Eckhard Lehmann]

Christian Gollwitzer wrote:

> > set x [expr $a+$b]
>
> I also dislike expr in Tcl, if one has to do lots of math. Especially
> that in 99% cases one needs to use additional braces. Set is OK. I'd
> like to have a syntax like

[...]
> set a ${$b+7}

That all looks very weird and complex. What about a simple and strict
polish notation, like in LISP:

proc + {a b} {expr {$a + $b}}
proc - {a b} {expr {$a - $b}}
proc * {a b} {expr {$a * $b}}
proc / {a b} {expr {$a / $b}}

set res [+ [* 7 8] [- 8 9]]
55

Every operator is a command as well and it is compatible with the rest
of Tcl (although it will be even less familiar to the majority of
programmers)

Eckhard

[Uwe Klein]

Eckhard Lehmann wrote:
> Christian Gollwitzer wrote:
>
>
>>>set x [expr $a+$b]
>>
>>I also dislike expr in Tcl, if one has to do lots of math. Especially
>>that in 99% cases one needs to use additional braces. Set is OK. I'd
>>like to have a syntax like
>
> [...]
>
>>set a ${$b+7}
>
>
> That all looks very weird and complex. What about a simple and strict
> polish notation, like in LISP:
>
> proc + {a b} {expr {$a + $b}}
> proc - {a b} {expr {$a - $b}}
> proc * {a b} {expr {$a * $b}}
> proc / {a b} {expr {$a / $b}}
>
> set res [+ [* 7 8] [- 8 9]]
> 55

guess why HP Calculators never gained popularity with the masses.

uwe, letting his gaze wander over to his treasured first calculator:

a still working HP 21

[Darren New]

Christian Gollwitzer wrote:
> I also dislike expr in Tcl, if one has to do lots of math. Especially
> that in 99% cases one needs to use additional braces.

I personally find it most annoying when doing some sorts of parsing,
where I have something like

set x [string range $y [expr {$z-1}] [expr {$z+1}]]
instead of something like
set x [string range $y z-1 z+1]

I.e., personally I miss the ability to use the same sort of constant
offsets you can apply to "end" on the other indecies. But that's just a
personal peeve. :-)

--
Darren New / San Diego, CA, USA (PST)
"That's pretty. Where is it?"
"Channelwood."
"We should go there on vacation."
"..."

[Larry Smith]

Stephan Kuhagen wrote:
> 2+2 -> x

As far as I know, this came from POP-11. I've never seen it elsewhere.
And, as I've noted before, it's a good fit with Tcl syntax _iff_ you
use "->" as a synonym for ";" with the proviso that the scanner will
generate the appropriate "set" after scanning ahead to eol or the next
";" to pick up the variable name. That is, the above is simply
understood by the scanner to be shorthand for "set x [ expr 2+2 ]",
the same way it now understands $x is shorthand for [ set x ].

--
.-. .-. .---. .---. .-..-. |Experts in Linux: www.WildOpenSource.com
| |__ / | \| |-< | |-< > / |"Making the bazaar more commonplace"
`----'`-^-'`-'`-'`-'`-' `-' |Check out my new novel: "Cloud Realm":
http://www.smith-house.org:8000|<this+/books/Larry_Smith/CloudRealm.html

[Kaitzschu]

On Mon, 30 Oct 2006, Darren New wrote:

> Christian Gollwitzer wrote:
> > I also dislike expr in Tcl, if one has to do lots of math. Especially
> > that in 99% cases one needs to use additional braces.
>
> I personally find it most annoying when doing some sorts of parsing,
> where I have something like
>
> set x [string range $y [expr {$z-1}] [expr {$z+1}]]
> instead of something like
> set x [string range $y z-1 z+1]
>
> I.e., personally I miss the ability to use the same sort of constant
> offsets you can apply to "end" on the other indecies. But that's just a
> personal peeve. :-)

Miss no more!

$ tclsh8.5
% set z 3
3
% string range "A string this is." $z-1 $z+4
string

--
-Kaitzschu
s="TCL ";while true;do echo -en "\r$s";s=${s:1:${#s}}${s:0:1};sleep .1;done

[Darren New]

Kaitzschu wrote:
> Miss no more!

Coool. What's the patchlevel on that? I already *have* 8.5. :-)

[Kaitzschu]

On Mon, 30 Oct 2006, Darren New wrote:

> Kaitzschu wrote:
> > Miss no more!
>
> Coool. What's the patchlevel on that? I already *have* 8.5. :-)

That would be a3 and later, ChangeLog shows "2005-04-29 TIP#176
IMPLEMENTATION [Patch 1165695]"

[Kevin Kenny]

Eckhard Lehmann wrote:
> That all looks very weird and complex. What about a simple and strict
> polish notation, like in LISP:
>
> proc + {a b} {expr {$a + $b}}
> proc - {a b} {expr {$a - $b}}
> proc * {a b} {expr {$a * $b}}
> proc / {a b} {expr {$a / $b}}
>
> set res [+ [* 7 8] [- 8 9]]
> 55
>
> Every operator is a command as well and it is compatible with the rest
> of Tcl (although it will be even less familiar to the majority of
> programmers)

TIP #174 (http://tip.tcl.tk/174) is being voted on this week.
It provides exactly the Cambridge Polish (not RPN, the "reverse"
in RPN indicates that the operator comes *last*) notation that
you request.

--
73 de ke9tv/2, Kevin
forth love if honk else forth learn then

[MH]

I guess I understand WHY CP was a natural method (since one can define the
operators to be the equivalent of a proc), but..

As a VERY frequent unix "dc" user (started with my HP-28S), I probably use
RPN more (to find answers, as opposed to entering formulae in programs) than
infix..

<sigh>

MH

[sleb...@gmail.com]

Stephan Kuhagen wrote:
>
> One point on the wiki-page was the syntax for math expressions like
>
> x=a+b
>
> in a "normal" language (whatever this means) which is
>
> set x [expr $a+$b]
>

My personal favourite is to do [interp alias {} expr {} =] so I can
write:

set x [ = $a + $b ]

which in a way looks a little normal again albeit with added [] noise.
Of course for maximum speed I'd have to write:

set x [= { $a + $b }]

with a lot more noise: [{}]. But it's good enough for me. And it's
compact enough for direct calculations in Tk:

label .l -width [= 150+$a] -height [= $a+$b]

and it also reads quite nice (width "equals" 150 "plus" $a).

[Stephan Kuhagen]

sleb...@yahoo.com wrote:

> My personal favourite is to do [interp alias {} expr {} =] so I can
> write:
>
> set x [ = $a + $b ]

Interesting, but I tried to make it a little C- or Python-like or something
similar, and to get rid of [expr] _and_ [set].

Can't your not be done with "proc = {..." also? This would work also with +,
-, * and so on. Some kind of operator-"overloading".

> which in a way looks a little normal again albeit with added [] noise.
> Of course for maximum speed I'd have to write:
>
> set x [= { $a + $b }]

But that looks exactly like the original to me.

Stephan

[Stephan Kuhagen]

Christian Gollwitzer wrote:

> I also dislike expr in Tcl, if one has to do lots of math. Especially
> that in 99% cases one needs to use additional braces.

Uh oh, what have I done...

> Set is OK. I'd
> like to have a syntax like
>
> ${something}
>
> as an equivalent to [expr {something}]
>
> So one could write
>
> set a ${$b+7}
>
> to get this more compact. However, this not possible in Tcl withou
> changing the language...

It should be easier, if the $ is replaced with something else. $ also looks
always as a variable reference to me. Yours would then be to set "a" to the
value of the variable "$b+7", at least that is how it looks to.

But maybe, there is indeed some need to have the possibility to do some more
math expressions "on the fly" inside other statements. I think, nobody
wants something like the {expand}-thing to expand math expressions in the
line, but some simple and short way to have this in the middle of other
statements seems to be useful to me. But I have no idea, how to put this
into the language, without changing it too much (that is without violating
the "command args"-scheme).

Stephan

[Stephan Kuhagen]

Kaitzschu wrote:

> Miss no more!
>
> $ tclsh8.5
> % set z 3
> 3
> % string range "A string this is." $z-1 $z+4
> string

I like that! I did not notice this, until now. Nice one.

Stephan

[Stephan Kuhagen]

Eckhard Lehmann wrote:

> That all looks very weird and complex. What about a simple and strict
> polish notation, like in LISP:
>
> proc + {a b} {expr {$a + $b}}
> proc - {a b} {expr {$a - $b}}
> proc * {a b} {expr {$a * $b}}
> proc / {a b} {expr {$a / $b}}

If you are used to LISP like languages, this is very straight forward, but
IMHO it has the disadvantage that you need to define a proc for every
operation you want to use. My first approach (which of course is far away
from being perfect as noted by others here and which is useless if you want
polish notation...) can simply use [expr], which gives you already a full
and effective expression parser, just with a very small extension to its
semantics. Maybe, this extension should be really part of [expr], so we can
write

expr {x=some_expr}

instead of

set x [expr {some_expr}]

Which IMHO would look very normal to many people, should be easy to
implement and saves you the [set]. OTOH "set..." has the advantage that you
easily can see, there is an assignment, which is what I generally like in
Tcl: WHAT is done come first. But "expr {x=some_expr}"... hm, I kind of
like that.

Stephan

[Stephan Kuhagen]

MH wrote:

>>TIP #174 (http://tip.tcl.tk/174) is being voted on this week.
>>It provides exactly the Cambridge Polish (not RPN, the "reverse"
>>in RPN indicates that the operator comes *last*) notation that
>>you request.
>
> I guess I understand WHY CP was a natural method (since one can define the
> operators to be the equivalent of a proc), but..
>
> As a VERY frequent unix "dc" user (started with my HP-28S), I probably use
> RPN more (to find answers, as opposed to entering formulae in programs)
> than infix..

I wasn't aware of this, but I think, I do not like it. It is a question of
what you are used to, of course. But in source-code I prefer writing infix
instead of prefix operators. I also dislike it, because it introduces so
many new commands and will not stop to extend (and floating the namespace)
with new commands until all possible math expressions are included. Of
course, the TIP puts them in a new namespace, but do you really want to
import math operators into the current namespace or reference them with
full namespace path? I don't think so... Then I like the good old [expr]
much better, which can be easily extended to understand some new operators,
expressions or even syntax (maybe something [expr -p + 2 3] to say [expr]
to use prefix operators?). But I like my other idea better, to extend
[expr] such that it can assign its results to a variable using [expr
x=...]. This would be a very small change, that does not introduce a big
change into the language, but saves many of the annoying examples from the
other postings here.

Regards
Stephan

[Stephan Kuhagen]

Larry Smith wrote:

> Stephan Kuhagen wrote:
>> 2+2 -> x
>
> As far as I know, this came from POP-11.

I never heard about that. What is it? Or do you mean PDP-11?

> I've never seen it elsewhere.

"->" is one character on the Casio pocket calculator, if I remember right.
If you're interested, it was this one:

http://rechner.hs.abcbtx.de/Gall_Casio/index.php?i=132

with it's manual here:

http://www.casiotechno.com/download/manual/FX-8000G.pdf

Mine still does work, and wow, I had 1917 kind of Bytes for storing my
programs! (Kind of because every token was one "Byte"... strange)

> And, as I've noted before, it's a good fit with Tcl syntax _iff_ you
> use "->" as a synonym for ";" with the proviso that the scanner will
> generate the appropriate "set" after scanning ahead to eol or the next
> ";" to pick up the variable name. That is, the above is simply
> understood by the scanner to be shorthand for "set x [ expr 2+2 ]",
> the same way it now understands $x is shorthand for [ set x ].

But this would be a bigger change to the scanner? Looks to me, if this
likely would have very bad performance.

Regards
Stephan

[sleb...@gmail.com]

Stephan Kuhagen wrote:
> sleb...@yahoo.com wrote:
>
> > My personal favourite is to do [interp alias {} expr {} =] so I can
> > write:
> >
> > set x [ = $a + $b ]
>

> Can't your not be done with "proc = {..." also? This would work also with +,
> -, * and so on. Some kind of operator-"overloading".

Aliases are faster since there is no "call"ing involved. In fact I used
to do it with proc before I found out about aliases.

> > which in a way looks a little normal again albeit with added [] noise.
> > Of course for maximum speed I'd have to write:
> >
> > set x [= { $a + $b }]
>
> But that looks exactly like the original to me.
>

Well, it doesn't to me. But that's just my personal feelings.

Your pet peeve have just motivated me to see what can be done. There's
probably a page on the wiki for this but I can't be bothered to search
for it right no. Besides, making Tcl do "strange" things can be fun.
Here's my own early attempt to please you:

proc cleanupVar {name1 name2 op} {
rename $name1 {}
}

proc var {name {= =} args} {
upvar 1 $name x
if {[llength $args]} {
set x [expr $args]
} else {
set x {}
}
proc $name args "
upvar 1 $name $name
if {\[llength \$args\]} {
set $name \[expr \[lrange \$args 1 end\]\]
} else {
return \$[set name]
}
"
uplevel 1 [list trace add variable $name unset cleanupVar]
}

OK, the code is very ugly at the moment but it works with the caveat
that you can never have a proc with the same name as a variable
declared with this (since all procs are global). With this you can
write C-like:

proc test {} {
var x
var y = 10

x = $y*2

return $x
}
puts [test]

should output the correct result (20). It even works in recursive procs
(which means that it is safe to use the same variable name in nested
procs):

proc recursiveTest {x} {
var y = $x - 1

if {$y > 0} {
recursiveTest $y
}
puts $y
}
recursiveTest 10

should output the numbers 0 to 9. Another test:

proc test2 {} {
var x = 10
puts "this x belongs to test2 = $x"
}

proc test3 {} {
var x = 100
test2
puts "this x belongs to test3 = $x"
}

test3

output:
this x belongs to test2 = 10
this x belongs to test3 = 100

[Stephan Kuhagen]

sleb...@yahoo.com wrote:

>> Can't your not be done with "proc = {..." also? This would work also with
>> +, -, * and so on. Some kind of operator-"overloading".
>
> Aliases are faster since there is no "call"ing involved.

Okay, I was not aware of that.

> In fact I used
> to do it with proc before I found out about aliases.

Looks like there can be done many funny things with that.

> Besides, making Tcl do "strange" things can be fun.

Right, and sometimes I really love playing around with that.

> Here's my own early attempt to please you:

I will have a closer look into that, looks cool to me. Does your example
imply that the variable must exist before it can be used that way? This
would be very C-like, more that I expected... ;-)

Stephan

[Eckhard Lehmann]

Kevin Kenny

>
> >>TIP #174 (http://tip.tcl.tk/174) is being voted on this week.
> >>It provides exactly the Cambridge Polish (not RPN, the "reverse"
> >>in RPN indicates that the operator comes *last*) notation that
> >>you request.

Sorry for the "reverse".. I meant strict prefix notation of operators
;-).

Stephan Kuhagen wrote:
> I wasn't aware of this, but I think, I do not like it. It is a question of
> what you are used to, of course. But in source-code I prefer writing infix
> instead of prefix operators.

The point is, that it resembles the Tcl way better and is easier to
explain. In LISP, everything is prefix, so the (+ a b) is no surprise.
Tcl is similar regarding prefix operators. [expr] is the prefix
operator for math but inside it mixes infix notation in - which differs
from the philosophy of prefix operators that you have everywhere else
in Tcl.

> I also dislike it, because it introduces so
> many new commands and will not stop to extend (and floating the namespace)
> with new commands until all possible math expressions are included.

There are more math operators expressed in prefix notation anyway:
[sin], [cos], [tan] [abs], [round]... Why not be consistent?

Eckhard

[sleb...@gmail.com]

Stephan Kuhagen wrote:
> sleb...@yahoo.com wrote:

> I will have a closer look into that, looks cool to me. Does your example
> imply that the variable must exist before it can be used that way? This
> would be very C-like, more that I expected... ;-)

No. 'Normal' variables don't inherit that behavior (for that you can
use the [unknown] trick). Instead the [var] command is used to create
C-like variables:

var x = 10
var y

x = $x * 2
y = $x * $x
x = $y
y = 0

puts $x
puts $y

Notice that since x and y are proper procs, they can also be used like
this:

y = [x]
x = [x] + [y]

but I think $x looks nicer than [x]. Besides, for me, in my code, [x]
signifies a constant (I use procs to define global constants).

[Fredderic]

> The point is, that it resembles the Tcl way better and is easier to
> explain. In LISP, everything is prefix, so the (+ a b) is no surprise.
> Tcl is similar regarding prefix operators. [expr] is the prefix
> operator for math but inside it mixes infix notation in - which
> differs from the philosophy of prefix operators that you have
> everywhere else in Tcl.

I think having the math operators in their own namespace is a great
idea, especially if they take multiple arguments (eg. [+ 1 2 3 4 5]).
I've occasionally found it handy to have the basic maths ops as
commands, and having them pre-defined in the math ops namespace means I
don't have to re-define them myself anymore.

> > I also dislike it, because it introduces so many new commands and
> > will not stop to extend (and floating the namespace) with new
> > commands until all possible math expressions are included.

I've also rarely came across a situation where it matters if they're
stuck in their own namespace, because generally the [expr] command does
the job better anyhow. We'll probably run into that old [expr] problem
with double-evaluated arguments. So [tclmath::+] (or whatever it ends
up being) shouldn't often be a problem. And even when it is, you can
also quite easily pull just the ones you need into the local
namespace. People should be encouraged to leave room for these
operators, and pull them in from there rather than re-implementing them
themselves. Perhaps even provide a convenience function to do it.

Fredderic

[sleb...@gmail.com]

sleb...@yahoo.com wrote:
> Stephan Kuhagen wrote:
> > sleb...@yahoo.com wrote:
> > I will have a closer look into that, looks cool to me. Does your example
> > imply that the variable must exist before it can be used that way? This
> > would be very C-like, more that I expected... ;-)
>
> No. 'Normal' variables don't inherit that behavior (for that you can
> use the [unknown] trick).

Forgot to link to the [unknown] trick. Richard Suchenwirth have written
a much more powerful and flexible system at http://wiki.tcl.tk/2776
which also works with 'ordinary' variables. It should do what you want
better than my hack.

[Stephan Kuhagen]

Eckhard Lehmann wrote:

> Stephan Kuhagen wrote:
>> I wasn't aware of this, but I think, I do not like it. It is a question
>> of what you are used to, of course. But in source-code I prefer writing
>> infix instead of prefix operators.
>
> The point is, that it resembles the Tcl way better and is easier to
> explain.

True. But I think it is very unusual for many people. Maybe both should be
possible in [expr].

> In LISP, everything is prefix, so the (+ a b) is no surprise.
> Tcl is similar regarding prefix operators. [expr] is the prefix
> operator for math but inside it mixes infix notation in - which differs
> from the philosophy of prefix operators that you have everywhere else
> in Tcl.

Hm, yes, that's true but... it feels uncomfortable. I think [expr] always as
a kind of sub-language in Tcl. So I would prefer [expr]s sub-language to
use infix (at least to stay backward-compatible), but maybe there could be
a switch to [expr] to change the parser so prefix.

Stephan

[Mark Janssen]

On Oct 30, 3:33 pm, Christian Gollwitzer

Note that there is a backward compatibility problem with using $ for
this. The reason is that in Tcl {$b+7} is a perfectly valid variable
name.
So you will run into problems:

% set {$b+7} 5
5
% set b 1
1
% set a ${$b+7}
# a == 5 (current Tcl)
# a == 8 (with this syntax)

Mark

[Donal K. Fellows]

Stephan Kuhagen wrote:
> Maybe, this extension should be really part of [expr], so we can write
> expr {x=some_expr}
> instead of
> set x [expr {some_expr}]

That's TIP#282, which is probably not going to be in 8.5 after all. That
is because it introduces a new concept, an LValue, which [expr]essions
didn't have before, and we'd like to have more alpha-cycle time to
evaluate it's effects.

You can hack your way around this by defining a [set] function, perhaps
like this:
interp alias {} ::tcl::mathfunc::set {} ::set
which you would then use like this:
expr { set("x", 1+2+3) }

Donal.

[Christian Gollwitzer]

Eckhard Lehmann wrote:
>
> That all looks very weird and complex. What about a simple and strict
> polish notation, like in LISP:
>
> proc + {a b} {expr {$a + $b}}
> proc - {a b} {expr {$a - $b}}
> proc * {a b} {expr {$a * $b}}
> proc / {a b} {expr {$a / $b}}
>
> set res [+ [* 7 8] [- 8 9]]
> 55

That is exactly the opposite of what I'm proposing. It is nice from a
mathematicians point of view to reduce programming langugages to few
simple rules. Look at the lambda calculus. But this concept gives you
brainfuck-like programs, if something does not fit into the concept.
E.g. "monads" are very complicated concepts just to get serial I/O in
Haskell. Or look at the definition of the subtraction of two natural
numbers in the lambda calculus...

Maths (analytics on paper) is usually done in infix notation for good
reasons: It makes the structure of expressions clear. You don't want to
transform them into RPN for the sake of computation by hand. RPN is only
good for very short expressions, not for

arctan(x/4*pi^sin(sqrt(y+x^3)))

Christian

[Stephan Kuhagen]

Donal K. Fellows wrote:

> Stephan Kuhagen wrote:
>> Maybe, this extension should be really part of [expr], so we can write
>> expr {x=some_expr}
>> instead of
>> set x [expr {some_expr}]
>
> That's TIP#282, which is probably not going to be in 8.5 after all. That
> is because it introduces a new concept, an LValue, which [expr]essions
> didn't have before, and we'd like to have more alpha-cycle time to
> evaluate it's effects.

Funny, just 2 weeks before my posting. Okay, for 8.5 it's far too late. But
if it has a chance to get into 8.6 (will there be one?) or 9.0, I can
wait...

Stephan

[suchenwi]

Donal K. Fellows schrieb:

> That's TIP#282, which is probably not going to be in 8.5 after all. That
> is because it introduces a new concept, an LValue, which [expr]essions
> didn't have before, and we'd like to have more alpha-cycle time to
> evaluate it's effects.

One interesting effect could be e.g
expr {sin($x) = sin($x)}
where as an lvalue, sin() would be an array, while on the right side
it's still the good old sine function...

[Stephan Kuhagen]

suchenwi wrote:

> One interesting effect could be e.g
> expr {sin($x) = sin($x)}
> where as an lvalue, sin() would be an array, while on the right side
> it's still the good old sine function...

Wow! This would be fun! You can show this around to non-Tcl'ers and get
additional 1000 points on the geek-scale...

But seriously: I do not think, that this would be such a bad effect. You can
write

set sin($x) [expr sin($x)]

today, which is also a little bit strange...

Stephan

[Eckhard Lehmann]

Christian Gollwitzer wrote:

> > set res [+ [* 7 8] [- 8 9]]
> > 55

> Maths (analytics on paper) is usually done in infix notation for good

> reasons: It makes the structure of expressions clear. You don't want to
> transform them into RPN for the sake of computation by hand. RPN is only
> good for very short expressions, not for

It's not RPN, it's prefix notation...

I think people should learn that at school from the beginning on - it
would cause far less problems in picking up prefix programming
languages later ;-)

> arctan(x/4*pi^sin(sqrt(y+x^3)))

arctan (* (/ x 4) (^ pi (sin (sqrt (+ y (^ x 3))))))

Ok, you can spent much time with counting parantheses here :-). But
when you're used to it, it seems more logical than the mixed
infix/prefix notation you wrote above - IMO...

Eckhard

[Fredderic]

On Mon, 30 Oct 2006 15:33:52 +0100,
Christian Gollwitzer <Christian....@uni-bayreuth.de> wrote:

> I also dislike expr in Tcl, if one has to do lots of math. Especially
> that in 99% cases one needs to use additional braces. Set is OK. I'd
> like to have a syntax like: ${something}
> as an equivalent to [expr {something}]
> So one could write: set a ${$b+7}

Question... Any reason it couldn't be adapted to a syntax like:

set a ${{$b+7}}

ala bash shells in *nix? The ${{...}} structure doesn't do what it
looks like it'd do anyhow. One would incorrectly assume that it would
either resolve a variable whos name contains the inner brackets, or
that the inner brackets would be magically absorbed as some kind of
list-of-a-single-word thing. In actual fact, the first open-brace
matches the first close-brace, with the effect that the second
open-brace is considered part of the variable name, and the second
close-brace is literal. This would be a very ugly variable name to try
and work with at the best of times.

So adding support for ${{...}} being equivalent to [expr {...}], might
actually make the syntax cleaner and slightly less confusing than it
already is anyhow, by giving it an actual defined meaning.

Fredderic

[suchenwi]

Fredderic schrieb:

> So adding support for ${{...}} being equivalent to [expr {...}], might
> actually make the syntax cleaner and slightly less confusing than it
> already is anyhow, by giving it an actual defined meaning.

I'm not sure whether it's cleaner and less confusing.. but
experimenting shows that the dollar parser's bevavior on braces is
surprising anyway:

15 % set {hello world} 1
1
45 % set x ${{hello world}}
can't read "{hello world": no such variable
So the first brace encountered is taken for closing, independent of
nesting depth?

[Fredderic]

On 31 Oct 2006 03:55:39 -0800,
"Eckhard Lehmann" <eck...@web.de> wrote:

> Christian Gollwitzer wrote:
> > arctan(x/4*pi^sin(sqrt(y+x^3)))
> arctan (* (/ x 4) (^ pi (sin (sqrt (+ y (^ x 3))))))

Just write everything in postfix notation, and be done with it...

[rpxe $x 4 $pi * $y $x 3 ^ + sqrt sin ^ / arctan]

Now, isn't that just so much clearer than anything else that's been
proposed so far? ;)

It actually shouldn't be too hard to implement... Really...

proc rpxe {args} {
set stack [list]
foreach arg $args {
if { [string is digit -strict $arg] } {
lappend stack $arg
continue
}
switch -exact $arg {
"+" - "-" - "/" - "*" - "^" {
foreach {x y} [lrange $stack end-1 end] {break}
set value [expr $x $arg $y]
set stack [lreplace $stack end-1 end $value]
# set value [expr {end-1}$stack $arg {end}$stack]
# set stack [list {0:end-2}$stack $value]
}
"sqrt" - "sin" - "arctan" {
set x [lindex $stack end]
set value [expr ${arg}(\$x)]
set stack [lreplace $stack end end $value]
# set value [expr ${arg}({end}$stack)]
# set stack [list {0:end-1}$stack $value]
}
}
}
lindex $stack end
}

(Just for the fun of it, the comments show how it MIGHT look, given the other thread I was heavily involved in not so long ago ;) )

Mind you... I have no idea whether that'll come even close to
working. And there's probably a vastly better version available
just about anywhere else. Just thought it'd be amusing to roll one out and see
what it'd look like. :)

Fredderic

[Fredderic]

On 31 Oct 2006 04:14:54 -0800,
"suchenwi" <richard.suchenw...@siemens.com> wrote:

> Fredderic schrieb:
> > So adding support for ${{...}} being equivalent to [expr {...}],
> > might actually make the syntax cleaner and slightly less confusing
> > than it already is anyhow, by giving it an actual defined meaning.
> I'm not sure whether it's cleaner and less confusing.. but
> experimenting shows that the dollar parser's bevavior on braces is
> surprising anyway:

> 45 % set x ${{hello world}}
> can't read "{hello world": no such variable
> So the first brace encountered is taken for closing, independent of
> nesting depth?

*nods* That's exactly the point I was making...!

Fredderic

[Fredderic]

On 30 Oct 2006 18:16:26 -0800,
"sleb...@yahoo.com" <sleb...@gmail.com> wrote:

> My personal favourite is to do [interp alias {} expr {} =] so I can

> write: label .l -width [= 150+$a] -height [= $a+$b]

That might be viable if [interp alias] was able to, for example,
embed the arguments within the list instead of only appending them.

interp new-kinda-alias {} = {} expr { ${} }

Where ${} represents the command tail. Then, writing this:

set x [= 150+$a]

would be absolutely identical to writing:

set x [expr { 150+$a }]

and it'd actually do something useful. Although, I think we'd be
heading into very very dangerous waters with an interp command like
that... A new definition of the old [K] function:

interp new-kinda-alias {} K {} lindex [list ${}] end

Almost as dangerous as if you could warp the namespace resolution of
the TCL maths namespace, to include the namespace resolution of the
present execution scope. All of a sudden all your maths operations
would be exposed as regular commands, and probably your entire procedure
body would be written within a single [expr] statement, using
[expr] syntax parsing rules instead of the usual TCL rules.
Replace the [proc] command to wrap the procedure body in an [expr]
and suddenly TCL ends up looking very very odd. ;)

Fredderic

[Don Porter]

Donal K. Fellows wrote:
> That's TIP#282, which is probably not going to be in 8.5 after all. That
> is because it introduces a new concept, an LValue, which [expr]essions

> didn't have before, ...

No, it doesn't. This is Tcl. Everything is a string.

We've had the concept of "variable name" for a long long time.

--
| Don Porter Mathematical and Computational Sciences Division |
| donald...@nist.gov Information Technology Laboratory |
| http://math.nist.gov/~DPorter/ NIST |
|______________________________________________________________________|

[Donal K. Fellows]

Don Porter wrote:
> We've had the concept of "variable name" for a long long time.

Is a variable name exactly an LValue? What happens with bareword
parsing? Do we really want to permit the f($x):=f($x) example?

Myself, I'd have been happy to let this go into 8.5, but the screaming
was too loud for others (just like with OO...)

Donal.

[Donal K. Fellows]

Fredderic wrote:
> Just write everything in postfix notation, and be done with it...
> [rpxe $x 4 $pi * $y $x 3 ^ + sqrt sin ^ / arctan]
> Now, isn't that just so much clearer than anything else that's been
> proposed so far? ;)

Now come up with a neat way of doing it with variadic operations. (RPN
works nicely as long as everything knows exactly how many values to pop
from the stack. Otherwise it's messy; most solutions that I've seen have
involved some special syntax for list manufacturing.)

Donal.

[George Peter Staplin]

RPN C extension for Tcl
http://wiki.tcl.tk/16187

[Don Porter]

Don Porter wrote:
>> We've had the concept of "variable name" for a long long time.

Donal K. Fellows wrote:
> Is a variable name exactly an LValue? What happens with bareword
> parsing?

That's it. Sorting out issues with exactly how we want to relax the
existing constraints on bareword parsing is where this proposal isn't
trivially simple. But sorting out that lexification revision doesn't
require any new "LValue" concept, borrowed from languages that lack
Tcl's EIAS nature.

[Darren New]

Christian Gollwitzer wrote:
> Maths (analytics on paper) is usually done in infix notation for good
> reasons: It makes the structure of expressions clear.

Bwaaaa ha ha ha haha!

Until you start using 3 different fonts and leaving out "understood"
operators and extra parentheses and start using the same notation to
mean completely different things in the same expression.

log² N² < O(N²) anyone?

log

--
Darren New / San Diego, CA, USA (PST)
"That's pretty. Where is it?"
"Channelwood."
"We should go there on vacation."
"..."

[Darren New]

Mark Janssen wrote:
> Note that there is a backward compatibility problem with using $ for
> this. The reason is that in Tcl {$b+7} is a perfectly valid variable
> name.

I must be oversensitive after having worked with Tcl too long. I'm
reading thru the Ruby "pickaxe" book, and seeing things like "This
parameter defaulted to false before 1.8 and true after 1.8", and
thinking "they really don't care what they break, do they?"

[Larry Smith]

Stephan Kuhagen wrote:
> Larry Smith wrote:
>> Stephan Kuhagen wrote:
>>> 2+2 -> x
>> As far as I know, this came from POP-11.
> I never heard about that. What is it? Or do you mean PDP-11?

Nope. http://en.wikipedia.org/wiki/POP-11

>> And, as I've noted before, it's a good fit with Tcl syntax _iff_ you
>> use "->" as a synonym for ";" with the proviso that the scanner will
>> generate the appropriate "set" after scanning ahead to eol or the next
>> ";" to pick up the variable name. That is, the above is simply
>> understood by the scanner to be shorthand for "set x [ expr 2+2 ]",
>> the same way it now understands $x is shorthand for [ set x ].
>
> But this would be a bigger change to the scanner? Looks to me, if this
> likely would have very bad performance.

I can't see that it would be any slower than the "set x $y" notation
is. It can still be bytecoded.

One of the best things about suffix notation like this is the fact
that the interpreter already has the command or expression already
in hand when it finds out it needs to store it somewhere. That is
almost always easier than stacking the "set" and then parsing the
command or expression and then recalling that this was all in order
to set something.

--
.-. .-. .---. .---. .-..-. |Experts in Linux: www.WildOpenSource.com
| |__ / | \| |-< | |-< > / |"Making the bazaar more commonplace"
`----'`-^-'`-'`-'`-'`-' `-' |Check out my new novel: "Cloud Realm":
http://www.smith-house.org:8000|<this+/books/Larry_Smith/CloudRealm.html

[Michael A. Cleverly]

On Mon, 30 Oct 2006, Stephan Kuhagen wrote:

> Looking at Tcl, I'm often simply raptured about it's beauty and how you
> can adapt Tcl to your structure of thinking (or, for the serious
> programmer: to the structure of your problem).

QOTW?

[Michael A. Cleverly]

On Tue, 31 Oct 2006, suchenwi wrote:

> I'm not sure whether it's cleaner and less confusing.. but
> experimenting shows that the dollar parser's bevavior on braces is
> surprising anyway:
>
> 15 % set {hello world} 1
> 1
> 45 % set x ${{hello world}}
> can't read "{hello world": no such variable
> So the first brace encountered is taken for closing, independent of
> nesting depth?

That's what the ${name} syntax of rule 7 of the endekalogue says. (Had to
re-read it because I found it surprising at first glance too.):

${name} Name is the name of a scalar variable. It may
contain any characters whatsoever except for
close braces.

Which means there are some names of variables that can be retrieved
with a [set ...] but not with any form of $ dereferencing. That's kind of
a fun piece of obscure trivia. :-)

Michael

[Stephan Kuhagen]

sleb...@yahoo.com wrote:

> Forgot to link to the [unknown] trick. Richard Suchenwirth have written
> a much more powerful and flexible system at http://wiki.tcl.tk/2776
> which also works with 'ordinary' variables. It should do what you want
> better than my hack.

Funny, I wrote something very similar some years ago, just to show a friend
of mine, what can be done with Tcl. Seems that Richard Suchewirth has the
same kind of obsession... But his implementation rocks, mine was just a
"Look! I can do THAT!" ;-)

Stephan

[Stephan Kuhagen]

Don Porter wrote:

> Don Porter wrote:
>>> We've had the concept of "variable name" for a long long time.
>
> Donal K. Fellows wrote:
>> Is a variable name exactly an LValue? What happens with bareword
>> parsing?
>
> That's it. Sorting out issues with exactly how we want to relax the
> existing constraints on bareword parsing is where this proposal isn't
> trivially simple. But sorting out that lexification revision doesn't
> require any new "LValue" concept, borrowed from languages that lack
> Tcl's EIAS nature.

Hm, I can't really see the difference here. Okay, writing

x=2+2

would break EIAS and be a bad change to Tcl. But

expr {x=2+2}

is not. This would be an extension to the embedded language of [expr] which
does not follow EIAS anyway.The extension would allow to write math
expressions in a much more intuitive (maybe more intuitive because of what
people are used to by learning bad designed mainstream languages) fashion.
Also I think, that this could be much faster than

set x [expr 2+2]

Regards
Stephan

[Stephan Kuhagen]

Larry Smith wrote:

> Nope. http://en.wikipedia.org/wiki/POP-11

Thanks, just learned something new.

> One of the best things about suffix notation like this is the fact
> that the interpreter already has the command or expression already
> in hand when it finds out it needs to store it somewhere. That is
> almost always easier than stacking the "set" and then parsing the
> command or expression and then recalling that this was all in order
> to set something.

If you see it as a game like my original x=2+2 thing, then this is okay for
me. To really change or extend Tcl in this way, would be a very strange
change to the syntax rules of Tcl. "2+2 -> x" for the current parser means
to call a command [2+2] and give it the arguments "->" and "x". Changing
Tcls parser to recognize this in your or my way, would be a total change in
semantics and surely break masses of old code...

But the good thing is, that it can be done in pure Tcl just for
demonstration. This is the reason, why I often implement small special
languages for special purposes just by bending Tcl a little bit around.

Stephan

[Stéphane A.]

Christian Gollwitzer a écrit :

> Maths (analytics on paper) is usually done in infix notation for good
> reasons: It makes the structure of expressions clear. You don't want to
> transform them into RPN for the sake of computation by hand. RPN is only
> good for very short expressions, not for
>
> arctan(x/4*pi^sin(sqrt(y+x^3)))
>
> Christian

Hello,

I agree with you in the sense that infix notation makes expressions
clear.
<DIGRESSION>
While developping math::bigfloat (a Tcllib package), I had to work with
the math::bignum package. It provided a prefix notation for additions,
multiplications, etc... as all operations were Tcl procs.

As Tcl 8.5 with bignums in the core was brought, I rewrote
math::bigfloat
to take advantage of this functionality, and handle bignums as
ordinary integers: with infix notation.
With infix notation, I noticed how some computations were
*under-optimized*,
and fixed it. That would not be the case if I stayed with prefix
notation.
</DIGRESSION>
That is why I am in favor of infix notation for math operators.
But I am not against prefix operators, as long as [expr] provides
a hook to them.
Example :
expr {$a + $b * 4}
could be internally eval'd as
[+ $a [* $b 4]]
and I would not complain.

Any suggestions?

Regards,
Stéphane

[Donal K. Fellows]

Stephan Kuhagen wrote (about [expr {x = 2+2}]):

> Also I think, that this could be much faster than
> set x [expr 2+2]

You're wrong there. Compilation is similarly expensive in both cases,
and the bytecode out is functionally the same, so no change in speed.

Donal.

[Donal K. Fellows]

Stéphane A. wrote:
[...]

> That is why I am in favor of infix notation for math operators.
> But I am not against prefix operators, as long as [expr] provides
> a hook to them.

Enough votes are now in on TIP#174 that we can say for sure that there
will be prefix "operators" in Tcl 8.5 (really Tcl commands that do
mathematical operations and whose names look like [expr] operators). But
the [expr] command is not going away; quite apart from the backward-
-compatability reasons, there are plenty of times when it is nice to
have both forms of syntax.

In terms of implementation, I would expect that by the time 8.5 goes
final the operator-commands will be bytecoded efficiently.

Donal.

[David N. Welton]

>> In LISP, everything is prefix, so the (+ a b) is no surprise.
>> Tcl is similar regarding prefix operators. [expr] is the prefix
>> operator for math but inside it mixes infix notation in - which differs
>> from the philosophy of prefix operators that you have everywhere else
>> in Tcl.
>
> Hm, yes, that's true but... it feels uncomfortable. I think [expr] always as
> a kind of sub-language in Tcl. So I would prefer [expr]s sub-language to
> use infix (at least to stay backward-compatible), but maybe there could be
> a switch to [expr] to change the parser so prefix.

I think it's going to wind up being a question of style. I wouldn't be
happy to read code like this:

set x [+ $y [* [/ $z 20] [% $n $m]] [- 100 $y]]

which is much more cleanly expressed using the existing expr command.

However, this is handy and looks cleaner than having to haul out expr,
braces and all:

set x [* $x 10]

So it'll be a question of educating people to use the proper tool for
the job.

--
David N. Welton
- http://www.dedasys.com/davidw/

Linux, Open Source Consulting
- http://www.dedasys.com/

[Stephan Kuhagen]

David N. Welton wrote:

> I think it's going to wind up being a question of style. I wouldn't be
> happy to read code like this:
>
> set x [+ $y [* [/ $z 20] [% $n $m]] [- 100 $y]]

Me too.

> which is much more cleanly expressed using the existing expr command.
>
> However, this is handy and looks cleaner than having to haul out expr,
> braces and all:
>
> set x [* $x 10]

As I understand the posting from Donal (

"Enough votes are now in on TIP#174 that we can say for sure that there
will be prefix "operators" in Tcl 8.5 (really Tcl commands that do
mathematical operations and whose names look like [expr] operators)."

) this will be in 8.5. I wouldn't vote against it, but I also would love to
have an extension to [expr] to make it understand "x=...", which IMHO
wouldn't break any Tcl-philosophy, since [expr] is a parser for a different
language which gives its result back to Tcl.

> So it'll be a question of educating people to use the proper tool for
> the job.

True. It also depends a little bit on your working environment. If you are
working much with people from a mainstream programming environment and have
to exchange often parts of or full math expressions, you do not always want
to convert expressions (especially, when they are even more complex than
your first example) but instead just copy and paste something or type it in
as usual and have it working.

Stephan

[Stephan Kuhagen]

Donal K. Fellows wrote:

> Enough votes are now in on TIP#174 that we can say for sure that there
> will be prefix "operators" in Tcl 8.5 (really Tcl commands that do
> mathematical operations and whose names look like [expr] operators). But
> the [expr] command is not going away; quite apart from the backward-
> -compatability reasons, there are plenty of times when it is nice to
> have both forms of syntax.

I might not be aware of it, but is there something wrong with [expr]? I get
the feeling, that this is seen as an ugly child by some, which one wants to
hide and replace with more lovely children in Tcl. - The only thing, I do
"not like" with [expr] is the missing assignment operator. Besides that, it
is a very handy tool to do all the typical expression evaluation. One of my
most used Tcl "scripts" is this one...:

---
#!/bin/sh
#\
exec tclsh "$0" "$@"

catch {expr $argv} res
puts $res
---

It was one of my first, too, when working on a system where bc was not
available (and unknown to me...).

Having [expr] extended with an assignment operator would make it even more
useful (at least to me).

Stephan

[Donald Arseneau]

"Donal K. Fellows" <donal.k...@manchester.ac.uk> writes:

> Stéphane A. wrote:
> [...]
> > That is why I am in favor of infix notation for math operators.
> > But I am not against prefix operators, as long as [expr] provides
> > a hook to them.
>
> Enough votes are now in on TIP#174 that we can say for sure that there
> will be prefix "operators" in Tcl 8.5 (really Tcl commands that do
> mathematical operations and whose names look like [expr] operators).

Bleach!

--
Donald Arseneau as...@triumf.ca

[Kevin Kenny]

Stephan Kuhagen wrote:
> As I understand the posting from Donal (
> "Enough votes are now in on TIP#174 that we can say for sure that there
> will be prefix "operators" in Tcl 8.5 (really Tcl commands that do
> mathematical operations and whose names look like [expr] operators)."
> ) this will be in 8.5. I wouldn't vote against it, but I also would love to
> have an extension to [expr] to make it understand "x=...", which IMHO
> wouldn't break any Tcl-philosophy, since [expr] is a parser for a different
> language which gives its result back to Tcl.

Well, I support that (http://tip.tcl.tk/282), but you're not going to
have it in 8.5. We simply haven't time in the curent release schedule,
and we have to get it out the door *sometime*. (And there are a great
many details of assignment-in-expr that still have to be sorted out.
It's harder than it looks.)

--
73 de ke9tv/2, Kevin

[Stephan Kuhagen]

Kevin Kenny wrote:

> Well, I support that (http://tip.tcl.tk/282), but you're not going to
> have it in 8.5. We simply haven't time in the curent release schedule,
> and we have to get it out the door *sometime*.

Yes, please...!

> (And there are a great
> many details of assignment-in-expr that still have to be sorted out.
> It's harder than it looks.)

If it doesn't gets lost, I can wait... I think, it would be good to have a
simple Tcl-only implementation of this TIP, just to play around with it and
look, how it behaves and feels. Maybe if I have some time during the
weekend...

Regards
Stephan

[Donal K. Fellows]

Stephan Kuhagen wrote:
> I might not be aware of it, but is there something wrong with [expr]?

I don't think so, but I'm happy to admit that there are some things
that are more neatly expressed in other ways. But then I am happy (and
I believe many other TCT members are too) if there's several ways to
achieve a given task. As the TIP notes, there's already long-standing
overlap between some expression capabilities and the behaviour of the
[if] command.

(OK, I'd be very happy to see an assignment operator in [expr], but I'd
be even happier to see an 8.5 release done within the next year!)

Donal.

[Donal K. Fellows]

Donald Arseneau wrote:
> Bleach!

What's wrong? Too much sodium hypochlorite?

Donal.

[Joe English]

Stephan Kuhagen wrote:
>
>I might not be aware of it, but is there something wrong with [expr]?

Nothing, really, the problem is having to switch
back and forth between [expr] syntax and Tcl syntax
multiple times in a single statement:

lset f($i) [expr {[lindex $f [expr {$i-1}]] + [lindex $f [expr {$i-2}]]}]

TIP 282 partly addresses this problem by expanding the range
of things that are possible within [expr] syntax. Larry McVoy's
"L" takes that approach to its logical conclusion, where *everything*
is done in [expr](-like) syntax.

TIP#174 tackles the problem from the other direction,
by making [expr] syntax unnecessary:

lset f($i) [+ [lindex $f [- $i 1]] [lindex $f [- $i 2]]]

--Joe English

[Larry Smith]

Stephan Kuhagen wrote:

> If you see it as a game like my original x=2+2 thing, then this is okay for
> me. To really change or extend Tcl in this way, would be a very strange
> change to the syntax rules of Tcl. "2+2 -> x" for the current parser means
> to call a command [2+2] and give it the arguments "->" and "x". Changing
> Tcls parser to recognize this in your or my way, would be a total change in
> semantics and surely break masses of old code...

What is so difficult about adding "->" as a synonym for ";"
and "\n"? Remember, Tcl already has logic to detect the end
of a command. If the command ends with ";" or "\n" then eval-
uate as normal, if it's "->" (and this only requires a one
character lookahead) then scan across white space to the 1st
non-white space, then scan the name of the variable to be
given the result of the evaluation - stopping at ";" or "\n".
You could even get fancy and allow a list of vars:

[= 2 + 2] -> four twicetwo

Both of which get the value "4".

[Bryan Oakley]

Larry Smith wrote:
>
> What is so difficult about adding "->" as a synonym for ";"
> and "\n"? Remember, Tcl already has logic to detect the end
> of a command. If the command ends with ";" or "\n" then eval-
> uate as normal, if it's "->" (and this only requires a one
> character lookahead) then scan across white space to the 1st
> non-white space, then scan the name of the variable to be
> given the result of the evaluation - stopping at ";" or "\n".
> You could even get fancy and allow a list of vars:
>
> [= 2 + 2] -> four twicetwo
>
> Both of which get the value "4".
>

The difficulty is that a fairly common usage of -> would cause
many-a-script to break:

regexp <pattern> $data -> foo bar

[Neil Madden]

Donal K. Fellows wrote:
> Stephan Kuhagen wrote:
>
>>I might not be aware of it, but is there something wrong with [expr]?
>
>
> I don't think so, but I'm happy to admit that there are some things
> that are more neatly expressed in other ways. But then I am happy (and
> I believe many other TCT members are too) if there's several ways to
> achieve a given task. As the TIP notes, there's already long-standing
> overlap between some expression capabilities and the behaviour of the
> [if] command.

Technically, of course, [if] includes *all* of [expr] in its definition,
as do [while] and [for], so there is tons of overlap. That in itself
should indicate that something is wrong with [expr] -- it is so ugly and
cumbersome to compose with other commands that those commands end up
embedding it, either whole or in cut-down form.

-- Neil

[Donal K. Fellows]

Neil Madden wrote:
> Technically, of course, [if] includes *all* of [expr] in its definition,
> as do [while] and [for], so there is tons of overlap. That in itself
> should indicate that something is wrong with [expr] -- it is so ugly and
> cumbersome to compose with other commands that those commands end up
> embedding it, either whole or in cut-down form.

Bah, I didn't mean in that sense. :-) I meant in the sense of it
examining the result of an operation and producing one value if the
value was truth, and another if the value was falsity. That is, the
primary behaviour of [if] and not the secondary behaviour.

Donal.

[R. T. Wurth]

jeng...@flightlab.com (Joe English) wrote in
news:eiafo...@news1.newsguy.com:

I am greatly puzzled. Care to run those examples by us again
with a more detailed explanation? If f is a hash, how is lindex
supposed to work on $f? And if it isn't a hash table, what is
the meaning of f($i)? Where does TIP 282 (or 174) address this?
Are you proposing that when f($i) with a non-array f and an
integer i is encountered that some sort of list indexing be
performed?
--
Rich Wurth

[Stephan Kuhagen]

Donal K. Fellows wrote:

> (OK, I'd be very happy to see an assignment operator in [expr],

Thanks! That's what I wanted to hear! I like the TIP about that very much,
and I think, it will be a great improvement.

> but I'd
> be even happier to see an 8.5 release done within the next year!)

That's true for all of us, I think...

Stephan

[Stephan Kuhagen]

Larry Smith wrote:

> What is so difficult about adding "->" as a synonym for ";"
> and "\n"?

If that would be proposed in a TIP to be included into the language, I bet
there would be the same discussion about it as with {expand}, because (to
me) it feels much like another keyword and syntax-expansion (the same would
be true for "=", which is why I think, it should be part of [expr], and not
of Tcl itself).

But I agree with what you said about getting around the stack operations for
[set]. So if it's about design of a parser and language, this would be a
good decision. But it does not fit into Tcl, I think.

> You could even get fancy and allow a list of vars:
>
> [= 2 + 2] -> four twicetwo
>
> Both of which get the value "4".

What I meant with breaking masses of old code is, that it might introduce
many ambiguities in old code, where the number of arguments after a command
is not fixed. In his posting Bryan Oakley gives this example:

regexp <pattern> $data -> foo bar

which currently means that the matching parts of the pattern are assigned to
variables called "->", "foo" and "bar". This would be a total change of the
semantics in the language, if "->" suddenly would be a assignment operator.

Stephan

[Stephan Kuhagen]

Joe English wrote:

>>I might not be aware of it, but is there something wrong with [expr]?
>
> Nothing, really, the problem is having to switch
> back and forth between [expr] syntax and Tcl syntax
> multiple times in a single statement:
>
> lset f($i) [expr {[lindex $f [expr {$i-1}]] + [lindex $f [expr
> {$i-2}]]}]

True, switching syntax is confusing. But that line of code is confusing
anyway. So if I write such code, I break it up into several lines and
statements (even makes my LOC-count look much better... ;-) and then having
a clean [expr] at the end. And if [expr] had an assignment operator, it
even would look much clearer.

> TIP#174 tackles the problem from the other direction,
> by making [expr] syntax unnecessary:
>
> lset f($i) [+ [lindex $f [- $i 1]] [lindex $f [- $i 2]]]

This is the real Tcl-way to do it, it fits good into the language. But it
doesn't feel good to me. I (and many others I think) are used to the more
common infix syntax of math expressions and IMHO they are much less error
prone than prefix notation (at least for math, not for common programming,
of course). So I would like best (I hope, I understand your example above
correctly) something like this:

set var0 [lindex $f $i-1] ;# the "$i-1" works in 8.5
set var1 [lindex $f $i-2]
expr f($i) = $var0 + $var1

Stephan

[Fredderic]

On Wed, 01 Nov 2006 10:48:41 +0100,
"David N. Welton" <dav...@dedasys.com> wrote:

> set x [* $x 10]

That'd have the same double-parsing issues as [expr $x * 10], vs. the
braced [expr {$x * 10}]. So prefix-math operators as commands wouldn't
help on that count. You'd still end up having to write [* {$x 10}],
which just looks really, really odd. ;)

Only two places I can see where the math-operator functions would be
handy;

1) when you want the pass a math operator to a [map]-like function,
having functions for the maths operators already makes like easier.
(Being able to reference the maths operators from the tclmath namespace
would do just fine in this case.)

2) when you want to perform the math op on multiple arguments. Such as
[+ $x $y 10 -$z] to calculate 10 plus the sum of $x and $y. If it'll
concatenate its arguments, including lists, then you could also say
something like [- 100 $list], which would be equivalent to something
along the lines of [expr 100 - [join $list +]].

Fredderic

[Donal K. Fellows]

Fredderic wrote:

> David N. Welton wrote:
>> set x [* $x 10]
> That'd have the same double-parsing issues as [expr $x * 10], vs. the
> braced [expr {$x * 10}].

No, since the arguments to [*] are treated as values, not expression pieces.

Donal.

[Fredderic]

On Tue, 31 Oct 2006 21:40:29 -0700,
"Michael A. Cleverly" <mic...@cleverly.com> wrote:

> On Tue, 31 Oct 2006, suchenwi wrote:
> > I'm not sure whether it's cleaner and less confusing.. but
> > experimenting shows that the dollar parser's bevavior on braces is
> > surprising anyway:
> That's what the ${name} syntax of rule 7 of the endekalogue says.
> (Had to re-read it because I found it surprising at first glance
> too.). Which means there are some names of variables that can be
> retrieved with a [set ...] but not with any form of $ dereferencing.
> That's kind of a fun piece of obscure trivia. :-)

And perfect reason to make ${{...}} a synonym for [expr {...}]... :)

Out of curiosity, would you be able to use a variable name containing a
brace, in an [expr]...? Would [expr {$\{foo + 6}] work? "{foo" is a
valid variable name for the $ shortcut, (although "foo}" would not be).

Fredderic

[Andreas Leitgeb]

Fredderic <put_my_n...@optusnet.com.au> wrote:
> And perfect reason to make ${{...}} a synonym for [expr {...}]... :)

I don't think so.
${{$x+1}}
is just one digit less than
[e {$x+1}]
after having [interp alias {} e {} expr]'ed.
(you can think of almost any char for "e", e.g. even "$")

Indeed, not every varname that can be "set" can also be "$"ed.
"$" was added as a sane abbreviation for sane varnames :-) and
even some insane varnames are useable that way, but not all.

> Out of curiosity, would you be able to use a variable name containing a
> brace, in an [expr]...? Would [expr {$\{foo + 6}] work? "{foo" is a
> valid variable name for the $ shortcut, (although "foo}" would not be).

Using varnames with unbalanced braces is just begging to have your
foot perforated with bullets :-)

But, still:
[expr "\${\{foo} + 1"] or [expr {[set \{foo] + 1}]

[Larry Smith]

Stephan Kuhagen wrote:

> regexp <pattern> $data -> foo bar
>
> which currently means that the matching parts of the pattern are assigned to
> variables called "->", "foo" and "bar". This would be a total change of the
> semantics in the language, if "->" suddenly would be a assignment operator.

Yes. It was a clever idiom, but it has closed off this line
of thinking. Maybe we should explore the bounds of unicode.
'→' would work. ;)

[Fredderic]

Do'h... Yeah. Fair enough.

I still get a shiver at the number of new global commands that'll add,
though... Personally, I'd still like to see them implemented within
the TCL math namespace (at least the likes of [sin] and [round]), and
imported into the global namespace by scripts that use them enough to
need it.

Or is this the start of a push to phase out the [expr] command
entirely?

Fredderic

[Fredderic]

On 02 Nov 2006 13:43:41 GMT,
Andreas Leitgeb <a...@gamma.logic.tuwien.ac.at> wrote:

> Fredderic <put_my_n...@optusnet.com.au> wrote:
> > And perfect reason to make ${{...}} a synonym for [expr
> > {...}]... :)
> I don't think so.
> ${{$x+1}}
> is just one digit less than
> [e {$x+1}]
> after having [interp alias {} e {} expr]'ed.

But it's still an awful lot easier to read, IMHO. One complaint I've
always had with [expr], is that it's awfully hard trying to follow an
expression that has a few of them, within other commands. [eval
{[command [eval {...}]]}] and the likes... Even abbreviating it to [e]
or [=] as some have done, doesn't help that much; the "[e" is a
distinct word, which makes the matching the brackets harder among
everything else. It should also be very obvious that ${{...}} already
includes the effects of the inner {...} of an [expr {...}].

At any rate.....

> (you can think of almost any char for "e", e.g. even "$")

You still end up with [$ {...}], and it's that space more than anything
that irks me. The fact that it's still two words, where ${{...}} is
very neat and tidy for those annoying short quick expressions that you
get in [lindex] and [lrange] commands (even still, if the extension of
allowing a general addition and subtraction comes into play).

> Using varnames with unbalanced braces is just begging to have your
> foot perforated with bullets :-)

I was going to say something similar about using strangely-named
variables with $, but you said it better. :)

> But, still:
> [expr "\${\{foo} + 1"] or [expr {[set \{foo] + 1}]

Getting into the zany world of back-slash quoting hell there...
The good old [set] command CAN handle anything, of course...

Fredderic

[Joe English]

R. T. Wurth wrote:

>I am greatly puzzled. Care to run those examples by us again
>with a more detailed explanation?

Sorry, I meant to write:

lset f $i [+ [lindex $f [- $i 1]] [lindex $f [- $i 2]]]

--JE

[Donal K. Fellows]

Fredderic wrote:
> I still get a shiver at the number of new global commands that'll add,
> though...

Who said anything about global commands? They're in their own namespace
(and Tcl 8.5 provides the tools to allow you to get access with minimum
fuss).

> Or is this the start of a push to phase out the [expr] command
> entirely?

No.

Donal.

[Andreas Leitgeb]

Joe English <jeng...@flightlab.com> wrote:
> lset f $i [+ [lindex $f [- $i 1]] [lindex $f [- $i 2]]]

Fibonacci the hard way ?

[Stephan Kuhagen]

Larry Smith wrote:

> Yes. It was a clever idiom, but it has closed off this line
> of thinking. Maybe we should explore the bounds of unicode.
> '→' would work. ;)

Ah, now we're getting somewhere! Reminds me of another really cool
programming language with a very similar philosophy ;-)

http://compsoc.dur.ac.uk/whitespace/index.php

Stephan

[Fredderic]

On 2 Nov 2006 16:15:04 -0800,

Well why didn't you just say that earlier!!! ;)

Fredderic

[Donal K. Fellows]

Fredderic wrote:
> Well why didn't you just say that earlier!!! ;)

It's in the TIP. I assumed you'd read it instead of basing your comments
purely on a hurried commentary on what's in it. :-p

Donal.

[Fredderic]

On Fri, 03 Nov 2006 13:59:45 +0000,

"Donal K. Fellows" <donal.k...@manchester.ac.uk> wrote:

Bah. I don't know how you manage to keep all those TIPs straight...

I read it a few days before I started paying proper attention to this
thread. I'll be stuffed if I can remember everything it actually said,
I have enough trouble remembering whether I'm using TCL or C, half
the time.

Just earlier today I went and wrote;
printf("Message: %s\n", $message);
Strangely, the C compiler was not overly impressed. ;)

Fredderic

[Larry Smith]

Hmmmmmmm. This is just a wild guess here, but your newsreader
isn't using a unicode font, is it? The above quoted character
is \u2192.

[MH]

In article <20061103224815.6791d337@magentus>,

And here I am thinking you meant the fact that unicode characters can be
proc names.. :-)

Just imagine the poor sod using a non-unicode editor that shows the
characters as " " (space). Trying to figure out WHICH of n procs is being
called could be a lot of fun (and win a few obfuscated Tcl contests too!)

MH

[Fredderic]

On Fri, 3 Nov 2006 20:41:40 +0000 (UTC),
mghe...@eceunix.uwaterloo.ca (MH) wrote:

> And here I am thinking you meant the fact that unicode characters can
> be proc names.. :-)

I'm just waiting for someone to start writing their scripts in l33t
text, using the full wealth of the Unicode character space...

l33t.tcl - renames all core commands to l33t-speak! *shivers*

Fredderic

[Stephan Kuhagen]

Fredderic wrote:

>> It's in the TIP. I assumed you'd read it instead of basing your
>> comments purely on a hurried commentary on what's in it. :-p
>
> Bah. I don't know how you manage to keep all those TIPs straight...

Same for me. Is there something like an overview of TIPs, ordered by
cathegory or something?

Stephan

[Stephan Kuhagen]

Larry Smith wrote:

> Hmmmmmmm. This is just a wild guess here, but your newsreader
> isn't using a unicode font, is it? The above quoted character
> is \u2192.

Ah, okay. But when I set my Newsreader to unicode on your first message, it
also does not show the character...

Stephan

[Donal K. Fellows]

Stephan Kuhagen wrote:
> Is there something like an overview of TIPs, ordered by
> cathegory or something?

There's an index, which is what you see when you go to
<URL:http://tip.tcl.tk/> and look in the main frame. That's how *I*
usually find what a particular TIP means. :-)

Donal.

[Stephan Kuhagen]

Donal K. Fellows wrote:

> There's an index, which is what you see when you go to
> <URL:http://tip.tcl.tk/> and look in the main frame. That's how *I*
> usually find what a particular TIP means. :-)

Oops... :-) - I read the TIPs only from links here in c.l.tcl until now.
http://tip.tcl.tk/ seems to be a good spare time reading...

Thanks
Stephan

[Donal K. Fellows]

Fredderic wrote:
> I'm just waiting for someone to start writing their scripts in l33t
> text, using the full wealth of the Unicode character space...
>
> l33t.tcl - renames all core commands to l33t-speak! *shivers*

That's entirely legal, though you could perhaps write it as below. Just
don't expect third-party packages (or most c.l.t people) to understand. :-)

§⍥บяℂ∊ᅠɫ⍷ℨ┬∙⊤ｃￜ

Donal (my soul is in trouble for this!)

[Uwe Klein]

you have an undying part? How faint!

uwe ;-)

[Darren New]

Uwe Klein wrote:
> you have an undying part?

Not after that post, he doesn't.

--
Darren New / San Diego, CA, USA (PST)
"That's pretty. Where is it?"
"Channelwood."
"We should go there on vacation."
"..."