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

[Julien Fischer]

On Tue, 31 Oct 2017, Zoltan Somogyi wrote:

>> 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.

To the best of my knowledge no-one has complained about the lack
of optimization due to the contents of the .trans_opts file not being
present.  Users have *frequently* complained about the compile time of
the Mercury system itself; part of the problem there is that building
the standard library .trans_opt files, which IIRC cannot be built in
parallel.

(FWIW, at Opturion we do not use transitive intermodule optimization
since we compile everything with --make.)

>>> - 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.

In the above case it doesn't.  That said, surely the "dummyness"
property only needs to be consistent within a target language not
across different target languages (e.g. if there's an applicable
foreign_type pragma then it's not a dummy type and otherwise it is)?

Julien.