Tcl "expr" command change suggestion

16 views
Skip to first unread message

Costas Menico

unread,
Jul 6, 1999, 3:00:00 AM7/6/99
to
It seems to me that the "expr" Tcl command is pretty annoying to have
to type it in everytime you want to do some math. I believe it can be
made optional if Tcl would be smart enough to see that when a command
starts with a digit or a + or -, or a left parenthesis to mean you
want to do math.

Example:


Change: set x [expr 1+2] to: set x [1+2]

Change: set x [expr int($someNumber)] to: set x [+int($someNumber)]

Change: set x [expr sin($rads)] to: set x [(sin($rads))]

Change: set x [expr $val1 + $val2] to: set x [$val1 + $val2]

Also this would help with quick command line math in Wish.

I have not thought of all the intricacies involved but it could work.
Does anyone see a syntactical conflict with this?

Costas Menico

Don Porter

unread,
Jul 6, 1999, 3:00:00 AM7/6/99
to
Costas Menico <costas...@mindspring.com> wrote:
> It seems to me that the "expr" Tcl command is pretty annoying to have
> to type it in everytime you want to do some math. I believe it can be
> made optional if Tcl would be smart enough to see that when a command
> starts with a digit or a + or -, or a left parenthesis to mean you
> want to do math.

You can probably achieve this with an appropriate re-definition of
the [unknown] command. Give it a try.

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

Jeffrey Hobbs

unread,
Jul 6, 1999, 3:00:00 AM7/6/99
to d...@cam.nist.gov, costas...@mindspring.com
Don Porter wrote:
> Costas Menico <costas...@mindspring.com> wrote:
> > It seems to me that the "expr" Tcl command is pretty annoying to have
> > to type it in everytime you want to do some math. I believe it can be
...

> You can probably achieve this with an appropriate re-definition of
> the [unknown] command. Give it a try.

This is in fact what tkcon does when you turn on "Calculator Mode".
When nothing else seems to have worked, it runs it through expr. See
http://www.hobbs.wservice.com/tcl/script/tkcon/

** Jeffrey Hobbs jeff.hobbs @SPAM acm.org **
** I'm really just a Tcl-bot My opinions are MY opinions **

Jeffrey.Hobbs.vcf

Richard.Suchenwirth

unread,
Jul 6, 1999, 3:00:00 AM7/6/99
to costas...@mindspring.com
Costas Menico wrote:
> It seems to me that the "expr" Tcl command is pretty annoying to have
> to type it in everytime you want to do some math. I believe it can be
> made optional if Tcl would be smart enough to see that when a command
> starts with a digit or a + or -, or a left parenthesis to mean you
> want to do math.
> Example:
> Change: set x [expr 1+2] to: set x [1+2]
> Change: set x [expr int($someNumber)] to: set x [+int($someNumber)]
> Change: set x [expr sin($rads)] to: set x [(sin($rads))]
> Change: set x [expr $val1 + $val2] to: set x [$val1 + $val2]
> Also this would help with quick command line math in Wish.
> I have not thought of all the intricacies involved but it could work.
> Does anyone see a syntactical conflict with this?

Of course there is a conflict. Tcl's strictly Polish syntax requires the
first "word" to be the name of a proc/command that is then executed with
the rest of the words, but is free to do whatever with its arguments.
When using [] brackets, their content is evaluated before "set" gets to
see them. Without them, things get easier. How do you like
let x = 1+2
let x = int($someNumber)
let x = $val1+$val2
Looks like back to the BASICs. Yours for only the following one-liner:
proc let {res = args} {upvar $res R; set R [expr $args]}
if you can do without the speed benefits of curlybracing expr's
arguments. Note that the = is the name of a parameter to "let" that is
never used, so you might as well write
let x <- 1+2
let x := 1 + 2
For command line math, what about this minimalism:
proc = args {expr $args}
starring the equal sign in a new role: as proc name that works almost
like expr (curlybracing excluded, again). May be used like
= $t/2 + sin(45) ;# but also:
set t [= $t/2 + sin(45)]

Don't ask what Scriptics can do for you - ask what you can do to Tcl ;-)
--
Schoene Gruesse/best regards, Richard Suchenwirth -- tel. +49-7531-86
2703
> RC DT2, Siemens Electrocom GmbH, Buecklestr. 1-5, D-78467 Konstanz, Germany
> My opinions were not necessarily, or will not necessarily be, mine.

