[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
  ...