Go to file
joeduffy 5bdb535c54 Begin doing evaluation
This change checks in an enormously rudimentary interpreter.  There is
a lot left to do, as evidenced by the countless TODOs scattered throughout
pkg/compiler/eval/eval.go.  Nevertheless, the scaffolding and some important
pieces are included in this change.

In particular, to evaluate a package, we must locate its entrypoint and then,
using the results of binding, systematically walk the full AST.  As we do
so, we will assert that aspects of the AST match the expected shape,
including symbols and their types, and produce value objects for expressions.

An *unwind structure is used for returns, throws, breaks, and continues (both
labeled and unlabeled).  Each statement or expression visitation may optionally
return one and its presence indicates that control flow transfer is occurring.
The visitation logic then needs to propagate this; usually just by bailing out
of the current context immediately, but sometimes -- as is the case with
TryCatchBlock statements, for instance -- the unwind is manipulated in more
"interesting" ways.

An *Object structure is used for expressions yielding values.  This is a
"runtime object" in our system and is comprised of three things: 1) a Type
(essentially its v-table), 2) an optional data pointer (for tagged primitives),
and 3) an optional bag of properties (for complex object property values).
I am still on the fence about whether to unify the data representations.

The hokiest aspect of this change is the scoping and value management.  I am
trying to avoid needing to implement any sort of "garbage collection", which
means our bag-of-values approach will not work.  Instead, we will need to
arrange for scopes to be erected and discarded in the correct order during
evaluation.  I will probably tackle that next, along with fleshing out the
many missing statement and expression cases (...and tests, of course).
2017-01-25 10:13:06 -08:00
cmd Move compiler options to pkg/compiler/core 2017-01-23 08:10:49 -08:00
docs Start a MuJS design document 2017-01-17 11:42:49 -08:00
examples Add a example web crawler Mu blueprint 2017-01-12 14:59:18 -08:00
lib Rearrange the library code 2017-01-20 10:30:43 -08:00
pkg Begin doing evaluation 2017-01-25 10:13:06 -08:00
tools/mujs Begin doing evaluation 2017-01-25 10:13:06 -08:00
.gitignore Move all cloud switching to mu/x MuPackage 2017-01-20 09:46:59 -08:00
.gitmodules Add Docker Compose and Kubernetes conversions as submodules 2016-11-01 10:30:39 -07:00
glide.lock Switch back to the official YAML repo 2016-12-09 11:59:05 -08:00
glide.yaml Switch back to the official YAML repo 2016-12-09 11:59:05 -08:00
main.go Move glogging into Mu command startup/teardown 2016-11-19 16:42:27 -08:00
Makefile Test packages when making the project 2016-11-15 19:25:06 -08:00
README.md Add a README pointer to the overview doc 2017-01-01 15:19:22 -08:00

Mu

Mu is a framework and toolset for creating reusable stacks of services.

If you are learning about Mu for the first time, please see the overview document.

Building and Testing

To build Mu, first clone it into a standard Go workspace:

$ mkdir -p $GOPATH/src/github.com/marapongo
$ git clone git@github.com:marapongo/mu $GOPATH/src/github.com/marapongo/mu

A good default value for GOPATH is ~/go.

Mu needs to know where to look for its runtime, library, etc. By default, it will look in /usr/local/mu, however you can override this with the MUPATH variable. Normally it's easiest just to create a symlink:

$ ln -s $GOPATH/src/github.com/marapongo/mu /usr/local/mu

There is one additional build-time dependency, golint, which can be installed using:

$ go get -u github.com/golang/lint/golint

And placed on your path by:

$ export PATH=$PATH:$GOPATH/bin

At this point you should be able to build and run tests from the root directory:

$ cd $GOPATH/src/github.com/marapongo/mu
$ make

This installs the mu binary into $GOPATH/bin, which may now be run provided make exited successfully.