[m-dev.] another interface file?
pbone at csse.unimelb.edu.au
Thu Jun 4 15:03:05 AEST 2009
On Thu, Jun 04, 2009 at 02:57:33PM +1000, Julien Fischer wrote:
> 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!
Plus information the compiler deduces from the source file.
>> We've also considered compiling to a bytecode representation for
>> interpretation, this would be useful for debugging. AIUI this is partially
>> 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.
Definitly. It solves some big problems as well as peter's problem. But
probahly introduces larger, more complicated problems than the current
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 197 bytes
Desc: Digital signature
More information about the developers