Will the modules be first-class entites (threated as regular variables, passed as params to functions, etc)?
"1 file = 1 module" (haskell-style, submodules in subdirectories)?
If not (2), will each file require any module Foo header or will it be generated automatically?
If (3), how should the import work in absence of "module to file" mapping? Does only the top module from the file could be imported?
The modules themself shoud be just records of fields (or js-objects). Would they be (after loading) interchangeable with records/objects made in-place?
If (1), we have functions returing modules - "module constructors" or "functors", and as such, parametrised modules. If we have a file with a module definition, could it have parameters? Should a toplevel module possible be a "functor" or should it always be a "grounded" module, only containing a functor?
When doing open List to <context> how should we do it? What to do on name collisions? (the open List as l to <context> is obvious and is equalent to the let l = load 'List' in <context>)
Should the functors be always applicative (producing same output on same input)? If yes, we can cache their invocations. Ground modules could be viewed as functions from nil to some module.
Can the functor call itself?
Can we get a list of names for functor?
Answers:
Yes, modules are first-class.
Kind of. Module a/b/c/foo.lol will be imported as open a/b/c/foo in .... Although, lambda-modules will be allowed in the form of module <let-bindings> {exports <whatever>} end.
There will be no header in the module. There will also be either export function or special syntax for the last statement of the module (after all toplevel lets).
Any module you can reference could be imported. The proposed syntax is [open <thing> to] <context> {or <loadind-failed-handler>} where <thing> is a loaded module. There should be a bunch of functions like local, library, from-url, etc to turn paths to modules. If that loader fails, the loadind-failed-handler is fired feeded by some reason the loader ended with. But for start, we need to make a simple scheme first.
Yes. Loaded modules will be just old good js-objects.
No, toplevel module can't have parameters. The functors must be contained inside the module.
Copy old-namespace, extend, run <context> and throw it out, effectively reverting to old-namespace. Our runtime forces us to overwrite collided names with freshly loaded.
Yes, we're in the land of pure languages. Same input - same output. There be special hacks clever things for IO, though.