[m-dev.] another interface file?

Paul Bone 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
>> 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.

Definitly.  It solves some big problems as well as peter's problem.  But
probahly introduces larger, more complicated problems than the current
situation.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: Digital signature
URL: <http://lists.mercurylang.org/archives/developers/attachments/20090604/1f385333/attachment.sig>


More information about the developers mailing list