[m-users.] Comparison in the reference manual

[Julien Fischer]

On Mon, 9 Nov 2015, Mark Brown wrote:

> On Mon, Nov 9, 2015 at 10:50 AM, Julien Fischer <jfischer at opturion.com> wrote:
>> On Mon, 9 Nov 2015, Peter Wang wrote:
>>> On Mon, 9 Nov 2015 10:09:27 +1100, Paul Bone <paul at bone.id.au> wrote:
>>>> While answering a question on IRC I tried to find the relevant part in
>>>> the
>>>> reference manual for comparison.  Specifically that the order of functors
>>>> in
>>>> a type declaration is significant.  But I could not find it.
>>>>
>>>> Is this written down somewhere?
>>>
>>>
>>> Hi Paul,
>>>
>>> Only implicitly, as far as I am aware.
>>
>>
>> It's written down in compiler/unify_proc.m, but that's not really
>> something you should be pointing users at.  ;-)
>
> It wasn't intended to be part of the language. The language only
> required a standard total ordering to exist, which is sufficient for
> implementing maps and sets. Anything further was undocumented
> behaviour, and not supposed to be relied upon.

Then the that should be stated somewhere, which to the best of my
knowledege it currently isn't.  (It's sort of covered in the
section on user defined comparison.)

>>
>>> Under "Using foreign enumerations in Mercury code" it states:
>>>
>>>   Note that the default comparison for types that are the subject of a
>>> `pragma foreign_enum' declaration will be defined by the foreign
>>> values, rather than the order of the constructors in the type
>>> declaration (as is usually the case).
>
> Hmm. So programs can mean different things when different foreign
> languages are used if the ordering of foreign enums is not consistent.
> Did you mean that to be the case?

Yes, it's not neccessarily under the Mercury programmer's control
anyway.

>>>
>>> In README.Erlang I wrote:
>>>
>>> * Discriminated union values are ordered according to Erlang conventions
>>>  (e.g. alphabetically) instead of according to the order that data
>>>  constructors appear in the type definition.
>
> That's a reason for it to be left undefined: because foreign languages
> can't be expected to be consistent with each other. What are the
> reasons for it to be defined?

I think the issue is the fact that it is undefined needs to be better
documented.

Julien.