Jeffrey Hobbs

unread,
Jul 6, 1999, 3:00:00 AM7/6/99
to
"Richard.Suchenwirth" wrote:
> For command line math, what about this minimalism:
> proc = args {expr $args}

I believe the following is more efficient:
interp alias {} = {} expr

This is OK for interactive use, but I don't know if you will get the
byte compiler advantage otherwise (probably worth figuring out...).

Jeffrey.Hobbs.vcf

Richard.Suchenwirth

unread,
Jul 6, 1999, 3:00:00 AM7/6/99
to Jeffrey Hobbs
Jeffrey Hobbs wrote:
> I believe the following is more efficient:
> interp alias {} = {} expr
>
> This is OK for interactive use, but I don't know if you will get the
> byte compiler advantage otherwise (probably worth figuring out...).

Yes. Proof:
interp alias {} = {} expr
=
set t 18
= $t/2 + sin(45)
9.85090352453
= {$t/2 + sin(45)}
9.85090352453

Costas Menico

unread,
Jul 6, 1999, 3:00:00 AM7/6/99
to
"Richard.Suchenwirth" <Richard.S...@kst.siemens.de> wrote:


>For command line math, what about this minimalism:
> proc = args {expr $args}

>starring the equal sign in a new role: as proc name that works almost
>like expr (curlybracing excluded, again). May be used like
>= $t/2 + sin(45) ;# but also:
>set t [= $t/2 + sin(45)]

So why is this not standardized? This is a very common command. Also
make ? be the equivalent of "puts"

Costas
cos...@mindspring.com

Bryan Oakley

unread,
Jul 6, 1999, 3:00:00 AM7/6/99
to
Costas Menico wrote:
>
> It seems to me that the "expr" Tcl command is pretty annoying to have
> to type it in everytime you want to do some math. I believe it can be
> made optional if Tcl would be smart enough to see that when a command
> starts with a digit or a + or -, or a left parenthesis to mean you
> want to do math.
>
> Example:
>
> Change: set x [expr 1+2] to: set x [1+2]

Of course, if I chose to do the following, the above would give
unexpected results:

proc {1+1} {args} {
# do something really clever
}

>
> Change: set x [expr int($someNumber)] to: set x [+int($someNumber)]

... likewise,

proc + {args} {
# do something slightly clever
}

So, it might be convenient for general interactive use, it would
introduce a very awkward backward compatibility problem. One could no
longer create procs that match the magic sequence of characters that get
interpreted as expressions.

--
Bryan Oakley mailto:oak...@channelpoint.com
ChannelPoint, Inc. http://purl.oclc.org/net/oakley

Education is full of oversimplified lies which can be
refined into the truth later.

Richard.Suchenwirth

unread,
Jul 6, 1999, 3:00:00 AM7/6/99
to costas...@mindspring.com

Must be historical reasons. The names of the standard set of Tcl
commands borrow from the models of Unix (e.g. expr) or C (e.g. puts) and
hardly ever use characters not in [a-z] (add :: since 8.0) . That Tcl
accepts proc names from empty strings to weird special chars (now even
in Unicode), is a different thing, giving us users lots of freedom, at
the risk of creating private dialects. With the "interp alias" construct
(see Jeff Hobbs' post) we lose no performance by using aliases like =
for expr, ? for puts (, @ for lindex, < for return, etc.?) It is still
valid Tcl, but doesn't look as in the book. I like to play with such
shorties, but am still not quite sure whether it's a Good Thing.

lvi...@cas.org

unread,
Jul 6, 1999, 3:00:00 AM7/6/99
to

According to Costas Menico <costas...@mindspring.com>:
:So why is this not standardized? This is a very common command. Also

:make ? be the equivalent of "puts"

Perhaps because the creators of Tcl never thought of it? I have to
admit, I don't recall in the past 7 years anyone asking for either of
these.

--
<URL: mailto:lvi...@cas.org> Quote: Saving the world before bedtime.
<*> O- <URL: http://www.purl.org/NET/lvirden/>
Unless explicitly stated to the contrary, nothing in this posting
should be construed as representing my employer's opinions.

Joe English

unread,
Jul 6, 1999, 3:00:00 AM7/6/99
to
Costas Menico <costas...@mindspring.com> wrote:
>
>It seems to me that the "expr" Tcl command is pretty annoying to have
>to type it in everytime you want to do some math. I believe it can be
>made optional if Tcl would be smart enough to see that when a command
>starts with a digit or a + or -, or a left parenthesis to mean you
>want to do math.

Hm... The thing I don't like about 'expr' (and 'if', 'while',
and 'for') is that they use a completely different syntax
than the rest of Tcl. I'd like to see:

