[m-dev.] another interface file?

[Paul Bone]

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.

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.

For instance we could create one interface file format that is exensible.  Have
one pass write it out once, and have other passes read it in, possibly reading
only the sections that are relevant.

Alternativly an initial pass of the compiler can generate bytecode
(approximatly similar to the HLDS).  Other information can be included.  later
passes, or passes on dependant modules can read this in, using the information
that is relevant.  When the compiler should generate code for a module it can
parse the bytecode rather than the source skipping part of the front end of the
compiler.

I havn't thought about this too hard, and know that it has at least some
faults.  I understand that some parts in the compiler front end (and IIRC
middle) depend on the compilation grade and backend.  This means that without
care the bytecode will be backend specific.  There may be many other problems
that I havn't though of yet.


-------------- 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/581e811a/attachment.sig>