Diff of /sml/branches/primop-branch-gkuan/cm/Overview

Parent Directory | Revision Log | Patch

	revision 340, Fri Jun 18 05:32:46 1999 UTC	revision 348, Tue Jun 22 05:43:46 1999 UTC
#	Line 91	Line 91
91	library gets "stabilized" (see below).  The (not yet implemented)	library gets "stabilized" (see below).  The (not yet implemented)
92	enforcement mechanism must ensure that anyone who stabilizes a library	enforcement mechanism must ensure that anyone who stabilizes a library
93	that wraps P has permission to wrap P.	that wraps P has permission to wrap P.
	(In CM's source code and comments, "wrapped" privileges are referred
	to as "granted" privileges -- which doesn't quite seem to capture the
	actual meaning.)
94
95
96	STABILIZATION	STABILIZATION
#	Line 103	Line 100
100	putting an entire pre-compiled library -- together with its	putting an entire pre-compiled library -- together with its
101	pre-computed dependency graph -- into one single container.  Once this	pre-computed dependency graph -- into one single container.  Once this
102	is done, CM will never need to have access to the original ML source	is done, CM will never need to have access to the original ML source
103	code.  Before actually consulting the description file for a	code.  Before actually consulting the description file for a library,
104	group/library, the parser will always check and see if there is a	the parser will always check and see if there is a stable container.
105	stable container.  If so, it will suck the dependency graph out of the	If so, it will suck the dependency graph out of the container and be
106	container and be done.	done.
107
108	Because of ML's "open" feature, it sometimes is necessary for the	Because of ML's "open" feature, it sometimes is necessary for the
109	dependency analyzer of a group to consult the contents (i.e., the	dependency analyzer of a group to consult the contents (i.e., the
110	definitions) of signatures, structures, or functors that are imported	definitions) of signatures, structures, or functors that are imported
111	from sub-groups/libraries.  Since the pre-computed dependency graph	from sub-libraries.  Since the pre-computed dependency graph does not
112	does not contain such information, it will then become necessary to	contain such information, it will then become necessary to recover it
113	recover it in a different way.	in a different way.
114
115	Remember, the ML source code shouldn't have to be available at this	Remember, the ML source code shouldn't have to be available at this
116	point.  However, the same information is contained in the static	point.  However, the same information is contained in the static
#	Line 121	Line 118
118	result of compiling one ML source file. It contains executable code	result of compiling one ML source file. It contains executable code
119	and a pickled representation of the static environment that is	and a pickled representation of the static environment that is
120	exported from the compilation unit.)  Aside from the dependency graph,	exported from the compilation unit.)  Aside from the dependency graph,
121	the container for a stabilized group/library also stores all the	the container for a stabilized library also stores all the associated
122	associated binfiles.	binfiles.
123
124	Loading (stable) binfiles for the purpose of dependency analysis is	Loading (stable) binfiles for the purpose of dependency analysis is
125	sometimes necessary, but since it is expensive we do it as seldom as	sometimes necessary, but since it is expensive we do it as seldom as
#	Line 131	Line 128
128	GenericVC) is in depend/se2dae.sml. (See the comments there.)  It is	GenericVC) is in depend/se2dae.sml. (See the comments there.)  It is
129	used in stable/stabilize.sml.  (Look for "cvtMemo"!)	used in stable/stabilize.sml.  (Look for "cvtMemo"!)
130
131	Information pertaining to members of stabilized groups/libraries is	Information pertaining to members of stabilized libraries is managed
132	managed by the abstract datatype BinInfo.info (see	by the abstract datatype BinInfo.info (see stable/bininfo.sml).  In
133	stable/bininfo.sml).  In some sense, BinInfo.info is to stabilized ML	some sense, BinInfo.info is to stabilized ML code what SmlInfo.info is
134	code what SmlInfo.info is to not-yet-stabilized ML code.	to not-yet-stabilized ML code.
135
136		By the way, only libraries can be stabilized.  A stabilized library
137		will encompass its own sources as well as the sources of sub-groups
138		(and their sub-groups, and so on).  Sub-libraries of the library, on
139		the other hand, will be referred to symbolically (they do not get
140		"sucked" in like groups do).  In effect, sub-grouping of a library
141		becomes convenient for resolving name-spacing issues without
142		compromising the "one single container" paradigm of stable libraries.
143
144
145	DEPENDENCY GRAPH	DEPENDENCY GRAPH
146	----------------	----------------
147
148	The division into non-stabilized and stabilized groups/libraries is	The division into non-stabilized and stabilized libraries is clearly
149	clearly visible in the definition of the types that make up dependency	visible in the definition of the types that make up dependency graphs.
150	graphs.  There are "BNODE"s that mention BinInfo.info and there are	There are "BNODE"s that mention BinInfo.info and there are "SNODE"s
151	"SNODE"s that mention SmlInfo.info.  (There are also "PNODE"s that	that mention SmlInfo.info.  (There are also "PNODE"s that facilitate
152	facilitate access to "primitive" internal environments that have to do	access to "primitive" internal environments that have to do with
153	with bootstrapping.)	bootstrapping.)
154
155	You will notice that one can never go from a BNODE to an SNODE.  This	You will notice that one can never go from a BNODE to an SNODE.  This
156	mirrors our intention that a subgroup of a stabilized group must also	mirrors our intention that a sub-library of a stabilized library must
157	be stabilized.  From SNODEs, on the other hand, you can either go to	also be stabilized.  From SNODEs, on the other hand, you can either go
158	other SNODEs or to BNODEs.  All the "localimports" of an SNODE (i.e.,	to other SNODEs or to BNODEs.  All the "localimports" of an SNODE
159	the imports that come from the same group) are also SNODEs.  To go to	(i.e., the imports that come from the same group/library) are also
160	a BNODE one must look into the list of "globalimport"s.  Global	SNODEs.  To go to a BNODE one must look into the list of
161	imports refer to "far" nodes -- nodes that are within other groups.	"globalimport"s.  Global imports refer to "far" nodes -- nodes that
162	The edge that goes to such a node can have an export filter attached.	are within other groups/libraries.  The edge that goes to such a node
163	Therefore, a farbnode is a bnode with an optional filter, a farsbnode	can have an export filter attached.  Therefore, a farbnode is a bnode
164	is either a BNODE or an SNODE with an optional filter attached.	with an optional filter, a farsbnode is either a BNODE or an SNODE
165		with an optional filter attached.
166	Imports and exports of a group are represented by "impexp"s.  Impexps
167	are essentially just farsbnodes, but they also contain the dependency	Imports and exports of a group/library are represented by "impexp"s.
168	analyzers "analysis environment" which contains information about the	Impexps are essentially just farsbnodes, but they also contain the
169	actual definition (contents) of exported structures/functors.  As said	dependency analyzers "analysis environment" which contains information
170	earlier, this is necessary to handle the "open" construct of ML.	about the actual definition (contents) of exported
171		structures/functors.  As said earlier, this is necessary to handle the
172	The exports of a group are then simply a mapping from exported symbols	"open" construct of ML.
173	to corresponding impexps. (See depend/ggraph.sml.)
174		The exports of a group/library are then simply represented by a
175		mapping from exported symbols to corresponding impexps. (See
176		depend/ggraph.sml.)
177
178
179	RECOMPILATION AND EXECUTION	RECOMPILATION AND EXECUTION

---

Colored Diff Long Colored Diff Unidiff Context Diff Side by Side

Legend: Removed from v.340   changed lines   Added in v.348

---

root@smlnj-gforge.cs.uchicago.edu	ViewVC Help
Powered by ViewVC 1.0.0