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