[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Min and max. Was Re: syntax heresy
- From: Rici Lake <lua@...>
- Date: Tue, 9 Aug 2005 11:24:10 -0500
On 9-Aug-05, at 7:17 AM, David Given wrote:
Another comment is that you seem to be very keen on using
symbols to represent library functions. Unfortunately, this is rather
the whole Lua philosophy; math.min *isn't* a language primitive, it's
library function. Presenting it as a primitive is misleading.
I personally think min and max operators would be a useful addition to
Lua, whether they were called 'min' and 'max', or (borrowing a gcc
extension) '<?' and '>?'. (Actually, \/ and /\ are kind of nice, too.)
The decision as to where to draw the line between built-in operators
and library functions is fairly arbitrary; obviously, Lua is fairly
conservative about operators, but on the other hand it has ^ and will
shortly have #. I probably use min and max more often than either of
those (and not always with numbers). The definition of min and max is
relatively uncontroversial in complete orderings (and the corner case
of NaN is defined by IEEE-754). The additional code required to
implement min and max opcodes (and corresponding metamethods) in the VM
and parser is less than 40 lines.
Having said that, it is not actually clear to me that a binary min
operator is actually appropriate for arbitrary datatypes. The (possibly
pathological) example I have in the back of my head is 'min' of a set
of functions where min is defined as having the shortest runtime.
Suppose then that 'a' and 'b' fail to terminate, but 'c' does. The
naive implementation of min(a, b, c) => min(min(a, b), c)) will fail to
terminate even though there is a well-defined answer. (min(function()
min(a, b) end, c) would work, though, assuming that min(a, b) was
implemented in a reasonable way.)
Of course, the reduction of the concatenation operation to a series of
pairwise concatenations is sub-optimal for many datatypes, so this is
not a problem confined to hypothetical new operators.