Arjen MarkusKevin Kenny$Revision: 1.11 $math expr Tcl

This TIP proposes to replace Tcl's math functions, ordinarily created using the Tcl_CreateMathFunc() function, with ordinary Tcl commands created in a known namespace, ::tcl::mathfunc. This change has two chief motivations: it allows programmers to define new math functions at the Tcl level, and it encapsulates the Tcl_Value API so that new math functions can work on data types that are not described adequately as Tcl_Value objects.

The two authors of this TIP, Kevin Kenny and Arjen Markus, have come at wanting the same change to Tcl from two distinct directions. Arjen Markus has been the maintainer of several modules in Tcllib that implement "special functions" such as the exponential integral, the incomplete gamma function and the Bessel functions. He has wanted to have "scripted" math functions available to simplify his notation. In place of a complex expression like ICBzZXQgZiBbZXhwciB7ICR4KltKMCAkeF0gKyBbSjEgW2V4cHIgezIuMCokeH1dXSB9XQ== which is pretty unreadable (and prone to error because of the need to brace the subexpressions), he would like a mechanism for defining new mathematical functions so that he can write: ICBzZXQgZiBbZXhwciB7ICR4KkowKCR4KSArIEoxKDIuMCokeCkgfV0= Donal Fellows has felt the need for such a construct, too, enough to implement a "funcproc" extension that provides it. [] Kevin Kenny has come at the desire for rework of the math function mechanism from a different direction. He has been investigating Tcl Core support for arbitrary-precision integers , and discovered that implementing math functions that accept them as arguments or return them as results would require an incompatible change to the Tcl_Value data type that is used to communicate with the math functions. When the last such change was made (in implementing 64-bit integers ), it required a source code change to several popular extensions that created new math functions min and max. Wishing the incompatibility introduced by to be the last of the type, he decided to eliminate Tcl_Value and use the open-ended Tcl_Obj data type in its place. When he derived the type signature that a math function would have if it accepted its parameters in an array of Tcl_Obj pointers, he discovered that it was identical to the Tcl_ObjCmdProc -- making him ask, "what if math functions really were commands?" This TIP is the result of those two investigations, and proposes a unification of math functions with Tcl commands.

This TIP proposes that: The [expr] command shall be modified so that an expression of the form:ICAgZihhcmcxLGFyZzIsLi4uKQ==shall generate code equivalent to that generated byICAgW3RjbDo6bWF0aGZ1bmM6OmYgW2V4cHIgeyBhcmcxIH1dIFtleHByIHsgYXJnMiB9XSAuLi5dso that math functions are interpreted as Tcl commands whose arguments are parsed as subexpressions. The existing code in [expr] that checks for correct argument counts to the math functions at compile time shall be removed (the general consensus among Core maintainers is that compile-time checks of this sort are a bad idea anyway).Note that the call to tcl::mathfunc::f has no leading namespace delimiter. A search for the function will try to resolve it first relative to the current namespace.The current math functions in Tcl shall be reimplemented as ordinary Tcl commands in the ::tcl::mathfunc namespace; a Tcl interpreter will contain commands ::tcl::mathfunc::abs, ::tcl::mathfunc::acos, etc. The Tcl command [info functions] shall be deprecated in favor of searching for math functions using [info commands] in the appropriate namespace.The C functions Tcl_CreateMathFunc, Tcl_GetMathFuncInfo, and Tcl_ListMathFuncs shall be deprecated in favor of Tcl_CreateObjCommand, Tcl_GetCommandInfo and [info commands]. (The last is provided only in Tcl at the present time; we do not export a C-level interface to enumerate commands in a namespace.) The functions will continue to work for extensions that use them. The Tcl_CreateMathFunc command will create a Tcl command in the ::tcl::mathfunc namespace whose command procedure checks argument count and types and dispatches to the math function handler. The Tcl_GetMathFuncInfo procedure will return TCL_OK or TCL_ERROR according to whether the given math function exists in ::tcl::mathfunc and will return parameter information for (only) those functions defined using Tcl_CreateMathFunc. Functions defined as ordinary Tcl commands shall return TCL_OK but have a parameter count of -1. The Tcl_ListMathFuncs procedure will simply enumerate all the commands in the ::tcl::mathfunc namespace.Several error messages change as a side effect of changing the math function implementation. All of the new messages are more informative than the old ones (for instance, identifying which math function encountered a parameter error rather than a generic "too few/too many arguments to math function"), with the exception of the error message for an unknown function, which is replaced with "unknown command ::tcl::mathfunc::<the_command>" where <the_command> is the name of the missing function.