Change: [expr { ($x + $y + $z) / abs($w) <= 1.0} ]
to: [<= [/ [+ $x $y $z] [abs $w]] 1.0]

--jeng...@flightlab.com

all those crossposts from comp.lang.lisp must be getting to me...

Bryan Oakley

unread,
Jul 6, 1999, 3:00:00 AM7/6/99
to
Joe English wrote:
>
> Costas Menico <costas...@mindspring.com> wrote:
> >
> >It seems to me that the "expr" Tcl command is pretty annoying to have
> >to type it in everytime you want to do some math. I believe it can be
> >made optional if Tcl would be smart enough to see that when a command
> >starts with a digit or a + or -, or a left parenthesis to mean you
> >want to do math.
>
> Hm... The thing I don't like about 'expr' (and 'if', 'while',
> and 'for') is that they use a completely different syntax
> than the rest of Tcl.

Interesting. That thought never occured to me. It seems to me that the
way it works now is the right way to do it. Nevertheless...

> I'd like to see:
>
> Change: [expr { ($x + $y + $z) / abs($w) <= 1.0} ]
> to: [<= [/ [+ $x $y $z] [abs $w]] 1.0]

Prefix notation is almost embarassingly easy to do in tcl (though,
performance suffers a bit). Here's one such example (not a particularly
elegant or fast implementation, but it proves the point and passes the
above little challenge):

# ideally this would use a namespace and one would have
# to do something like "import prefix::*" or something.
# I'll save that as an exercise for the reader...

proc handlePrefix {operation args} {
# note the rather weird syntax of an operator followed by
# a dash followed by an operator, etc. This is probably better
# expressed with each operator on a separate line, but I've
# condensed them to save a little space (which I promptly
# filled up with this comment!)
switch -exact -- $operation {
- - + - * - / {
# simple operations that can handle a list of values
set expression [join $args $operation]
set result [expr $expression]
}

== - <= - >= - < - > {
# equality operations which can take a list, but
# must be processed carefully...
if {[llength $args] < 2} {
error "$operation: wrong number of args"
}
set result 1
set current [lindex $args 0]
foreach operand [lrange $args 1 end] {
if "$current $operation $operand" {
set current $operand
continue
} else {
set result 0
break
}
}
}

abs - double - int {
# functions which require only one argument
if {[llength $args] != 1} {
error "$operation: wrong number of args"
}
set result [expr ${operation}([lindex $args 0])]
}

}
# arrange for result to be returned
set result
}

# define the commands/operators we are prepared to deal with
# of course, one could all all the operators they wish here...
foreach operation [list / + * - < <= == >= > abs int double] {
proc $operation {args} "eval handlePrefix $operation \$args"
}

# a simple test:
set w 15.0
set x 10.0
set y 20.0
set z 30.0

puts -nonewline "this test should return false: "
if {[<= [/ [+ $x $y $z] [abs $w]] 1.0]} {
puts "true"
} else {
puts "false"
}

# another simple test...
set w 60.0
puts -nonewline "this test should return true: "
if {[<= [/ [+ $x $y $z] [abs $w]] 1.0]} {
puts "true"
} else {
puts "false"

Costas Menico

unread,
Jul 6, 1999, 3:00:00 AM7/6/99
to
Bryan Oakley <oak...@channelpoint.com> wrote:

>Costas Menico wrote:
>>
>> It seems to me that the "expr" Tcl command is pretty annoying to have
>> to type it in everytime you want to do some math. I believe it can be
>> made optional if Tcl would be smart enough to see that when a command
>> starts with a digit or a + or -, or a left parenthesis to mean you
>> want to do math.
>>

>> Example:
>>
>> Change: set x [expr 1+2] to: set x [1+2]
>
>Of course, if I chose to do the following, the above would give
>unexpected results:
>
> proc {1+1} {args} {
> # do something really clever
> }

The above will work as long you call your procedure as follows:

{1+1} myArg

I believe what you mean is (using my minimalistic concept):


proc [1+1] {args} {
# do something really clever
}

This should work if you call your procedure as follows:

2 myArg


Costas

cos...@mindspring.com

Costas Menico

unread,
Jul 6, 1999, 3:00:00 AM7/6/99
to
jeng...@flightlab.com (Joe English) wrote:

>Costas Menico <costas...@mindspring.com> wrote:
>>
>>It seems to me that the "expr" Tcl command is pretty annoying to have
>>to type it in everytime you want to do some math. I believe it can be
>>made optional if Tcl would be smart enough to see that when a command
>>starts with a digit or a + or -, or a left parenthesis to mean you
>>want to do math.
>

>Hm... The thing I don't like about 'expr' (and 'if', 'while',
>and 'for') is that they use a completely different syntax

