A specification will be found in a (missing) word doc.
The basic idea is to be able to build "cards" in a cardstack.org sense using functional definitions that are then converted into JavaScript by this compiler.
The input to the compiler is a set of files which are structured purely using indentation (there are no line terminators or block start and end characters). A new block is introduced with an "extra" tab, and lines are continued by having the same number of tabs and one or more spaces. This is all handled by the Blocker.
The output of the Blocker consists of a set of blocks, each of which has one ContinuedLine consisting in turn of one or more physical lines. The physical lines are concatenated (with a space inserted) to make a single line definition (which could have been presented as one line in the first place). A Story navigates the tree of blocks calling "potential" line parsers as appropriate and seeing which of these match and then operating accordingly on nested blocks. This produces a tree of Scope, each of which is a mapping from a name to a definition; each definition in turn may have a nested Scope. This is described in the Parser.
This is then translated into "virtual code" for a "virtual machine". The exact translation and what gets left depends on the individual definitions, but the idea is that the final virtual code is mainly function definitions, together with enough information to understand how objects are laid out and how the functions exist within the overall environment (by which I basically mean types and interfaces).
So far, only the case for normal "functions" has been handled in the HSIE engine.
There needs to be a phase which then resolves the dependency graph. Each function knows what objects it depends on, but these need to be ordered so that operations such as type checking can work in an orderly fashion.
With this virtual form in place, we are in a position to do type checking. Our type checking algorithm is based on the "standard" inference engine first fully described by Hindley and Milner in 1978, but our version owes much more to the detailed implementation given by Peter Hancock in SLPJ's seminal work "The Implementation of Functional Programming Languages". Since the original text is rather formal, significantly mathematical and very "computer science-y", it is somewhat translated in the section Understanding Peter Hancock.
With that understanding in place, I intend to go back and build a typechecker using TDD, building up from the simplest cases (such as a simple, standalone lambda function) to the more complex cases (such as LETRECs).
With the necessary annotations from the type checker, it is then possible to generate actual JavaScript for the functions and cards, and connect to the broader card environment.
The JavaScript runtime is a separate project, see http://github.com/zinikiGareth/flasjs.