Home My Page Projects Code Snippets Project Openings SML/NJ
Summary Activity Forums Tracker Lists Tasks Docs Surveys News SCM Files

SCM Repository

[smlnj] View of /sml/trunk/src/system/smlnj/init/init.cmi
ViewVC logotype

View of /sml/trunk/src/system/smlnj/init/init.cmi

Parent Directory Parent Directory | Revision Log Revision Log

Revision 573 - (download) (annotate)
Thu Mar 9 15:23:52 2000 UTC (20 years, 3 months ago) by blume
File size: 4897 byte(s)
merging back changes from blume_devel_v110_26_2
# spec.cmi
#  (C) 1999 Lucent Technologies, Bell Laboratories
# Author: Matthias Blume (blume@kurims.kyoto-u.ac.jp)
# This is the specification for how to build the "init group".
# The main purpose of the init group is to tie in the runtime system,
# to set up the core environment, and to build the pervasive environment.
# Because of its special nature, the init group cannot be described as
# an ordinary CM library.  Instead, it is built from the DAG description
# in this file.  The bootstrap compiler turns the init group into an
# ordinary stable group.  The boot process fetches core and pervasive
# environment from that stable library.
# Besides core and pervasive environments, the init group can (and does)
# also export additional definitions.  These can be accessed by client code
# (such as the implementation of the Basis library) by simply listing
# "init.cmi : cm" in their respective library description files.  (Since CM
# does not automatically recognize the member class of ".cmi" files, the
# class "cm" must be given explicitly.)  Clients who want to access "init.cmi"
# must be in possession of the privilege named "primitive".
# The specification is basically a DAG: "bind" statements define
# named environments which are the results of compiling the files on the
# right-hand side of "=" wrt. a combination of the environments given
# in parentheses.
# Format of this file:
#  - The file is processed on a line-by-line basis.
#  - Empty lines and lines beginning with "#" are ignored.
#  - Actual whitespace, "=", ",", "(", and ")" are all counted as whitespace.
#     (this means that the syntactic sugar you see below is really just
#      sugar for the human eye; the program that processes this file can
#      do without it)
#  - A line that says "nosplit" disables cross-module inlining (aka
#    "lambda-splitting") until the next line that says "split".
#  - The (single) "rts-placeholder" line acts mostly like a "bind" line.
#    Its purpose is to specify the module that plays the role of a
#    placeholder for the runtime system.
#  - "bind" lines (and the "rts-placeholder" line) must be in topological
#    order (i.e., they cannot access environment names that are being
#    defined later).
#  - The last line that gets processed is the "return" line.
#    It must specify at least two environment names in this order:
#      * the one that is used as the system-wide "core" environment
#      * the one that is used as the system-wide "pervasive" environment
#    For any additional name n the exports of the module that was bound
#    (by "bind") to n are added to the exports of the init group.
#    These exports can be accessed by clients that explicitly list init.cmi
#    in their own description files.
#    Note: Since some clients need direct access to the core environment,
#    the name "core" is listed twice: one time in its usual place, one time
#    to have it exported from init.cmi.
#  - There is one pre-defined name ("primitive") that refers to the
#    Environment.primEnv.  It must not be "exported" by the "return" line.
# There is a side-condition on the core environment:
# CM will first compile just the minimal required number of files that is
# sufficient for getting hold of the core environment.  Naturally, these
# files are compiled _without_ access to core and, therefore, cannot make
# use of any language feature that lets the compiler try and access the core.
# As soon as core is available, all remaining files are compiled using that
# core, though.


# Turn off splitting. It would confuse the compiler because the following
# files are not actually loaded at boot time.

# The "signature" of the runtime system:
bind asig = assembly.sig (primitive)

# The placeholder for the runtime system:
rts-placeholder rts = dummy.sml (asig, primitive)

# We can now turn the cross-module optimizer on (when available)...

# This defines the core environment to be used everywhere else...
bind core = core.sml (rts, asig, primitive)

# The rest of the DAG...
bind built-in = built-in.sml (core, primitive)
bind pp = pre-perv.sml (built-in)
bind ps = pre-string.sml (core, built-in, pp)
bind ss-sig = substring.sig (pp, built-in)
bind ss = substring.sml (ss-sig, pp, ps, core, built-in)
bind print-hook = print-hook.sml (built-in)
bind use-hook = use-hook.sml (built-in)
bind exn-info-hook = exn-info-hook.sml (built-in)
bind init-utils = init-utils.sml (ps ss-sig ss)

# Building the "pervasive" environment.  This file should be
# kept as small as possible and only bind non-modular things
# (i.e., top-level types and values).
bind pervasive = pervasive.sml (core, ps, ss, pp, print-hook, use-hook, exn-info-hook, built-in)

# Report the results to the world...
return (core, pervasive) built-in print-hook use-hook exn-info-hook core init-utils

ViewVC Help
Powered by ViewVC 1.0.0