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

SCM Repository

[smlnj] Diff of /sml/trunk/HISTORY
ViewVC logotype

Diff of /sml/trunk/HISTORY

Parent Directory Parent Directory | Revision Log Revision Log | View Patch Patch

revision 901, Tue Aug 14 19:21:17 2001 UTC revision 902, Wed Aug 15 21:17:05 2001 UTC
# Line 14  Line 14 
15  ----------------------------------------------------------------------  ----------------------------------------------------------------------
16  Name: Matthias Blume  Name: Matthias Blume
17    Date: 2001/08/15 17:15:00 EDT
18    Tag: blume-20010815-compreorg
19    Description:
21    This is a first cut at reorganizing the CM libraries that make up the
22    core of the compiler.  The idea is to separate out pieces that could
23    be used independently by tools, e.g., the parser, the typechecker, etc.
25    The current status is a step in this direction, but it is not quite
26    satisfactory yet.  Expect more changes in the future.
28    Here is the current (new) organization...
30        What used to be $smlnj/viscomp/core.cm is now divided into
31        six CM libraries:
33             $smlnj/viscomp/basics.cm
34                           /parser.cm
35                           /elabdata.cm
36                           /elaborate.cm
37                           /execute.cm
38                           /core.cm
40        The CM files for these libraries live under src/system/smlnj/viscomp.
41        All these libraries are proxy libraries that contain precisely
42        one CM library component.  Here are the locations of the components
43        (all within the src/compiler tree):
45             Basics/basics.cm
46             Parse/parser.cm
47             ElabData/elabdata.cm
48             Elaborator/elaborate.cm
49             Execution/execute.cm
50             core.cm
52         [This organization is the same that has been used already
53         for a while for the architecture-specific parts of the visible
54         compiler and for the old version of core.cm.]
56         As you will notice, many source files have been moved from their
57         respective original locations to a new home in one of the above
58         subtrees.
60         The division of labor between the new libraries is the following:
62             basics.cm:
63                - Simple, basic definitions that pertain to many (or all) of
64                  the other libraries.
65             parser.cm:
66                - The SML parser, producing output of type Ast.dec.
67                - The type family for Ast is also defined and exported here.
68             elabdata.cm:
69                - The datatypes that describe input and output of the elaborator.
70                  This includes types, absyn, and static environments.
71             elaborator.cm:
72                - The SML/NJ type checker and elaborator.
73                  This maps an Ast.dec (with a given static environment) to
74                  an Absyn.dec (with a new static environment).
75                - This libraries implements certain modules that used to be
76                  structures as functors (to remove dependencies on FLINT).
77             execute.cm:
78                - Everything having to do with executing binary code objects.
79                - Dynamic environments.
80             core.cm:
81                - SML/NJ-specific instantiations of the elaborator and MLRISC.
82                - Top-level modules.
83                - FLINT (this should eventually become its own library)
85    Notes:
87    I am not 100% happy with the way I separated the elaborator (and its
88    data structures) from FLINT.  Two instances of the same problem:
90        1. Data structures contain certain fields that carry FLINT-specific
91           information.  I hacked around this using exn and the property list
92           module from smlnj-lib.  But the fact that there are middle-end
93           specific fields around at all is a bit annoying.
95        2. The elaborator calculates certain FLINT-related information.  I tried
96           to make this as abstract as I could using functorization, but, again,
97           the fact that the elaborator has to perform calculations on behalf
98           of the middle-end at all is not nice.
100        3. Having to used exn and property lists is unfortunate because it
101           weakens type checking.  The other alternative (parameterizing
102           nearly *everything*) is not appealing, though.
104    I removed the "rebinding =" warning hack because due to the new organization
105    it was awkward to maintain it.  As a result, the compiler now issues some of
106    these warnings when compiling init.cmi during bootstrap compilation. On
107    the plus side, you also get a warning when you do, for example:
108       val op = = Int32.+
109    which was not the case up to now.
111    I placed "assign" and "deref" into the _Core structure so that the
112    code that deals with the "lazy" keyword can find them there.  This
113    removes the need for having access to the primitive environment
114    during elaboration.
116    ----------------------------------------------------------------------
117    Name: Matthias Blume
118  Date: 2001/08/13  Date: 2001/08/13
119  Tag: blume-20010813-closures  Tag: blume-20010813-closures
120  Description:  Description:

Removed from v.901  
changed lines
  Added in v.902

ViewVC Help
Powered by ViewVC 1.0.0