[MLton-devel] mlton bug

[Matthew Fluet]

> > Maybe the right thing to do is to elaborate prefix and suffix inside the
> > basis implementation.
>
> I'm confused.  It looks to me like this is what happens in the code
> you checked in.

No.

fun selectBasisLibrary () =
   let
     val {build, localTopFinish, libs} = basisLibrary ()
     val lib = !Control.basisLibrary
   in
      case List.peek (libs, fn {name, ...} => name = lib) of
	 NONE => Error.bug ("Missing basis library: " ^ lib)
       | SOME {bind, prefix, suffix, ...} =>
	   let
	     val bind =
                localTopFinish
                (fn () => elaborateProg (bind, basisEnv))
	   in
	     {basis = Decs.append (build, bind),
	      prefix = prefix,
	      suffix = suffix}
	   end
   end

Elaborate.Env.localTop used to have the type:
Elaborate.Env.t * (unit -> 'a) * (unit -> 'b) -> ('a * 'b)

And would work by evaluating the first function (call it f) to produce an
extended evironment, evaulating the second function (call it g) and only
keep the binding exported by this second function.  So, we used to do:

local
 <build-basis> (* f *)
in
 <bind-basis> (* g *)
end

<input-prog>
<suffix>

Because <bind> is basis dependent, we can't do the whole localTop when we
build the world.  So, I changed Env.localTop to have the type:
Elaborate.Env.t * (unit -> 'a) * ('a * ((unit -> 'b) -> 'b))
Essentially returning a continuation ready to evaluate the g function.

Anyways, the point is that after localTop is finished evaluating,
everything else that is elaborated is elaborated outside the basis
implementation.

Now things look like

local
 <build> (* f *)
in
 <bind> (* g *)
end

<prefix>
<input-prog>
<suffix>

And prefix, input-prog and suffix are all elaborated after a call to
selectBasisLibrary, so they are all "outside" the basis implementation.

> > It's a little complicated since prefix and suffix are -basis
> > dependent, but I think it's doable.
>
> Oh, do you mean using the same prefix and suffix in the same basis no
> matter what the -basis flag?

No, I'd still have them different in the different basis implementations.
It would just mean having the elaboration of <prefix> and <suffix> occur
inside the g function (i.e., in selectBasisLibrary).  Neither <prefix> nor
<suffix> should have any new bindings, so it won't affect -show-basis
true.

So, change selectBasisLibrary to:

fun selectBasisLibrary () =
   let
     val {build, localTopFinish, libs} = basisLibrary ()
     val lib = !Control.basisLibrary
   in
      case List.peek (libs, fn {name, ...} => name = lib) of
	 NONE => Error.bug ("Missing basis library: " ^ lib)
       | SOME {bind, prefix, suffix, ...} =>
	   let
	     val (bind, prefix, suffix) =
                localTopFinish
                (fn () =>
                 (elaborateProg (bind, basisEnv);
                  elaborateProg (prefix, basisEnv);
                  elaborateProg (suffix, basisEnv)))
	   in
	     {basis = Decs.append (build, bind),
	      prefix = prefix,
	      suffix = suffix}
	   end
   end

> > Of course, then -show-basis-used is going to have weird results,
> > since it will look like more of the basis is used than is available
> > (which is true).
>
> I'm still confused.  Do you mean that with your proposed change that
> "more of the basis is used than is available" or that that is the case
> right now?

What I mean is that the "input program" is really
<prefix>,<input-prog>,<suffix> so the input program consisting of
val _ = ()
would still "use" Posix.Process.exit (and anything else that brought in).
But, this is a pointless argument -- we "use" OS.Process.exit with -basis
basis-2002 even though it's not explicitly in the input program.

> Anyways, I'd be fine with having -basis none bind the primitive types,
> tycons, and excons, as the old -use-basis-library false did.

Easy enough.  Just edit/make
/basis-library/libs/none/top-level/top-level.sml and
/basis-library/libs/none/bind
to export whatever you think is reasonable.

> Also, since the whole idea of -basis none is to keep the code as small
> as possible, I'd vote for adding a call to Posix.Process.exit in the
> suffix, but not OS.Proces.exit.

Again, this would have to be done in the context of moving <prefix> and
<suffix> elaboration into the library implementation.



-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
MLton-devel mailing list
MLton-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mlton-devel