Re: About the usage of the Compilation Manager.

Thank you so much for your replies. 


On Thu, 2 Jun 2005, Matthias Blume wrote:

> 
> >
> > Currently, I made a simple compiler whose target file is a ".sml".
> > I wanted the source file of this compiler to use datatypes and
> > function defintions defined in other ".sml" files.
> >
> > That is,
> >
> > A.sml  -  defines some datatype D and some function defintion F.
> >
> > B.src  -  uses D and F, and
> >        -  is compiled by my compiler into B.sml.


Sorry for any confusion. The current implementation only allows any
datatype to be declared within .src. It is not equipped with any 
import mechanism yet. I asked my question because I want to equip
my compiler with import mechanism. I am examining several implementation
options for my purpose.  

> 
> How exactly does B.src depend on D and F, i.e.,
> how does your compiler process the contents of A.sml?  Does it
> rely on SML/NJ's internal data structures?  In other words, does
> it require SML/NJ to compile A.sml before it can compile B.src?
> 

That is one option that I am thinking. But I wonder if there is better 
option which is more portable and easier. 

As another option, I want to use the Compilation Manager's functionality
to analyze the dependency among structures. 


Suppose A.sml and B.src.

* A.sml:

  structure A =
  struct

  datatype D = C1 | ... | Cn

  end


* B.src:

  open A         (* import A *)

  ... D ...      (* use the type name  D *)

  ... Ci ....    (* use the constructor names Ci *)

                 (* "..." is NOT an SML expression, of course *)



One scenario that I imagine is this. My compiler first creates B.sml 
for a *temporary* purpose from B.src.


* B.sml: (temporary)

  structure B =
  struct

    open A       (* leave "open A" unchanged for dependency *)
                 (* delete other parts *)

  end


Now I run CM to just analyze the dependency between A and B and 
to store the dependency information somewhere. My compiler restores 
the stored information to compile B.src into a *real* B.sml as

* B.sml: (real)

  structure B =
  struct

    open A 

    ... D ...      (* "..." is some SML expression now. *)

    ... Ci ....    

  end

Finally, I run CM again to compile both A.sml and B.sml together now. 

I would like to know whether this makes sense or not. Also I would like 
to know how hard it is to hack on CM to do this.


Thanks again for John's and Matthias's replies.


Best regards,


Kwanghoon Choi




> If this is the case, then things are rather tricky, and I am afraid
> CM does not currently handle this situation without some serious
> amount of hackery.
> 
> If, however, your compiler merely parses A.sml, then things are simpler
> and will probably work out-of-the-box:
> 
>    1. Write a "Makefile" (for Unix' "make" command) which describes
>       how to invoke your compiler on B.src to make B.sml.  Let's call
>       that file "B.make". The make rule for B.sml would mention A.sml
>       as a dependency.
>    2. Add the following line to your .cm file:
> 
>          B.sml : make (-f B.make)
> 
>    3. A.sml must also be included in your .cm file somewhere.

> 
> I hope this helps.  If it doesn't, please send me e-mail with a
> description of how your compiler works (in particular, how it gets
> at those definitions exported from A.sml), and I will see what
> can be done.


> 
> Kind regards,
> Matthias
> 
> 
> > Finally, A.sml and B.sml are compiled into binaries by SML/NJ.
> >
> >
> > However, in order to compile B.src into B.sml, I need to know what
> > definitions are used by B.src, for example, due to type checking.
> >
> >
> > Q1. Could I specify by CM the order of compilation so that A.sml will
> >     be compiled first and B.src will then be compiled with the  
> > exported
> >     definitions of A.sml?
> >
> > Q2. Moreover, how could I get a list of exported definitions of A.sml
> >     to compile B.src, automatically or by any means I need to do?
> >
> >
> > My situation seems to be more complicated than that of MLyacc and
> > MLlex because the compilation of ".MLYacc" and ".MLLex" itself does
> > not need any exported definitions of other ".sml" files.
> >
> >




-------------------------------------------------------
This SF.Net email is sponsored by Yahoo.
Introducing Yahoo! Search Developer Network - Create apps using Yahoo!
Search APIs Find out how you can build Yahoo! directly into your own
Applications - visit http://developer.yahoo.net/?fr=offad-ysdn-ostg-q22005