[m-dev.] discussion about the implementation of compact type representations
zoltan.somogyi at runbox.com
Tue Oct 31 04:24:01 AEDT 2017
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?
> > - 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.
More information about the developers