[m-dev.] another interface file?

Julien Fischer juliensf at csse.unimelb.edu.au
Thu Jun 4 14:57:33 AEST 2009

On Thu, 4 Jun 2009, Paul Bone wrote:

> On Wed, Jun 03, 2009 at 03:41:39PM +1000, 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?
> We may want to add more and more information into interface files in the
> future.  It's feasable to say that we may never know when we've put all the
> information we will ever want into interface files.

If we ever end with all the contents of the original source file in the
interface files we will certanly know!

> We've also considered compiling to a bytecode representation for
> interpretation, this would be useful for debugging.  AIUI this is partially
> implemented.
> I know that it would be a lot of work (and therefore shouldn't delay your work
> on the java grade) but I wonder if we can't find a better solution.

That's overkill for the problem Peter is addressing.

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

More information about the developers mailing list