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