incremental linking

[gurr@pop.mrs.med.ge.com (David Gurr)]

<---- MLj users ---- http://www.dcs.ed.ac.uk/home/mlj/doc/users.html ---->



Currently MLj links & compiles an entire project at a time.  Would it
not be posible to do incremental linking?  The virtues of incremental
linking are both the obvious but also the problem that currently the
only ways to modify (extend, patch, etc) a MLj generated application are

  a) to recompile the whole thing from scratch or,
  b) bumble arround trying to partition the application into parts 
     with Java interfaces

Link iterates over entities but only compiles after it has linked the
entire project.   What about an incremental linker that would link an
entity and compile it to a set of classes, link the next entity and
compile it to a set of classes inheriting from the previous set of
classes, etc.  As the linker iterates over the list of entities, it
accumulates a tymap, SE, supply, and e.  Could these be exported and
stored in the generated zip file (aside, ok make that a jar file) so
that the link&compile could be resumed were it left off?  (I wrote a
quick hack towards an incremental version of link.  It is not working
but it does show what I am thinking.  It is too long to include in
this mail list.  I can email copies to interested persons.).  What I am 
forgeting?  

If this cant be made to work, Java uses interfaces as a hack to
indicate properties of modules.  Could mlj use an interface like
lang.mlj.Clean to indicate that the elements of the module dont need to
be checked for null values etc?  If you are worried that this would
comprise safety, then let the name of the interface be a secret that
only mlj knows but at least I would not need to check for null values
in classes that are generated by mlj.  A further extension of this
idea would be to insert the information that is stored in ocaml's
.mlx files into the .class or .jar files generated by MLj.

-David Gurr

PS  I'm reading "Interlanguage Working ...".  I like what I am
reading.  I wrote the above before I got IWWT, so maybe these
points are addressed in the paper.  

I have not finished reading IWWT, but since there is
no reference to Claudio Russo's work, I would like to suggest
that Java's objects are similar to Claudio Russo's first
class modules and might be a considered as a further step in
negating any need to add a full object oriented extension to MLj.