>than the rest of Tcl. I'd like to see:


>
>Change: [expr { ($x + $y + $z) / abs($w) <= 1.0} ]
> to: [<= [/ [+ $x $y $z] [abs $w]] 1.0]
>

I hope you are kidding.....

Costas

cos...@mindspring.com

Bryan Oakley

unread,
Jul 6, 1999, 3:00:00 AM7/6/99
to
Costas Menico wrote:
>
> Bryan Oakley <oak...@channelpoint.com> wrote:
>
> >Costas Menico wrote:
> >>
> >> It seems to me that the "expr" Tcl command is pretty annoying to have
> >> to type it in everytime you want to do some math. I believe it can be
> >> made optional if Tcl would be smart enough to see that when a command
> >> starts with a digit or a + or -, or a left parenthesis to mean you
> >> want to do math.
> >>
> >> Example:
> >>
> >> Change: set x [expr 1+2] to: set x [1+2]
> >
> >Of course, if I chose to do the following, the above would give
> >unexpected results:
> >
> > proc {1+1} {args} {
> > # do something really clever
> > }
>
> The above will work as long you call your procedure as follows:
>
> {1+1} myArg

That's a mighty steep restriction, given the utter predictability of tcl
as it stands today.

>
> I believe what you mean is (using my minimalistic concept):
> proc [1+1] {args} {
> # do something really clever
> }

No, that was not what I meant. The original post suggested tcl
automatically run a command through expr if it looks like an expression
(to quote: "... starts with a digit..."). But if I defined my own proc
to have a name that looked like an expression, it would cause a
conflict. I don't want restrictions on what I can name my procs, or how
I must call them. Complete flexibility in this regard is one of tcl's
strengths, IMO.

So, while it might be nice to try and recognize expressions, it is
fraught with peril.

Richard.Suchenwirth

unread,
Jul 7, 1999, 3:00:00 AM7/7/99
to
Bryan Oakley wrote:
> ...

> Prefix notation is almost embarassingly easy to do in tcl (though,
> performance suffers a bit). Here's one such example (not a particularly
> elegant or fast implementation, but it proves the point and passes the
> above little challenge):
> ...
Cool! I never missed LISPish maths that much, but your implementation
makes great reading! Especially the chaining of comparison operators.
Just one observation: error messages are one of the major interfaces to
users, so I propose to indicate the error reason more clearly, hinting
how to fix it:

