[erlang-questions] Maps branch and disclaimers

[Jesper Louis Andersen]

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

type x
datatype order = EQ | LT | GT

val compare : x * x -> order

rather than

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


On Tue, Oct 29, 2013 at 8:23 PM, Robert Virding <
robert.virding@REDACTED> wrote:

> You couldn't have values like that, they're not primes.
>
> Robert
>
> ------------------------------
>
> *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!
>
>
>
> --
> J.
>
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://erlang.org/mailman/listinfo/erlang-questions
>
>
>


-- 
J.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20131029/c6d602b8/attachment.htm>