WIP: first stab at 2nd class modules with type components

[crusso]

This PR contains a first-cut implementation of modules for actorscript.

Modules contain type and value declarations and can be nested. Access to module components is by the dot notion, for both types and value components.

The syntax is extended with a new declaration

module <id> = { decs }

Example

module Collections = {
  module List = {
    type t<T> = ?(T, t<T>);
    func nil<T>() : t<T> = null;
    func cons<T>(x : T, l : t<T>) : t<T> = ?(x, l);
  };
};

type Stack = Collections.List.t<Int>;

func push(x : Int, s : Stack) : Stack = Collections.List.cons<Int>(x, s);

let empty = Collections.List.nil<Int>();

Supported features: (too?) liberal cross module recursion of types and terms.

features:

[X] module renaming via [let ìd = path], provided path is backward looking and an import, module identifier or module path.
[ ] type abstraction (sealing).

Implementation (notes)

• The current implementation extends types with variant Kind (c,k) (k should be removed since c now carries its kind).
• Type syntax is extended with (restricted) paths X. … .Y.t" (better would be .t`)
• Type components are just fields with type Kind _.
• Field lookup is sensitive to type vs value lookup, with punning of type and values allowed.
• Fields are sorted lexicographically by flavour (type or value) and label. Modules are a new sort of object.
• Prepasses for typing recursion look down as well as ahead, descending into module declarations.
• Type components are erased by compilation.

Future plans:

• support full expressions (extended with module ) on rhs of module binding for computed modules.
• add quantifiers to object types so we can properly trreat scoping of concrete and, later, abstract type components.
• add existential introduction via subtyping (<exp> : <module type>)
• (perhaps) replace module declaration by module pattern that eliminates (existential) quantifiers from module values (i.e. integrate module with let). Make current module declaration sugar for
  'let module X = module ', where lhs 'module x' is a new (nestable) pattern.
• add purity restrictions on module contents (otherwise we could just use objects with type components).

[matthewhammer]

The examples in test/run/module1.as look really exciting to me. I look forward to using similar patterns to manage namespaces (of types) in stdlib soon.

Why does the last commit say "not the implementation I want"?

I guess I'm wondering:

• Are there examples that you want to write, but that don't (yet) work?
• Or, is it just that the implementation isn't optimal in some way?
• Or both?

[crusso]

@matthewhammer basically it's a bit hacky at the moment, but I suspect you could pretty much use it for your examples. It does seem to go through the entire pipeline (but that's with minimal testing).

Module renaming doesn't work yet and is potentially tricky with recursion.

So I guess the answer is both.

[ggreif]

I only looked at the example.

[matthewhammer]

LATM.
A = Awesome

[rossberg]

Great stuff, thanks for this! I like the general direction but feel a bit uneasy about some of the details of typing.

Above all, I think we need to make up our minds regarding name-spacing. If we have two separate name spaces for types and terms then we should avoid the hack of a Kind type that isn't a proper type, but rather bite and put two environments into object types.

Still trying to wrap my head around the recursive typing...

[rossberg]

Btw, I'd prefer if we did not get into the habit of merging PRs before the review is complete. ;)

[crusso]

I merged because it was blocking Matthew.

[matthewhammer]

I merged because it was blocking Matthew.

Thanks @crusso; sorry @rossberg!

[matthewhammer]

...using this now to reorganize the stdlib and PX implementation files.