# [erlang-questions] Maps branch and disclaimers

Erik Søe Sørensen <>
Wed Oct 30 08:55:00 CET 2013

```Den 29/10/2013 20.42 skrev "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.

The one argument I see against atoms is that eq < gt < lt - and that is
easily fixable with a view function.

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

Bad example, I'm afraid: the result is 1 whenever the numbers are in order,
either x <y <z or x> y> z; and -1 whenever y is a strict extreme.
(Not that it changes anything much.)

> On Tue, Oct 29, 2013 at 8:23 PM, Robert Virding <
> wrote:
>>
>> You couldn't have values like that, they're not primes.
>>
>> Robert
>>
>> ________________________________
>>>
>>> From: "Jesper Louis Andersen" <>
>>>
>>>
>>> On Tue, Oct 29, 2013 at 7:15 PM, OvermindDL1 <>
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
>>>
>>> http://erlang.org/mailman/listinfo/erlang-questions
>>
>>
>
>
>
> --
> J.
>
> _______________________________________________
> erlang-questions mailing list
>
> http://erlang.org/mailman/listinfo/erlang-questions
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20131030/1a3866b3/attachment.html>
```