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

[Zoltan Somogyi]

On Mon, 30 Oct 2017 20:27:16 -0400 (EDT), Julien Fischer <jfischer at opturion.com> wrote:
> I think foreign_types also need to be included in this list.  (IIRC, the
> pragmas need to be visible to the importing modules, since the pragams
> contain settings that affect representation.)

Agreed, but we already put foreign_type pragmas into interface files.
As I mentioned in my reply to Peter, I was listing only the *new* things
I was proposed putting into interface files.

> Fine with me -- what goes into the interface files is purely an implementation
> detail anyway.  (In fact, hopefully any new interface file syntax can be
> designed to be more efficiently processed by the compiler.)

That was one of my reasons for preferring the new kind of item
over a new kind of where clause in type definition items.

> I propose we get rid of .trans_opt files now.  None of the actual optimizations
> use them.   Some program analyses do, but (a) the results of those program
> analyses do not significantly affect optimization _in practice_ and
> (b) mmc --make is the preferred user level build system and it doesn't support
> them anyway.

I would want to verify that assertion first, and even then I am reluctant
to delete support for a feature that others may use.

> > - Specifying a foreign_type tag pragma for them should be an error.
> 
> I disagree with this.  (And I don't see a problem with allowing it.)
> The usual use case I have for this is where there is a binding
> to some foreign language library that has to be compile, but not
> work in the other target languages.  For example.
> 
>      :- interface.
>      :- type java_thing.
> 
>      :- implementation.
> 
>      % Defn. for Java grade.
>      :- pragma foreign_type("Java", java_thing, "java.lang.Object").
> 
>      % Defn. for non-Java grades.
>      :- type java_thing ---> java_thing.
> 
>      % Predicate defns for Java are foreign procs ...
>      % Predicate defns for non-Java call error/1 ...
> 
> Yes, obviously the non-Java definition for java_thing could be (a non-dummy)
> something else, but defining it as above is nice precisely because it conveys
> no information.

I don't see why the user cannot use a nondummy type in this case, but
you are right: there is not much point in forcing users to use a nondummy type
either.

That leaves the question: should a Mercury type with one functor of arity 0
*with* foreign type pragmas be considered a dummy type in grades in which
none of those pragmas apply? I don't see any reason why it shouldn't,
but then again, I don't see any great urgency in optimizing the representation
of a data item whose first access will abort the program.

> > 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.
> 
> I'm fine with that proposal in principle.  (Since interface files are supposed
> to be grade independent it may need some modification to work properly with
> foreign types.)

The presence of foreign types should not affect this proposal at all.
The compiler already handles that case properly, and I am not proposing
to change that fact.

Zoltan.