[erlang-questions] Maps branch and disclaimers
Jesper Louis Andersen
Tue Oct 29 20:41:45 CET 2013
Ok, then lets use, 12572247014351 which happens to be a prime.
No, there are good reasons for not using the integer domain in this way:
first of all, the type of comparisons will be
datatype order = EQ | LT | GT
val compare : x * x -> order
val compare : x * x -> int
Do note, that if we had something like view-types, we can easily convert
from order to the integer domain:
view(eq) -> 0;
view(lt) -> -1;
view(gt) -> 1.
This function is exhaustive in the input type. Whereas the opposite
definition will fail for view(1337), for instance. I do know Erlang is a
unityped language, but whenever there is a possibility of picking an
interface from a polytyped language, they are much to be preferred.
Do note that this is in order with Standard ML and Haskell, whereas Ocaml
chose the int-path. But I still think comparison should be case-analysed.
Another problem with an integer is that
compare(X, Y) * compare(Y, Z) is a valid expression, but it has no meaning
On Tue, Oct 29, 2013 at 8:23 PM, Robert Virding <
> You couldn't have values like that, they're not primes.
> *From: *"Jesper Louis Andersen" <jesper.louis.andersen@REDACTED>
> On Tue, Oct 29, 2013 at 7:15 PM, OvermindDL1 <overminddl1@REDACTED>wrote:
>> +1 for -1, 0, and 1, math simplifies then in cases
> No -1000 for this bad insane idea. Comparison is an algebraic datatype
> with three outcomes: lt, eq or gt. You DON'T use an integer domain to
> represent that. Why not -1337, 0 and +230439204830948320498 instead? They
> are equally good I guess!
> We don't need to diverge from Standard ML. We need to converge!
> erlang-questions mailing list
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the erlang-questions