> if {[llength $args] < 2} {
> error "$operation: wrong number of args"

**** requires 2 or more arguments"

> if {[llength $args] != 1} {
> error "$operation: wrong number of args"

**** requires exactly one argument"
> }
Just nit-picking, but might save a user some seconds. I really *like* to
see most of Tcl's error messages for their clarity -- sometimes coming
close to an online help. (Ever looked at Python error messages ?-)
NB. As the proposed messages depend directly on the preceding "if"
condition, maybe they could be generated by sth. like an ASSERT macro?

Costas Menico

unread,
Jul 8, 1999, 3:00:00 AM7/8/99
to
Bryan Oakley <oak...@channelpoint.com> wrote:


>>
>> I believe what you mean is (using my minimalistic concept):
>> proc [1+1] {args} {
>> # do something really clever
>> }
>
>No, that was not what I meant. The original post suggested tcl
>automatically run a command through expr if it looks like an expression
>(to quote: "... starts with a digit..."). But if I defined my own proc
>to have a name that looked like an expression, it would cause a
>conflict. I don't want restrictions on what I can name my procs, or how
>I must call them. Complete flexibility in this regard is one of tcl's
>strengths, IMO.

Well you quoted me out of context. Here is the full quote: "...when a


command starts with a digit or a + or -, or a left parenthesis to mean
you want to do math."

A command in Tcl is enclosed in [ ]. It is not enclosed in { }. So
the requirement is that you would still use the command brackets.
E.g. [expr 1 + 1] can be [1 + 1] .

{expr 1 + 1} is not a command unless it is passed on to an evaluator
command (eval) in which case {1 + 1} would work also.

E.g. eval {expr 1 + 1} can be eval {1 + 1}


Costas


Richard.Suchenwirth

unread,
Jul 8, 1999, 3:00:00 AM7/8/99
to costas...@mindspring.com
Costas Menico wrote:
> A command in Tcl is enclosed in [ ].
Sometimes, yes. If its return value shall be used in another command.

> It is not enclosed in { }.

What about "foreach i {red green blue} {puts hello,$i}"

So the requirement is that you would still use the command brackets.
> E.g. [expr 1 + 1] can be [1 + 1]

A command has a name and a sequence of arguments. In your example,
command "1" (legal name) would be called with arguments "+ 1".
As they used to say before Tcl 8.0, "everything is a string" - depends
what you do with it. The few syntax rules in Tcl(n) are enough, and good
enough, for me, and a number of other folks. Still, in Tcl you're free
to do many things you wouldn't even start in other languages.
Introspection. Write a C program that interactively tells you what
functions it contains.
And, as you're interested in alternatives to expr, here's my unknown
proc:

if ![info proc _unknown] {rename unknown _unknown} ;# keep the original
proc unknown {args} {
if [regexp (.+):$ [lindex $args 0] -> name] {
set args [lreplace $args 0 0 $name =]
} ;# allow REBOL-style assignments (foo: bar; bar: 17+4)
if {[lindex $args 1]=="="} {
# maybe an assignment like "x = 3+4" ? (Blanks matter!)
upvar [lindex $args 0] _x
set rest [lrange $args 2 end]
if [llength [info commands [lindex $args 2]]] {
return [set _x [uplevel eval $rest]]
}
set _x $rest ;# this should always work...
catch {set _x [expr $rest]} ;# ...but maybe expr is happy
return $_x
} elseif {[regexp {^([^ ]+)\+\+$} $args -> vname]} {
uplevel [list incr $vname] ;# allow things like "i++" ...
} elseif {[regexp {^([^ ]+)--$} $args -> vname]} {
uplevel [list incr $vname -1] ;# ... or "j--"
} elseif {[regexp {^[-+/\*\.0-9 ()]+$} $args]} {
return [expr $args] ;# pure expression? "(17+4)/3"
} else {eval _unknown $args} ;# let old "unknown" do it
}
For calls like
v = info tclversion ;# maybe assign a proc result (no []!!)
8.1
s = this is a string ;# default: shrink-wrapped string (no ""!)
this is a string
j = sqrt(2)*3 ;# if expr agrees, the result (no [expr..]!)
4.24264068712

Yes, this is still Tcl, and no, it's not like in the book.

Chang LI

unread,
Jul 8, 1999, 3:00:00 AM7/8/99
to
Bryan Oakley wrote:
>

> Prefix notation is almost embarassingly easy to do in tcl (though,
> performance suffers a bit). Here's one such example (not a particularly
> elegant or fast implementation, but it proves the point and passes the
> above little challenge):
>

I like the prefix notation. I do not think there is performance suffer
if you implement the <, =, > as the primary commands. Maybe there is
no expression optimization but may have byte code optimization.

With prefix operations can we solve the accuracy problem?

--
--------------------------------------------------------------
Chang LI, Neatware
email: cha...@neatware.com
web: http://www.neatware.com
--------------------------------------------------------------

Bryan Oakley

unread,
Jul 8, 1999, 3:00:00 AM7/8/99
to
Costas Menico wrote:
>
> Bryan Oakley <oak...@channelpoint.com> wrote:
>
> >>
> >> I believe what you mean is (using my minimalistic concept):
> >> proc [1+1] {args} {
> >> # do something really clever
> >> }
> >
[snip]

>
> Well you quoted me out of context. Here is the full quote: "...when a
> command starts with a digit or a + or -, or a left parenthesis to mean
> you want to do math."
>
> A command in Tcl is enclosed in [ ].

No, not always. Commands also begin at the start of a line, or after a
properly terminated command (eg: after a ';')

> It is not enclosed in { }. So


> the requirement is that you would still use the command brackets.

> E.g. [expr 1 + 1] can be [1 + 1] .
>
> {expr 1 + 1} is not a command unless it is passed on to an evaluator
> command (eval) in which case {1 + 1} would work also.
>

