[m-dev.] for review: Aditi round 2 [2]
Fergus Henderson
fjh at cs.mu.OZ.AU
Mon Aug 3 22:34:43 AEST 1998
On 30-Jul-1998, Simon Taylor <stayl at cs.mu.OZ.AU> wrote:
>
> --- compiler_design.html 1998/06/04 17:26:23 1.20
> +++ compiler_design.html 1998/07/30 03:39:27
> @@ -32,12 +32,12 @@
> stages:
>
> <ol>
> -<li> parsing (source files -> HLDS)
> -<li> semantic analysis and error checking (HLDS -> annotated HLDS)
> -<li> high-level transformations (annotated HLDS -> annotated HLDS)
> -<li> code generation (annotated HLDS -> LLDS)
> -<li> low-level optimizations (LLDS -> LLDS)
> -<li> output C code (LLDS -> C)
> +<li> parsing (source files -> HLDS)
> +<li> semantic analysis and error checking (HLDS -> annotated HLDS)
> +<li> high-level transformations (annotated HLDS -> annotated HLDS)
> +<li> code generation (annotated HLDS -> LLDS or RL)
> +<li> low-level optimizations (LLDS -> LLDS or RL -> RL)
> +<li> output code (LLDS -> C or RL -> bytecode)
Why did you change the `>' to `>' ?
> + <dt> excess.m:
> + <dd>
> + This eliminates assignments that merely introduce another
> + name for an already existing variable. The functionality of
> + this module has been included in simplify.m, however sometime
> + in the future it may be necessary to provide a version which
> + maintains superhomogeneous form.
Hmm, I notice that the only place that imports excess.m is dnf.m,
which does not use it.
If we want to keep it as part of the compiler, just to ensure that the
code doesn't rot too much, then mercury_compile.m is probably the
best place to import it -- and the `:- import_module' declaration
should have a comment.
But it may be better to just delete the import of it from dnf.m
and fix any code rot if/when we come to use it.
These changes should not be part of the Aditi changes, though.
Apart from that, it all looks fine.
--
Fergus Henderson <fjh at cs.mu.oz.au> | "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh> | of excellence is a lethal habit"
PGP: finger fjh at 128.250.37.3 | -- the last words of T. S. Garp.
More information about the developers
mailing list