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

[Zoltan Somogyi]

On Mon, 30 Oct 2017 18:16:34 +1100, Peter Wang <novalazy at gmail.com> 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.

Agreed. The reason I didn't list it is because we *already* include
this information for such types in interface files, though not in the form
I just proposed.

> > - Specifying a reserve tag pragma for them should be an error.
> 
> Never used reserved tags myself.

They were added for HAL and then for G12. Does G12 still use them?
Julien?

> > 
> > - Specifying a foreign_type tag pragma for them should be an error.
> 
> A small number of types in the standard library will need to be
> trivially changed (io.file_id, dir.stream, etc.).
> User code should be less likely to be broken by this change.

If a type has a foreign_type pragma specified for it on *all* backends,
then the language reference manual allows the programmer to omit
giving a Mercury definition at all.

If there are backends on which these types do *not* have a foreign type,
then we should fix that omission, since a dummy Mercury type clearly
won't work for them.

> > I would prefer a syntax along the lines of
> > 
> > :- type_representation(t6, abstract_enum(N)).
> > :- type_representation(t7, dummy_type).
> > :- type_representation(t8, notag_type).
> > :- type_representation(t9, equivalent_to(t10)).
> > 
> > Distinguishing between interface Mercury and standard Mercury at the top level
> > function symbol of the declaration seems to me to be a cleaner separation.
> > 
> > While we currently represent "where type_is_abstract_enum(N)" declarations
> > using the usual kind of type_defn items, it would be natural to represent
> > type_representation declarations using a different kind of item, and
> > principle 4a could be implemented as a list of this new kind of item.
> > 
> > The type_representation syntax should also be slightly easier to parse;
> > since it does not use any operators, we won't have to worry about their
> > precendences.
> 
> That's fine. Is the lack of 'pragma' to distinguish it from code
> that can be written by the user?

That would be a valid motivation, but it wasn't mine. I simply thought that
the way the compiler needs to handle this information is distinct from the
way it handles all other existing language constructs.

> We also have 'where type_is_abstract_noncanonical' and 'where
> direct_arg' that may be replaced by this new mechanism.

I agree; they should be.

Zoltan.