> E.g. eval {expr 1 + 1} can be eval {1 + 1}

But my point is, if I defined a proc as I originally suggested (with
curly braces...):

proc {1+1} {args} {
# do something clever
}

you would then expect to be able to use this command like this:

# it's time to do something clever!
1+1 "some random string"

# or maybe do something normal with the result of something clever:
if {[1+1]} {blah}

See? Here, I'm wanting to call my new "1+1" command. But in your
scheme, since the command looks like an expression according to your
criteria ("...starts with a digit..."), it would get treated as an
expression instead of my command. Not at all what I would expect.

The point being, your suggestion introduces a special case into a
language that has none. It would cause a radical shift in the basic
philosophy of how to program in tcl.

Bryan Oakley

unread,
Jul 8, 1999, 3:00:00 AM7/8/99
to
Chang LI wrote:
>
> Bryan Oakley wrote:
> >
>
> > Prefix notation is almost embarassingly easy to do in tcl (though,
> > performance suffers a bit). Here's one such example (not a particularly
> > elegant or fast implementation, but it proves the point and passes the
> > above little challenge):
> >
>
> I like the prefix notation. I do not think there is performance suffer
> if you implement the <, =, > as the primary commands. Maybe there is
> no expression optimization but may have byte code optimization.
>
> With prefix operations can we solve the accuracy problem?

I'm not sure what accuracy problem you are speaking of. This solution in
no way affects accuracy. All it does is do it's own argument parsing,
rearranging the arguments before sending them to expr. Whatever accuracy
problem exists in expr (if there is one...) will exist in this code.

Chang LI

unread,
Jul 8, 1999, 3:00:00 AM7/8/99
to
Bryan Oakley wrote:
>
Bryan,

I remember there was a discussion about the float accuracy problem
before the Tcl 8.0. I think after the 8.0 there is no problem.

Your parsing should have no problem.



> > With prefix operations can we solve the accuracy problem?
>
> I'm not sure what accuracy problem you are speaking of. This solution in
> no way affects accuracy. All it does is do it's own argument parsing,
> rearranging the arguments before sending them to expr. Whatever accuracy
> problem exists in expr (if there is one...) will exist in this code.

--

lvi...@cas.org

unread,
Jul 8, 1999, 3:00:00 AM7/8/99
to

According to Chang LI <cha...@neatware.com>:
:With prefix operations can we solve the accuracy problem?

Well, in theory, you could call mpexpr or some other math code to handle
higher precision.

Donal K. Fellows

unread,
Jul 9, 1999, 3:00:00 AM7/9/99
to
In article <37848B...@kst.siemens.de>,

Richard.Suchenwirth <Richard.S...@kst.siemens.de> wrote:
> And, as you're interested in alternatives to expr, here's my unknown
> proc:
[...]

> For calls like
> v = info tclversion ;# maybe assign a proc result (no []!!)
> 8.1
> s = this is a string ;# default: shrink-wrapped string (no ""!)
> this is a string
> j = sqrt(2)*3 ;# if expr agrees, the result (no [expr..]!)
> 4.24264068712
> Yes, this is still Tcl, and no, it's not like in the book.

OOh. That was so good I Wiki'ed it! It'll even come out looking good
once the backslash Wikit bug has been fixed...

Donal.
--
Donal K. Fellows http://www.cs.man.ac.uk/~fellowsd/ fell...@cs.man.ac.uk
-- The small advantage of not having California being part of my country would
be overweighed by having California as a heavily-armed rabid weasel on our
borders. -- David Parsons <o r c @ p e l l . p o r t l a n d . o r . u s>

lvi...@cas.org

unread,
Jul 9, 1999, 3:00:00 AM7/9/99
to

According to Donal K. Fellows <fell...@cs.man.ac.uk>:
:In article <37848B...@kst.siemens.de>,

:Richard.Suchenwirth <Richard.S...@kst.siemens.de> wrote:
:> And, as you're interested in alternatives to expr, here's my unknown
:> proc:

:OOh. That was so good I Wiki'ed it! It'll even come out looking good


:once the backslash Wikit bug has been fixed...


I seem to recall other examples of code into the unknown proc over the
years, but alas, I am very certain that trying to search for unknown
and tcl isn't going to be very productive <grin>. Anyone have other
pointers?

Reply all
Reply to author
Forward
0 new messages