 |
lua-l archive |
|
|
||
|
On 9-Aug-05, at 7:17 AM, David Given wrote:
Another comment is that you seem to be very keen on using single-purpose symbols to represent library functions. Unfortunately, this is rather against the whole Lua philosophy; math.min *isn't* a language primitive, it's just alibrary 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.