lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]


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 a
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.