Module system followups

SquidDev commented 5 years ago

In which Pooh discovers that modules weren't as simple as he had been led to believe.

The driver

[x] Cache invalidation: Currently files are stored in the cache forever. Ideally we would be able to detect if a file has changed and, if so, reload it.

I think the best way to handle this is with a clock with a major (tock) and minor (tick) counter. By default, changed files are not reloaded.
- On a new tick (say, a new REPL input), erroring files may be reloaded (as this can be done safely without affecting the environment).
- On a tock (:load), all changed files will be reloaded.
[x] Rethink how we handle errors. Currently we try to be conservative with what modules we report errors from, but this ends up hiding important information.
[x] Prelude support: I know @zardyh is doing some work on this already, but worth thinking about how it integrates with the driver.
[x] Driver monitoring: Can we have a way to listen to various changes within the oracle? This'd be especially useful within the REPL, when using :dump.
[ ] Write tests for it all!

REPL and editor support

[x] Add a :compile out.lua command to the REPL, which just compiles the currently loaded file to Lua, and writes it.
[ ] The current Emacs integration writes to a temporary file and lints that instead. It would be nice to have support for saying "process this text, pretending it's a file in the cache" (and so erroring on loops).
[x] Preserve the cache across :load/:reloads. Currently we trash everything and start again, which is a little wasteful - ideally we'd perform a "tock" (as mentioned in cache invalidation) and re-run the appropriate core.

Note, several of these are dependent on cache invalidation.

Misc

[x] Somewhat related to the REPL, but it might be nice to have a "watch mode", which just monitors changes for files and prints out the latest errors on stdout.
[x] How do we want to handle libraries? There's an argument here for going a Javascript-esque route, where ./foo.ml will be a relative import, and foo will be an absolute one _{(hey it's better than "foo.h" vs <foo.h>)}.

Alternatively, one could go the Futhark route, and just not have any library path instead - everything goes in your source tree!
[x] Support for include. This should be pretty easy - it's pretty much identical to the existing open code, but extending both scopes.

plt-amy commented 5 years ago

Prelude support's happening in feature/guillotine-the-builtins. However, I'm not french, and so I suck at guillotining.

plt-amy commented 5 years ago

Prelude support's done in #184

SquidDev commented 5 years ago

While editor integration is next on my todo list, having done some more research, I don't think it falls under the current module driver system.

I'm going to close this for the time being, and call this iteration of the module system "done". We'll see what emerges over the next few weeks as far as editor logic goes, and how much can be integrated with the existing systems.

amuletml / amulet