[m-dev.] Abstract exported dummy types

[Julien Fischer]

On Thu, 19 Oct 2017, Peter Wang wrote:

>>> Note that other modules would need to be recompiled when either an exported dummy type
>>> is changed (with the second way above), or when a nonexported type is changed either
>>> from a dummy type to a nondummy type or vice versa. So the two ways above have similar
>>> performance implications; the difference being that the second is in a way more "honest"
>>> about the costs (and the benefits) of exposing the dummy-ness of the type.
>>
>> Is it possible to not apply the dummy type optimization to abstract
>> exported types (i.e. the dummy type optimization would not apply in both
>> the defining module and any importing ones)?
>
> The compiler could silently disable the dummy type optimization on
> abstract exported types, or require a pragma from the programmer to
> disable the dummy type optimization on that type explicitly.
>
> But I would still prefer if users could define their own abstract
> exported dummy types, by adding a pragma in interface files.
>
> We currently have "where type_is_abstract_enum" to expose something
> about the representation of values of an abstract type while maintaing
> the abstraction barrier, and I think we'll want something for
> fixed-width integer types, too. Exposing the dumminess of a type seems
> like just another aspect of the same idea.

There are two cases here:

1. (as in Mantis 441)

     :- interface.
     :- type fio(T).
     :- implementation.
     :- type fio(T) ---> fio(T).

2.
     :- interface
     :- type fio(T).
     :- implementation.
     :- type fio(T) ---> fio.

(1) is only dummy if T is dummy (e.g. fio(unit)), (2) is always dummy.
Ideally, you would want the dummy type optimization to always apply to
case (2).

Julien.