Re: [TCLCORE] TIP #266: Numbers are Commands

[<ke...@cr...>]

First, let me say that I appreciate people thinking along the
lines of how to integrate math more tightly into Tcl.  Certainly,
[expr] has always been something of a wart, in that its syntax
doesn't match that of the rest of the language.

That said, I'm profoundly uneasy about the implications of this 
proposal.  Remember that the popular wisdom in Tcl is "always brace
[expr]s." There are several reasons for braced expressions, and
each points out a potential flaw in how these commands will work.

First, expressions are braced for performance.  Several people
discussing this proposal seem to think that "numbers are commands"
as Core functionality will offer a significant performance gain -
perhaps by being byte-compiled.  Alas, I don't see an easy way to do
that - Tcl's dynamic nature means that we can have code like

    proc p {x y} {
        return "$x$y$x"
    }
    set a 0
    set b [$a + 3]
    set a p
    set b [$a + 3]
    set a list
    set b [$a + 3]

where one of the identical statements invokes a "number as value",
one a user procedure, and one a (potentially) bytecoded Core command.
Without much more type inference at compile time than I'm prepared to
offer, I doubt that any Core implementation would do better than a
C-coded [unknown] procedure, and [namespace unknown] would provide a
way to implement such a procedure and confine its scope to a single
namespace.

Perhaps a more important reason for bracing expressions is that they
often involve data from an external medium.  The double evaluation that
happens when an unbraced expression contains additional substituents
is perilous:

    set a {[rm -rf /]}      ;# or {[format C:]} for Windows programmers
    expr $a + 2             ;# has an unexpected side effect
    expr {$a + 2}           ;# comparatively safe

I cannot avoid the nagging feeling that TIP #266 has similar security
implications somewhere.

I'm also uncomfortable with the false expectations that TIP #266 is likely
to raise.  I suspect that if it is implemented, every newcomer to Tcl
will begin to report a "bug" that [$a+2] fails while [$a + 2] works.
Resolving such an issue would mean further analysis of the leading word 
of each command to determine whether it might be the start of an
inlined arithmetic expression, and open further ugly security and performance
issues.

Another subtle point is that Boolean operators perform short-circuit
evaluation.  There would be a subtle expectation that

    set a 0
    $a && [don't do this]

would not display whatever side effects are requested by the second
clause.  This expectation would either mean another irregularity between
[expr] and inlined expressions using "number as command" or else a
subtle but radical change in the way Tcl's command parsing works. I don't
fancy being gored by either horn of that dilemma.

I find Kristoffer's earlier proposal - TIP #174: "Math operators as
commands" to be considerably more attractive, with a few caveats:

   - the behaviour of variadic operators needs to be defined and clearly
     specified
   - the short-circuit operators &&, ||, and ?: must be omitted from
     "operators as commands" because their evaluation behaviour is
     inconsistent with the Tcl command parser
   - we need to be clear about namespace management and the impact of
     "operators as commands" on existing code. Specifically, we need
     to clarify whether operator overloading is or is not in scope.

With those issues resolved, #174 would be an entirely acceptable proposal
to me.  #174 would be easy to interface with the bytecode engine, and
so its commands could run with full performance.

#266 is more attractive superficially, because of the
familiarity of syntax. But precisely because of the fact that it
is introducing foreign syntax into Tcl, it has subtle pitfalls.
Until and unless we understand them better, I can't quite bring
myself to support it.  (And I say that with considerable disappointment;
as I said, [expr] is a wart.)

--
73 de ke9tv/2, Kevin KENNY   GE Corporate Research & Development
ke...@cr...           P. O. Box 8, Bldg. K-1, Rm. 5B36A
                             Schenectady, New York 12301-0008 USA