[MLton] caching elaboration

Stephen Weeks MLton@mlton.org
Mon, 16 Aug 2004 12:34:57 -0700


> Now, the problem is that elaboration of a MLB Basdec requires
> non-trivial manipulation of the environment.  So, I don't think it
> makes sense to try to co-routine it in such a way that it returns to
> the main/compile.fun functions between every file (in the implicit
> way that the List.fold above does).

Agreed.

> If we lex/parse the _entire_ program before starting elaboration (as
> we currently do), then we'll never see any benefit in your common
> case, because we'll invariably change one file, which will
> invalidate the assumptions _before_ type-checking even begins.  We
> want to do as much elaboration (and type-checking) as possible
> before encountering the changed file.

Complete agreement here.  This is by far the strongest argument, on
either side, in favor of interleaving parsing and type checking.

> The real question is what should the Basdec datatype look like for
> a source file:
> 
>  | SMLFile of File.t
>  | SMLFile of File.t * Ast.Program.t
>  | SMLFile of File.t * Ast.Program.t Promise.t
> 
> (The same question applies to the variant for an imported mlb file,
> but I assume .mlb files are changing less rapidly than source
> files.) I've currently opted for the second one.  The first one
> would explicitly require doing lexing and parsing from the
> elaborator, while the third one would implicitly prompt the lexing
> and parsing.

Ahh OK.  So, going to the promise is what you meant by the elaborator
prompting lexing and parsing.  Now it makes sense (and seems not too
hard).