Fix renames sol and slot_machine

app/views/pages/misc/soml.html.haml

@@ -17,7 +17,7 @@ typed an untyped was unclear or i didn't get it to work. The current system
 works by typing self, but not it's instances. A difficult mix to express in a
 language.
 %br
-This led me to abandon soml and rewrite the functionality as vool and mom layers.
+This led me to abandon soml and rewrite the functionality as sol and SlotMachine layers.
 But Soml was working, the parser is still about and there are some interesting
 =link_to "benchmarks" , "soml_benchmarks.html"
 that came from it and really validated the calling convention.

app/views/pages/rubyx/builder.html.haml

@@ -11,17 +11,17 @@
   challenging. The simple object model helps, and so does the simple risc instruction set,
   but for a long time i was struggling to create readable code that generates the risc.
 %p
-  The main places we find this code is the mom layer, eg in the
+  The main places we find this code is the SlotMachine layer, eg in the
   =link_to "calling convention" , "calling.html"
   and in the Builtin module, generating code that can not be expressed in ruby.
 
 %h2 Compiler
 %p
-  When the code goes from ruby to vool, or vool to mom, methods on the previous (tree)
+  When the code goes from ruby to Sol, or Sol to SlotMachine, methods on the previous (tree)
   structure return the next structure. But going to risc the code evolved to use a different
   approach. The unit of compilation is a block or method, and the respective
   %b Compiler
-  is passed into the generating method.
+  is passed into the generating ruby method.
 %p
   The risc code is then added directly to the compiler. If anything is returned it is
   used by the caller for other things. This change happened as the compiler needed to

app/views/pages/rubyx/debugger.html.haml

@@ -12,7 +12,7 @@
   jumping and testing.
 %p
   But since it is so simple, it it a little challenging to understand what is happening
-  in terms of ruby language constructs, or even the Mom abstraction.
+  in terms of ruby language constructs, or even the SlotMachine abstraction.
 
 %p
   Many test use the Interpreter to test conversion output also dynamically. But to test

app/views/pages/rubyx/layers.html.haml

@@ -33,22 +33,19 @@
   that basically models the ast in a concrete syntax tree. This means there is one class
   per node type.
 %p
-  The Ruby layer is then used to transform the data into the Vool layer. Eg: Implicit
+  The Ruby layer is then used to transform the data into the Sol layer. Eg: Implicit
   block passing is made explicit, conditions are simplified, arguments are simplified,
   and syntactic sugar is removed.
 
-%h3#virtual-object-oriented-language Virtual Object Oriented Language
+%h3#simple-object-language Simple Object Language
 %p
-  Virtual, in this context, means that there is no syntax for this language; it is an
+  Simpe, in this context, means that it is much simpler than ruby.
-  intermediate representation which
-  %em could
-  be targeted by several real languages.
 %p
   The main purpose is to simplify existing oo languages down to it’s core components: mostly
   calling, assignment, continuations and exceptions. Typed classes for each language
-  construct exist and are responsible to transform a statement into Mom level below.
+  construct exist and are responsible to transform a statement into SlotMachine level below.
 %p
-  Examples for things that exist in ruby but are broken down in Vool are
+  Examples for things that exist in ruby but are broken down in Sol are
   %em unless
   ,
   %em ternary operator
@@ -58,27 +55,28 @@
   %em for
   loops and other similar syntactic sugar.
 
-%h3#minimal-object-machine Minimal Object machine
+%h3#slot-machine SlotMachine
 %p
-  We compile Vool statements into Mom instructions. Mom is a machine, which means it has
+  We compile Sol statements into SlotMachine instructions. SlotMachine is a machine,
-  instructions. But unlike a cpu (or the risc layer below) it does not have memory, only
+  which means it has instructions. But unlike a cpu (or the risc layer below) it does not
-  objects.
+  have memory, only objects.
   It also has no registers, and together these two things mean that all information is
   stored in objects. Also the calling convention is object based and uses Frame and
   Message instances to save state.
 %p
   Objects are typed, and are in fact the same objects the language operates on. Just the
   functionality is expressed through instructions. While source methods are defined on
-  classes as Vool, when they are compiled to binary, they are made type specific. These
+  classes as Sol, when they are compiled to binary, they are made type specific. These
-  TypedMethods hold the binary and are stored in the Type.
+  CallableMethods hold the binary and are stored in the Type.
 %p
-  The Mom level exists to make the transition to Risc easier. It has a very abstract,
+  The SlotMachine level exists to make the transition to Risc easier. It has a very abstract,
   high level instruction set, where each single instruction may resolve to many (even
-  tens of) lower level instructions. But it breaks down Vool's tree into an instruction
+  tens of) lower level instructions. But it breaks down Sol's tree into an instruction
   list, which is conceptually a much easier input for the next layer.
 %p
