[m-dev.] Abstract exported dummy types

[Peter Wang]

On Wed, 18 Oct 2017 19:53:51 -0400 (EDT), Julien Fischer <jfischer at opturion.com> wrote:
> 
> Hi Zoltan,
> 
> On Thu, 19 Oct 2017, Zoltan Somogyi wrote:
> > In any case, the approach above does not allow code passing around values of type t
> > to be optimized outside x.m. We could fix this in one of two ways.
> >
> > One way would for us to put a pragma in x's interface files to say that f is a dummy type.
> 
> Presumably, you mean add the pragma if _t_ is a dummy type?  Or would
> the pragma be on the function that returns the dummy type?
> 
> > The other would be simply to generate an error when a dummy type is abstract exported,
> > requiring the programmer to choose between exporting the definition of the dummy type
> > and keeping the type private but making it non-dummy.
> 
> Removing the abstraction barrier may be potentially unsafe (in this case
> it definitely is); making this type non-dummy (in the case where T is
> dummy) could only be done by making it a non notag type which would
> incur a memory allocation everytime a (non dummy) value is wrapped.
> 
> > 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.

Peter