Many find this particular aspect of Tcl unappealing. It gets increasingly
difficult to read as more and more simple mathematical expressions build up.
(See Example below for how these will look after the proposed change.)

Proposed Change

A group of Tcl commands are added which would handle mathematical
operations without the need to use expr. Most commands would take a
variable amount of arguments and would work such that the operator is
applied to the combination of the first and second arguments. 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. See below for
details for each operator. An example implementation of the +
command in Tcl follows:

All operator commands will be kept in the ::tcl::mathop (in line
with ::tcl::mathfunc from [232]) namespace, from which they would most
commonly be imported into the calling namespace (or resolved in it by
means of the namespace path ([229]) command).

The commands are not connected to their corresponding expr operator.
Overloading or adding any command in ::tcl::mathop does not
affect operators in expr or any other command that calls
Tcl_ExprObj, and nor does overriding expr alter the behaviour of
any command in :::tcl::mathop.

Operator Commands Details

Unary operators ~ and ! always take one argument.

Op/argc 0 1 2 3+
~ err ~a err err
! err !a err err

Left-associative operators that naturally allow 0 or more arguments do so:

(Note the single &; a Tcl command is not capable of "short circuit"
evaluation of its arguments.)

The operators that do conditional evaluation of their arguments (&&, || and
?:) are not included. This is because their characteristic evaluation laziness
is best modelled using the existing if command.

Example

This is clearly shorter and much easier on the eyes. There is no need to
consider the effects of bracing expressions.

Sum of a list becomes

set sum [+ {expand}$list]

Security considerations

It is worth noting that variadic operators have no way of "short circuit"
evaluation, much as putative && and || commands would not. This
consideration means that they must be used with caution in cases where
expressions have side effects; all their arguments will be evaluated.
Commands like

< 1 0 [don't do this!]
/ 0 0 [don't do this!]

will indeed evaluate the string in square brackets.

If expressions like these are constructed from user input, care must be taken
to place them in a safe execution environment or otherwise defend against code
injection attacks. (This last consideration is somewhat far-fetched, since it
is implausible that an injection attack would be able to generate [< 1 0
[don't do this!]] but not [< [don't do this!] 0].)

Implementation

Efficiency

These commands can naturally be compiled and thus as efficient as their
corresponding expr operators. The following lines should probably result
in the same byte codes.

set x [expr {$a * $b + $c}]
set x [+ [* $a $b] $c]

Reference Implementation

Available online at SourceForge
http://sf.net/tracker/?func=detail&aid=1578137&group_id=10894&atid=310894 .
The patch is for this TIP as it stood several versions ago; in particular, it
does not implement the ordering comparators and gets associativity wrong in a
couple of other cases. Nevertheless, the authors of this TIP believe it to be
an adequate proof that the ideas of the TIP are implementable with good
performance.