Re: [MLton] RFC: implement "use" function to support explicit file dependency

I thought this mechanism can be implemented similar to that of the ML Basis system. Please point out if I am wrong.

The mlb files are elaborated with the elaborateMLB function in the Elaborate phase. I guess this phase is able to combine and substitute all the “use” statements with file contents. (I assume the “use” is not a normal function, but a compile time meta-programming.)

For instance, the semantics of this simple file A.sml:

local
  use “B.sml”;
  use “C.sml”;
in 
  (* use B and C here. *)
end

is equivalent to a mlb file A.mlb:
local
  B.sml
  C.sml
in A.sml end

On 5 Feb 2014, at 11:04 am, Christopher Cramer <[email protected]> wrote:

> On Wed, Feb 05, 2014 at 10:16:21AM +1100, James Deng wrote:
>> Here I propose to add implementation of the optional “use” function
>> in the ML basis library, to support explicit file dependencies. To avoid
>> problems, the string argument of “val use: string -> unit” can be
>> restricted to compile-time constants.
> 
> I think this is reasonable, from the perspective of someone using the
> compiler. It's portable and easy to understand.
> 
> But implementing it is not trivial. You'd have to go through the
> stages of the compiler to get to the point where the "use" function is
> understood to be a particular "use" primitive (I guess past FrontEnd,
> which is not expensive), and then rerun all the stages you went through
> to get there. But you'd probably want to get past at least XMLSimplify,
> (after FrontEnd, Elaborate, and Defunctorize; pretty expensive), so you
> could actually understand that the argument to "use" is a constant.
> 
> By that point, it's going to take a lot of time to rerun those stages
> again. Every use of "use" is going to require going through everything
> again, unless you could figure out how to splice a new file into the
> internal representation you already have, which I'm not sure is possible.
> 
> So this would require a substantial reorganization of the compiler, and
> I'm pretty sure it would always be very slow to compile any code using this.
> It's really not in the spirit of a whole-program compiler.
> 
> ------------------------------------------------------------------------------
> Managing the Performance of Cloud-Based Applications
> Take advantage of what the Cloud has to offer - Avoid Common Pitfalls.
> Read the Whitepaper.
> http://pubads.g.doubleclick.net/gampad/clk?id=121051231&iu=/4140/ostg.clktrk
> _______________________________________________
> MLton-devel mailing list
> [email protected]; [email protected]
> https://lists.sourceforge.net/lists/listinfo/mlton-devel

------------------------------------------------------------------------------
Managing the Performance of Cloud-Based Applications
Take advantage of what the Cloud has to offer - Avoid Common Pitfalls.
Read the Whitepaper.
http://pubads.g.doubleclick.net/gampad/clk?id=121051231&iu=/4140/ostg.clktrk

_______________________________________________
MLton-devel mailing list
[email protected]; [email protected]
https://lists.sourceforge.net/lists/listinfo/mlton-devel