-  Mom instruction may also be used to extend the systm functionality. This feature is used
+  SlotMachine uses a class hierachy to represent instructions, and this fact may be used to
-  in the Builtin layer of functions. These functions are coded at the Mom level, as they
+  extend the systm functionality. This feature is used in the Builtin layer of functions.
+  These functions are coded at the SlotMachine level, as they
   can not be expressed in ruby. Examples include instance variable access, integer ops...
 
 %h3#risc Risc
@@ -86,9 +84,9 @@
   The Register machine layer is a relatively close abstraction of risc hardware,
   but without the quirks that for example arm has.
   The Risc machine has registers, indexed addressing, operators, branches and everything
-  needed to implement Mom. It does not try to abstract every possible machine feature
+  needed to implement SlotMachine. It does not try to abstract every possible machine feature
   (like llvm), but rather “objectifies” the general risc view to provide what is needed for
-  the Mom layer, the next layer up (and actually Builtin functions).
+  the Slot layer, the next layer up (and actually Builtin functions).
 %p
   The machine has it’s own (abstract) instruction set, and the mapping to arm is quite
   straightforward. Since the instruction set is implemented as derived classes, additional

app/views/pages/rubyx/memory.html.haml

@@ -92,7 +92,7 @@
   is an Integer. Then it loads the data from both objects, performs the operation,
   "allocates" a new Integer object and saves the machine word into it.
 %p
-  We can also define Mom Instruction to manipulate data, but as work is done in
+  We can also define SlotMachine Instruction to manipulate data, but as work is done in
   methods, the Builtin approach has been sufficient up to now.
 %p
   Again one may think this is wasteful, the simplest of Integer operation thus taking

app/views/pages/rubyx/method_resolution.html.haml

@@ -43,24 +43,24 @@
   cache of one, captured by the class
   =ext_link "CacheEntry" , "https://github.com/ruby-x/rubyx/blob/master/lib/parfait/cache_entry.rb"
 
-%h3 Vool
+%h3 Sol
 %p
-  Static resolution is done at the Vool level, where the CacheEntry is also created
+  Static resolution is done at the Sol level, where the CacheEntry is also created
   and then used as any other constant. Ie there is exactly one CacheEntry for every
   call site (SendStatement).
 %p
-  Vool breaks the resolution into it's logical component steps, ie:
+  Sol breaks the resolution into it's logical component steps, ie:
   %ul
     %li Check the current type against cached type
     %li Update cached type if needed
     %li Update cached method if needed
     %li Call the cached method
 
-  Breaking down means that Mom Instructions are emitted to effect the logic above.
+  Breaking down means that SlotMachine Instructions are emitted to effect the logic above.
   Most of the logic (like the if that is needed) already exists. But the last two
   steps require special instructions described below.
 
-%h3 Mom
+%h3 SlotMachine
 %p
   The method cache update described above is basically an assignment where
   we assign the resolved method to the cache. But to do that, we need to finally
@@ -68,7 +68,7 @@
 %p
   The implementation of the
   %em ResolveMethod
-  is quite a bit longer than most other Mom instructions, but basically does:
+  is quite a bit longer than most other SlotMachine instructions, but basically does:
   %ul
     %li Load methods from current (cached) type
     %li Enter a while loop until we hit nil (goto NOT_FOUND if nil)
@@ -78,7 +78,7 @@
     %li OK: save method in cache
   To achieve readable code for this low level assembler programming a DSL is
   used. The
-  =ext_link "result", "https://github.com/ruby-x/rubyx/blob/master/lib/mom/instruction/resolve_method.rb#L32"
+  =ext_link "result", "https://github.com/ruby-x/rubyx/blob/master/lib/slot_machine/instruction/resolve_method.rb#L32"
   is quite understandable.
 
 %p

app/views/pages/rubyx/parfait.html.haml

@@ -26,11 +26,11 @@ oriented system.
 
 %p
   It may be easiest to understand types by how they are used. When rubyx parses a class,
-  it creates a Vool::Class, which in turn creates a Parfait::Class. This class carries
+  it creates a Sol::ClassExpression, which in turn creates a Parfait::Class. This class carries
-  the Vool methods, basically the language code for the methods.
+  the Sol methods, basically the language code for the methods.
   %br
   At this point a type, representing the object layout as known at the time, is created.
-  Vool::Methods are compiled to binary (Parfait::Method) according to the type information
+  Parfait::SolMethod are compiled to binary (Parfait::Callable) according to the type information
   and stored in the type.
   %br
   If the class changes at run-time, ie variables are added or removed, a new type object is