[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).