The proposed change lifts several other restrictions in the way math functions operate: There is no longer any restriction that new math functions must accept a fixed number of arguments, or, indeed, that their arguments and results must be numeric. It will be possible to create variadic functions like:ICAgcHJvYyA6OnRjbDo6bWF0aGZ1bmM6Om1pbiBhcmdzIHs=ICAgICAgIHNldCBtIEluZg==ICAgICAgIGZvcmVhY2ggYSAkYXJncyB7ICAgICAgICAgICBpZiB7ICRhIDwgJG0gfSB7ICAgICAgICAgICAgICAgc2V0IG0gJGE=ICAgICAgICAgICB9ICAgICAgIH0=ICAgICAgIHJldHVybiAkbQ==ICAgfQ==It will be possible to compile Tcl code that refers to a math function that has not yet been defined. That is:ICAgcHJvYyBmb28geyB4IH0gew==ICAgICAgIHNldCBoYXZlX2YgW2xsZW5ndGggW2luZm8gY29tbWFuZHMgOjp0Y2w6Om1hdGhmdW5jOjpmXV0=ICAgICAgIGlmIHsgJGhhdmVfZiB9IHs=ICAgICAgICAgICByZXR1cm4gW2V4cHIgeyBmKCR4KSB9XQ==ICAgICAgIH0gZWxzZSB7ICAgICAgICAgICAuLi4gZmFsbGJhY2sgLi4uICAgICAgIH0=ICAgfQ==will be a valid procedure. (In Tcl 8.4, the procedure will fail to compile if f is not known at compile time, something that runs contrary to the dynamic nature of Tcl.)Namespaces will be able to define their own math functions that are not visible outside those namespaces. If a namespace defines a function [namespace current]::tcl::mathfunc::f, then calls to f in expressions evaluated in that namespace will resolve to it in preference to ::tcl::mathfunc::f. Not only does this rule allow two extensions both to define functions f without collision, but it also allows an extension to override a builtin function such as sin. Alas, all these improvements come at some cost of performance. On Kevin Kenny's machine, the command IGV4cHIge3NpbigwLjMyNSl9 executes in roughly 520 nanoseconds before the change, and 870 nanoseconds afterward. Since the resolution of the function name is cached, name lookup is not the problem; rather, the issue is that invoking the function as a command needs to look for command traces; this whole mechanism costs about 300-350 ns (and has been observed to do so in other contexts). For real-life expressions, the additional cost tends to vanish quickly into statistical noise; variable access (with corresponding checks for traces) and bytecode overhead quickly comes to dominate the performance for all but the simplest expressions.

It is not anticipated that exposing this functionality in a safe interpreter will present any new problems for safety. Any functionality that the interpreter can access by defining or overriding math functions is functionality that would have been available to it by calling the functions as commands.

Extensions coded in C that wish to create math functions accepting parameters of type TCL_EITHER may find that they do not get type coercion from parameters of new numeric types, such as extended-precision integers. The coding change to replace them with Tcl commands is fairly easy and mechanical, at a level of effort comparable to that needed for . Moreover, once it is completed, a math function will be using the known Tcl_CreateObjCmd API, which has been stable since Tcl 8.0 and is unlikely to change substantially in future releases. The tbcload extension will need to implement a small amount of bytecode translation to preserve compatibility with bytecode compiled modules built against earlier versions of Tcl. The reason is that two bytecodes, INST_INVOKE_BUILTIN1 and INST_INVOKE_FUNC1 have been eliminated from Tcl_ExecuteByteCode since the compiler no longer emits them. If this change for some reason should prove infeasible, we can always put the bytecodes back into Tcl_ExecuteByteCode, but the authors of this TIP would prefer to avoid the code bloat.

A reference implementation is committed on the 'tcl-numerics-branch' at SourceForge and may be retrieved with IGN2cyAtZDpleHQ6VVNFUklEQGN2cy5zb3VyY2Vmb3JnZS5uZXQ6L2N2c3Jvb3QvdGNsIGNoZWNrb3V0IC1yVElQMjMyIHRjbF9udW1lcmljcw==

Copyright (c) 2005 by Kevin B. Kenny and Adriaan Markus. All rights reserved. This document may be distributed subject to the terms and conditions set forth in the Open Publication License, version 1.0 [].