Home > Archive > Tcl > March 2004 > TIP #174: Math Operators as Commands
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
TIP #174: Math Operators as Commands
|
|
| Kristoffer Lawson 2004-03-27, 12:27 am |
|
TIP #174: MATH OPERATORS AS COMMANDS
======================================
Version: $Revision: 1.1 $
Author: Kristoffer Lawson <setok_at_altparty.org>
State: Draft
Type: Project
Tcl-Version: 8.5
Vote: Pending
Created: Monday, 15 March 2004
URL: http://purl.org/tcl/tip/174.html
WebEdit: http://purl.org/tcl/tip/edit/174
Post-History:
-------------------------------------------------------------------------
ABSTRACT
==========
This TIP describes a proposal for math operators in Tcl as seperate
commands, acting much like the equivalent in the Lisp language. This
would make simple usage of mathematics much clearer and could possibly
facilitate a clean path for future [expr] extendibility.
RATIONALE
===========
While the [expr] command works fairly well for longer mathematical
expressions, it is extremely tedious for the most common uses, such as
handling indices. Take the following example:
set newList [lrange $list [expr {$idx - 5}] [expr {$idx + 5}]]
Many find this particular aspect of Tcl unappealing. It gets
increasingly difficult to read as more and more simple mathematical
expressions build up.
In addition all functions related to mathematics are contained within
the [expr] command with its own separate syntax and thus we effectively
have two different kinds funtions with no obvious relation to one
another: Tcl commands and mathematical functions. This has been shown
to be quite confusing to a new user and decreases the elegance of Tcl
as a whole.
PROPOSED CHANGE
=================
1. I propose a group of Tcl commands which would handle mathematical
operations without the need to use [expr]. Each command would
take a varying amount of arguments and would work such that the
operator is applied to the combination of the first and second
argument. The result of this combination is then used with the
operator for the third argument etc. If only one argument is
given, it is returned as is. A sample implementation of the *+*
command in Tcl follows:
proc + {r args} {
foreach operand $args {
set r [expr {$r + $operand}]
}
return $r
}
2. The exceptions to rule number 1 are the operators ! (logical
NOT), ~ (bitwise NOT) and x?y:z (if-then-else). The first two
only accept one argument while if-then-else accepts three.
3. All operator commands will be kept in the tcl::math::ops
namespace, from which they would most commonly be imported to the
global namespace. Alternatively the math::ops namespace could be
used.
4. Each [expr] mathematical function will be mirrored into a Tcl
command of the same name with the same results as its [expr]
counterpart.
5. Each mathematical command will be kept in the tcl::math
namespace. Alternatively the math namespace could be used.
6. As a result of 4 and 5, current [expr] functions will be marked
in the documentation as deprecated and that the Tcl commands
should be used instead, with a warning in the documentation that
they may be removed at some future time. They will, however, be
kept in the language for as long as deemed necessary for purposes
of backwards compatibility. [expr] functions offer no benefit
over their command counterparts and only result in extra
complexity and redundancy, which is something Tcl has done well
to avoid.
7. The other aspects of the [expr] command will not be affected.
As an example use, let us change the lrange line from above:
set newList [lrange $list [- $idx 5] [+ $idx 5]]
This is clearly shorter and much easier on the eyes. There is no need
to consider the effects of bracing expressions.
It is not the purpose of this TIP to discuss the necessity of providing
an interface for dynamic [expr] expansion, but with the above interface
we could possibly build a mechanism for doing this, by adding new
commands to the appropriate namespace. This would offer an alternative
to [TIP #133]. Problems of precedence etc. that may result in such a
facility are beyond the scope of this TIP.
COPYRIGHT
===========
This document has been placed in the public domain.
-------------------------------------------------------------------------
TIP AutoGenerator - written by Donal K. Fellows
[[Send Tcl/Tk announcements to tcl-announce@mitchell.org
Announcements archived at http://groups.yahoo.com/group/tcl_announce/
Send administrivia to tcl-announce-request@mitchell.org
Tcl/Tk at http://tcl.tk/ ]]
| |
| Donald Arseneau 2004-03-27, 12:27 am |
| Kristoffer Lawson <setok@altparty.org> writes:
> set newList [lrange $list [- $idx 5] [+ $idx 5]]
I, myself, don't find this format clearer at all. It is okay
for [+], because addition is commutative, but seems backwards
for [-]: I read "[- $idx 5]" as "subtract idx from 5" which
is backwards ("subtract, from idx, 5" is the meaning, but it
does not flow naturally).
Donald Arseneau asnd@triumf.ca
| |
| Volker Hetzer 2004-03-27, 12:27 am |
|
"Donald Arseneau" <asnd@triumf.ca> schrieb im Newsbeitrag news:yfizna48ert.fsf@triumf.ca...
> Kristoffer Lawson <setok@altparty.org> writes:
>
>
> I, myself, don't find this format clearer at all. It is okay
> for [+], because addition is commutative, but seems backwards
> for [-]: I read "[- $idx 5]" as "subtract idx from 5" which
> is backwards ("subtract, from idx, 5" is the meaning, but it
> does not flow naturally).
I think one could document that those commands follow the LISP
convention where the idea clearly comes from.
(In the case of -, (- a b) comes to a - b, i.e. just like in infix the
second operand gets subtracted from the first.)
Lots of Greetings!
Volker
| |
| Andreas Leitgeb 2004-03-27, 12:27 am |
| Volker Hetzer <volker.hetzer@ieee.org> wrote:
> "Donald Arseneau" <asnd@triumf.ca>:
> I think one could document that those commands follow the LISP
> convention where the idea clearly comes from.
> (In the case of -, (- a b) comes to a - b, i.e. just like in infix the
> second operand gets subtracted from the first.)
I don't find it a good idea, to document a feature in Tcl by referring
to a different language, which tcl isn't even based on.
expectations are at odds, what [- $num] could mean:
it could be a +/- swap
or it could mean first $num minus nothing (for lack of other operands)
While I find the TIP generally good, at least for the non-kommutative
or non-associative (or both-nons) there should be very strict semantics.
e.g. "-" should only take one or two arguments meaning unary or binary
minus, but not more (to minimize expectations of being able to
subtract an arbitrary list)
regarding the original TIP, I wouldn't remove the mathematical
functions from expr, but instead make any (ascii-named) procedure
from (::tcl)::math::ops automatically available inside expr.
I wonder, how this TIP will go with TIP 176.
either, implementing 176 will catch most of the reasons for 174,
or 174 takes the wind away for 176 (except for end+N, whose use
I don't really understand)
Anyway, I don't want to imply, that these TIPs couldn't both be done.
| |
|
|
| Andreas Leitgeb 2004-03-27, 12:27 am |
| David N. Welton <davidw@dedasys.com> wrote:
> Andreas Leitgeb <avl@gamma.logic.tuwien.ac.at> writes:
>
> Quite the contrary, if you had () instead of [], Tcl would look rather
> more lispish indeed.
fortunately not!
or ome small tcl-script might have to look like:
{AND {set 'x "Hello, World!"}
{puts {valueof 'x}}
{exit}}
perhaps a little overdone... ;-)
| |
| David N. Welton 2004-03-27, 12:27 am |
| Andreas Leitgeb <avl@gamma.logic.tuwien.ac.at> writes:
> David N. Welton <davidw@dedasys.com> wrote:
[color=darkred]
[color=darkred]
[color=darkred]
> fortunately not!
Indeed. Tcl's really  because it strikes a nice balance between
the lisp "syntax", and more hard-wired approaches like Python where
you can't, for instance, create new control constructs in the language
itself.
This TIP is another good step down that path. You can do quick stuff
quickly and simply (almost half the keystrokes!):
[- $x 1.5]
vs
[expr {$x - 1.5}]
and yet still use expr for more complicated notation where infix is
simpler and easier to read. Once again, the best of both worlds!
--
David N. Welton
Consulting: http://www.dedasys.com/
Personal: http://www.dedasys.com/davidw/
Free Software: http://www.dedasys.com/freesoftware/
Apache Tcl: http://tcl.apache.org/
| |
| Melissa Schrumpf 2004-03-27, 12:27 am |
| Volker Hetzer wrote:
> Donald Arseneau schrieb:
[color=darkred]
[color=darkred]
[color=darkred]
> I think one could document that those commands follow the LISP
> convention where the idea clearly comes from.
predates Polish_Notation LISP
--
MKS
| |
| setok@fishpool.com 2004-03-27, 12:27 am |
| Donald Arseneau <asnd@triumf.ca> wrote:
> Kristoffer Lawson <setok@altparty.org> writes:
>
>
> I, myself, don't find this format clearer at all. It is okay
> for [+], because addition is commutative, but seems backwards
> for [-]: I read "[- $idx 5]" as "subtract idx from 5" which
> is backwards ("subtract, from idx, 5" is the meaning, but it
> does not flow naturally).
I find it easy to read in the "stick the operator between its arguments"
way. Ie. [- $idx $x 5] --> $idx - $x - 5. I'm not sure if that's really
that confusing.
--
/ http://www.fishpool.com/~setok/
| |
| Volker Hetzer 2004-03-27, 12:27 am |
|
"Melissa Schrumpf" <reverse-comDOTyahooATm_schrumpf@bogus.address> schrieb im Newsbeitrag
news:reverse-comDOTyahooATm_schrumpf-3EF007.08043226032004@news.newsguy.com...
> Volker Hetzer wrote:
>
>
>
>
>
> predates Polish_Notation LISP
Right you are.
Lots of Greetings!
Volker
| |
| Volker Hetzer 2004-03-27, 12:27 am |
|
"Andreas Leitgeb" <avl@gamma.logic.tuwien.ac.at> schrieb im Newsbeitrag news:slrnc6833i.u3k.avl@gamma.logic.tuwien.ac.at...
> Volker Hetzer <volker.hetzer@ieee.org> wrote:
>
> I don't find it a good idea, to document a feature in Tcl by referring
> to a different language, which tcl isn't even based on.
>
> expectations are at odds, what [- $num] could mean:
> it could be a +/- swap
> or it could mean first $num minus nothing (for lack of other operands)
Ok, but regardless how it is documented, I'd like to see the operators
follow the lisp behavior, or a subset of it.
In this case, (- 1) returns -1.
As for documentation, the format command which follows printf is properly
explained, yet still contains the printf-hint. IMHO something similar should be
possible for the prefix commands.
Btw, a colleague of mine wants to know how much effort it would take
to have expr convert infix to prefix notation and return a tcl script of that.
After all, expr has to create the parse tree anyway and returning a preorder
traversal should be manageable.
Lots of Greetings!
Volker
| |
| John E. Perry 2004-03-29, 12:35 pm |
|
"Andreas Leitgeb" <avl@gamma.logic.tuwien.ac.at> wrote in message
news:slrnc6833i.u3k.avl@gamma.logic.tuwien.ac.at...
> ...
> I don't find it a good idea, to document a feature in Tcl by referring
> to a different language, which tcl isn't even based on.
>
I don't understand the desire to refer to Lisp, myself. I like the tcl
[command plus arguments] just fine, and [expr ...] is an unfortunate (but,
yes, necessary) compromise with the rest of the world.
> expectations are at odds, what [- $num] could mean:
> it could be a +/- swap
> or it could mean first $num minus nothing (for lack of other operands)
>
That's what man pages are for. Anyone who understands the difference
between commutativity and non- knows some convention has to be set up to
cover these cases, whether it's to forbid them, or to choose between several
possibilities, or ...
> While I find the TIP generally good, at least for the non-kommutative
> or non-associative (or both-nons) there should be very strict semantics.
> e.g. "-" should only take one or two arguments meaning unary or binary
> minus, but not more (to minimize expectations of being able to
> subtract an arbitrary list)
>
Personally, I don't see this as necessary. They would need strict semantics
_and_ clear documentation of the choices made (and, maybe, why the choices
were made).
John Perry
| |
| Donal K. Fellows 2004-03-31, 1:39 pm |
| John E. Perry wrote:
> Personally, I don't see this as necessary. They would need strict
> semantics _and_ clear documentation of the choices made (and, maybe,
> why the choices were made).
FWIW, this is *exactly* what TIPs are supposed to provide. I can
usually see what a piece of code does (though there are one or two bits
of the core - the RE engine springs to mind - which are a bit obscure)
but I definitely can't read the programmer's mind three years down the
line...
Donal.
|
|
|
|
|