[m-dev.] discussion about the implementation of compact type representations

[Julien Fischer]

On Mon, 30 Oct 2017, Peter Wang wrote:

>> principle 1:
>>     If a module m1 defines and abtract-exports a type t1, whose
>>     representation, though semantically hidden, could affect decisions
>>     about the representations of other types (t2, t3 etc) defined
>>     *either* in m1 or in other modules, then a description of its
>>     representation SHOULD be included in module m1's interface files.
>>     (I am not sure yet about *which* interface files exactly.)
>>
>>     The abstract-exported type definitions affected this way are
>>
>>     - type constructors whose definitions show that they are dummy
>>       types (if their arity is nonzero, this means all their instances
>>       are also dummy types)
>>
>>     - type constructors whose definitions show that they are notag types
>>
>>     - type constructors whose definitions show that they fit in a given
>>       number of bits that is less than a word in size
>>
>>     - type constructors that are defined to be equivalent to another type t4
>>       that either
>>
>>       - *are* in one of these four categories (if t4 is defined in m1), or
>>       - *may be* in one of these four categories (if t4 is defined outside m1).
>
> I think we require one further condition for types defined to be
> equivalent to an atomic type with a 2-word representation:
> currently only float but may soon include int64 and uint64.

It will definitely include int64 and uint64 ;-)

Julien.