[m-dev.] another interface file?

[Julien Fischer]

On Wed, 3 Jun 2009, Peter Wang wrote:

> The java (and il) grades need to be able to expand out imported abstract
> equivalence types, which is currently achieved by simply enabling
> intermodule optimisation.  However this is overkill, increasing compile
> times significantly, and would be very frustrating for program development.
> (Also, intermodule optimisation might not be all that useful as the JVM can
> do its own intermodule optimisations at runtime.)
>
> My idea is to introduce another type of interface file, say .int4, exposing
> the equivalence types which were abstractly exported in the interface (and
> types necessary to make sense of those).  Unlike the other .int* files,
> these would be grade dependent, as C grades don't need them.
>
> Does anyone see problems with this idea, or have an alternative suggestion?

One alternative would be to always hoist abstract equivalance type
definitions (plus any supporting definitions) into the implementation
sections of the existing interface files.  Obviously, this will affect separate
compilation to some extent.  On the upside, it would also make detecting
overlapping type class instances easier.

On a related note, it's probably worth always hoisting abstract unit
dummy types the same way.  Most of the code that I've seen that uses
them effectively does this manually, by putting the definition in a
hidden :- interface section anyway.

Julien.
--------------------------------------------------------------------------
mercury-developers mailing list
Post messages to:       mercury-developers at csse.unimelb.edu.au
Administrative Queries: owner-mercury-developers at csse.unimelb.edu.au
Subscriptions:          mercury-developers-request at csse.unimelb.edu.au
--------------------------------------------------------------------------