[m-dev.] Abstract exported dummy types

[Zoltan Somogyi]

On Wed, 18 Oct 2017 21:36:34 -0400 (EDT), Julien Fischer <jfischer at opturion.com> 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.

OK, that seems to be the consensus.

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

You are right; these two cases would need the compiler to put two
*different* pragmas into interface files, one to say that fio is a notag type,
the other to say that it is a dummy type.

Julien, how urgent is Mantis 441? I can do a fix that disables optimization
of fio(_) in vfm2.m and fixes the bug that way significantly more quickly
than a fix that generates and uses these new pragmas.

Zoltan.