🚀 go-pugleaf

In article <ROCKWELL.92Apr15220419@socrates.umd.edu>, rockwell@socrates.umd.edu (Raul Deluth Miller-Rockwell) writes:
|> [...]
|> The maximum element of a type is the identity element for the MIN
|> operation. 

Aren't you the one who keeps saying that the programmer shouldn't have
to deal with implementation specific issues - particularly hardware
related ones?  The intuitive meaning for MIN is that it has _no_ 
identity - it is used to compute the minimum of a non-empty collection
of values.  If the collection of values is empty - there is _no_
minimum element.  The minimum element of such an empty collection 
is certainly _NOT_ the maximum value of some implementation dependent
type - a value the collection didn't even contain.

|> [...]
|>    NAN (not a number) might be an appropriate return.
|> 
|> Are you saying that
|>    MIN(NAN, 5)
|> is 5?

No.  I'm saying that MIN() [that is, min applied to nothing] is NAN,
and that otherwise MIN is guaranteed to return a value that was actually
present in its argument.  Better than this would be for MIN() to cause
an exception - then you could _always_ assume that a return value was
a member of the argument collection.

For another thing, what's the identity element of MIN reduced on 
an empty collection of BIGNUMS (arbitrary sized integers)?  What is
the identity element for MIN reduced on an empty collection of
character strings (the infinite length string of whatever character
is at the end of your collating sequence?)?  For that matter, how do 
you determine the base type of an empty collection in your typeless 
language?  Does the empty collection contain no integers, or does it 
contain no arrays of complex, or perhaps is contains no character 
strings, or....

|> [...]
|>    The user should have control over this explicitly though.  The user
|>    should decide what should be done if the array argument to a reduce
|>    is empty.
|> 
|> If that's the case, the user can do so... [obligatory description of
|> turing completeness elided].

Cute, but you haven't specified _how_ the user gets such control.
If it requires considerably different (longer) expressions to do so, 
then I claim your language is broken - the thing you want _most_ 
often (explicit control) should be the default behavior.  The less
common operation (if allowed at all) is the one that should take 
more complicated denotation.

J. Giles