[MLton] cvs commit: mlb integration

Matthew Fluet fluet@cs.cornell.edu
Fri, 30 Jul 2004 11:52:22 -0400 (EDT)


A significant practical difference between CM and MLBs is that CM
essentially elaborates a .cm group in a non-empty environment:

   10 The pervasive environment

   The pervasive environment can be thought of as a compilation unit that
   all compilation units implicitly depend upon.  The pervasive enviroment
   exports all non-modular bindings (types, values, infix operators,
   overloaded symbols) that are mandated by the specification for the
   Standard ML Basis Library [RG99]. (All other bindings of the Basis
   Library are exported by $/basis.cm which is a genuine CM library.)

   The pervasive environment is the only place where CM conveys
   non-modular bindings from one compilation unit to another, and its
   definition is fixed.

It will probably be useful to provide something like this as well.  Note
that our use of MLton lib as a Basis Library replacement is somewhat bad
in this respect -- we just want to have

local
  ../../lib/mlton/sources.mlb
  a.sml
  b.sml
in
  ...
end

but then infix status, overload status, unqualified types (like unit,
bool, ref), polymorphic-equality, etc. are not provided by MLton Lib (in a
naive translation of lib/mlton/sources.cm).  You can fake it by writing

local
  $(SML_LIB)/basis/basis.mlb
  ../../lib/mlton/sources.mlb
  a.sml
  b.sml
in
  ...
end

and having MLton Lib override much of the Basis Library, but unqualified
things will still come from the Basis Library; so it doesn't solve the
"type t = Int.t" problem.

In any case, we may well want to provide a $(SML_LIB)/basis/pervasive.mlb.
Then we can either write

local
  $(SML_LIB)/basis/pervasive.mlb
  ../../lib/mlton/sources.mlb
  a.sml
  b.sml
in
  ...
end

or write lib/mlton/sources.mlb as

local
 ...
in
 ...
 $(SML_LIB)/basis/pervasive.mlb
 rebind.sml
end

where rebind.sml has
  type int = Int.t
  type word = Word.t
  ...