add something in runtime.NativeObjects for IO too

.gitignore

@@ -0,0 +1,4 @@
+target/
+.ensime
+.ensime_lucene
+.#*

FAQ.md

@@ -0,0 +1,118 @@
+# Moe Frequently Asked Questions
+
+This document will contain answers to questions that either have
+already come up, or which I anticipate will come up. If your
+questions are not answered in that document, please do one of
+the following:
+
+* submit an issue on Github asking the question
+* fork the project, add the question to this file, seek out an
+answer, add it in and submit a pull request
+
+The second option is the more preferred approach of course.
+
+## How much of Perl are you planning to stay compatible with?
+
+A subset.
+
+Exactly what subset, at this point I can not say. This should
+shake out in the next couple weeks or so as I try and spec out the
+language subset.
+
+## Are you going to support XS
+
+Don't you think it is a little early to start asking that?
+
+Actually, my (very, very, very) rough plans for backcompat is to
+lean on an embeddable Perl interpreter somehow (libperl.so). It
+does mean there is some kind of walled garden in between (old)
+Perl 5 and (new) Perl 5, but I don't believe that we could do it
+any other way. Over time I believe it will be possible to evolve
+something closer to what Jesse Vincent proposed in this "5.16 and
+Beyond" talk, but having that as a starting goal I think is
+unreasonable and unrealistic.
+
+## What makes you think you can do this?
+
+Honestly, I don't know if I can, but you never know unless you try.
+
+## Why not C?
+
+To start with, I don't know C, and to be honest I am not all that
+interested in learning it.
+
+Additionally I think that starting it in C would be premature
+optimization. It also defeats the whole "would it be nice to run
+on multiple VMs" idea.
+
+Does that mean I am against using C? No, perhaps if this all
+works out, the final version will be in C, which I am fine with
+as long as it is a compiler and can target multiple runtimes.
+
+## Why not Perl 5?
+
+I don't think Perl 5 is actually a great language to write a
+language in. I really wanted something with a solid type system
+that is statically checked. That said, I am not against eventually
+being self-hosting or something.
+
+## Why Scala?
+
+So, see my above comment about a nice static type system, which
+Scala has and which I find much nicer than other languages like
+Java.
+
+In fact, I originally started to write this in Java, after looking
+over a few different languages, but after two rough implementations
+I kept finding myself running into Java's annoying type system.
+
+I am becoming quite fond of Scala for the following reasons:
+
+* It can interoperate with Java and that entire ecosystem
+* It is enough of a functional programming language to be really
+  nice for writing compilers in, and enough of an OOP language to
+  be easy for those not as familiar with FP
+* The language actually feels Perl-ish
+* It is a useful skill, so if Perl is really dead, then we can all
+  learn a new skill and move on ;)
+
+## Why not $my_favorite_language?
+
+See above.
+
+## Are you planning on sticking with the JVM?
+
+No, not necessarily, the only reason the JVM is involved right
+now is that I am writing this in Scala. I don't plan on only
+having an interpreter; eventually I would love have a compiler
+and then we can target multiple VMs.
+
+## Why do you have a simplistic tree-walking interpreter?
+
+This is the shortest path to a working language that people can
+play with, anything else would be premature optimization.
+
+I do know that an AST interpreter is slow as dirt, but I also
+know that having an AST makes it easier to write a true compiler
+as well. I also know that a stable AST is very important for good
+tooling support (IDE autocompletes, etc).
+
+## Moe?
+
+Modern Perl (Moose) - OS dependency (the JVM) = Moose - OS = Moe
+
+## Perl is Dead
+
+Yes, I know, I wrote [a talk](https://speakerdeck.com/stevan_little/perl-is-not-dead-it-is-a-dead-end) about it.
+
+But if you are just looking to troll, you can go to reddit,
+hackernews or whatever, that is what they are there for.
+
+## What are some good resources for those who want to learn more about Scala
+
+* Twitter's [Scala School](http://twitter.github.com/scala_school/)
+* Programming Scala [OFPS](http://ofps.oreilly.com/titles/9780596155957/)
+* Programming in Scala (1st edition from Artima) [pins1ed](http://www.artima.com/pins1ed/)
+* Understand pattern matching and scala.Option, but are having some trouble with `map`, `orElse`, `getOrElse` and others? Check out [this cheat sheet](http://blog.tmorris.net/posts/scalaoption-cheat-sheet/).
+
+If you're the kind to read dead tree versions, you can buy from O'Reilly or Artima.

GitGuide.md

@@ -0,0 +1,140 @@
+Git Guide
+=========
+
+What is this guide about?
+-------------------------
+
+The purpose of this guide is to help you understand how to use Git and GitHub
+effectively when working on Moe, using the conventions we find most
+comfortable.
+
+We'll cover branches, pulls, pushes, rebasing, and so on, one step at
+a time.
+
+
+Development workflow
+--------------------
+
+Once you have a local clone of the repository you can start contributing.
+A typical workflow (described in more detail below) is:
+
+  * create a branch to work in
+  * while working, keep your local repo in sync with the main repo
+  * optionally merge your branch into your local master
+  * submit your changes
+
+
+### cloning your repository
+
+If you have a commit bit on the main repository, you can simply clone that:
+
+    git clone git@github.com:MoeOrganization/moe.git
+
+and your "origin" will be the main Moe repo.
+
+If you do not have a commit bit, fork the project using
+the `Fork` button on the Moe project page. Then clone your
+fork:
+
+```bash
+git clone git@github.com:YOUR_USERNAME/moe.git
+
+# and now to add the original path as the upstream
+git remote add upstream https://github.com/MoeOrganization/moe.git
+```
+
+You should now have a directory called "moe" containing the entire project,
+including all the commit history. (Read up on other Git commands
+such as `git log` if you want to review the history.)
+
+
+### branching
+
+In order to keep your contribution isolated from other code or
+documentation changes, it's usually best to create a branch for
+it. This makes it easier to review, approve, merge or even revise it,
+if necessary.
+
+    git checkout -b my-changes master
+
+This creates and switches you to a new branch called "my-changes"
+which is based on the "master" branch (the main project branch and
+where all works gets merged eventually).
+
+
+### committing changes
+
+Once you've created any files you wish to create and have edited whatever
+content needs editing, you're ready to add and commit to your branch:
+
+```bash
+vi Guide.md       # A new file; We'll need to add it in a moment.
+git add Guide.md  # Add to what will be our next commit.
+git commit -m "created a new guide"
+
+cd src/main/scala/org/moe/
+vi Moe.scala  # Edit a tracked file.
+git add -p    # Interactively add changes.
+git commit -m "cleaned up some Scala styling"
+```
+
+Note that `git add` and `git commit` are commands that have layers of
+complexity and features that will not be covered here and can be used in various
+different ways that provide a more fluent work-flow coupled with advanced
+features. Should you find the time, read more on these commands, especially
+`git add -p`, which provides finer-grained control over content adding and
+allows to review your work more easily before committing.
+
+
+### rebasing in preparation for submission
+
+So you finished all your work and it's sitting happily in your local commit
+history. Are you sure it's ready for merge?
+
+While you were working it's possible (and sometimes likely) that others have
+done work as well. Perhaps some of that work was just merged to the main
+branch ("master") of the project. This means that the project has had changes
+introduced since you created your branch and - depending on how you look it -
+either you're out of step with it, or it is out of step with you.
+
+While this doesn't seem scary, it becomes quite the little annoyance if
+you're depending on something that has changed: tests might break, code
+might stop working, and merging itself might cause a conflict because two
+people might have changed the same content.
+
+What do we do? Rebase!
+
+The act of rebasing is to get your code up to speed with changes that already
+occured in the project after you created your branch. Rebasing places your
+changes fresh on top of the existing ones.
+
+    # first, we go to the main branch
+    git checkout master
+
+    # if you have a commit bit, you simply pull the last changes
+    git pull origin master
+
+    # if you work on your own GitHub fork, we pull from upstream
+    git pull upstream master
+
+    # now we can go back to our branch and rebase from master
+    git checkout my-changes
+    git rebase master
+
+Now your code is sitting on top of all the changes that had happened since
+you started working on it. Good job!
+
+### submitting your contribution
+
+It's always good manners to submit your contribution for approval instead of
+pushing it directly, unless you've gained enough knowledge and experience that
+it becomes unlikely you'll make changes that need reverting.
+
+Since we have everything in a branch, we can simply push that branch remotely.
+
+    git push origin my-changes
+
+Now we need to alert the other developers that there's a new branch for review.
+This is best done using the "Pull Request" button available on the Github
+project page. Click it and follow the instructions.
+

LICENSE

@@ -0,0 +1,19 @@
+Copyright (c) 2013 Infinity Interactive, Inc.
+
+Permission is hereby granted, free of charge, to any person obtaining a 
+copy of this software and associated documentation files (the "Software"), 
+to deal in the Software without restriction, including without limitation 
+the rights to use, copy, modify, merge, publish, distribute, sublicense, 
+and/or sell copies of the Software, and to permit persons to whom the 
+Software is furnished to do so, subject to the following conditions:
+
+The above copyright notice and this permission notice shall be included 
+in all copies or substantial portions of the Software.
+
+THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS 
+OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, 
+FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL 
+THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER 
+LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING 
+FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER 
+DEALINGS IN THE SOFTWARE.