Re: math.min, math.max

[Coroutines <coroutines@...>]

On Wed, Apr 9, 2014 at 9:43 AM, Dirk Laurie <dirk.laurie@gmail.com> wrote:
> 2014-04-09 17:56 GMT+02:00 Andrew Starks <andrew.starks@trms.com>:
>
>> If huge or -(huge) were the result of (nil), I probably would not patch it
>> and instead change the logic in my code to use the new result, but it
>> doesn't sound like this would be correct.
>
> >From the mathematical point of view, max() can only be defined if
> (a) you know from what ordered set legal values come (b) that set
> has a smallest element. The moment one allows max to accept any
> ordered set, there is no useful value that max() can have -- and nil
> is designed for just that situation. But I would not like to distinguish
> between max() and max(nil).
>

I dunno, I wonder if max()/max(nil) -> 'nothing'  would be more appropriate.

Returning nil usually makes sense in error cases where it is followed
by an error explaining the case -- if there is a problem with the
provided arg list and a max cannot be determined then perhaps
returning nothing at all would be best.  Coercion to nil can take
affect thereafter.

If anything, I'd like to see a max()/min() in the global scope that
invoke __gt, __lt.