remove references to soml

README.md

@@ -7,21 +7,21 @@
 
 Salama is about native code generation in and of ruby.
 
-It is probably best to read the [The Book](http://dancinglightning.gitbooks.io/the-object-machine/content/) first.
+The current (fourth) rewrite adds a typed intermediate representation layer (bit like c,
+but not as a language). The idea is to compile ruby to that typed representation.
 
-The current third rewrite adds a system language, with the idea of compiling ruby to that language, Soml.
-The original ruby parser has been remodeled to parse Soml and later we will use whitequarks
-parser to parse ruby.  Then it will be ruby --> Soml --> assembler --> binary .
+We will use whitequarks parser to parse ruby.  Then it will be ruby --> Typed --> Register --> Arm --> binary .
 
 
 ## Done
 
 Some things that are finished, look below for current status / work
 
-### Soml
+### Typed representation
 
-A working of the [system language](http://salama-vm.org/soml/soml.html) is done. It is
-strongly typed, but leans more towards ruby style syntax.
+The fully typed syntax representation and compiler to the Register level is done.
+It is remodeled after  last years system language, which proved the concept and
+surprised with speed.
 
 Completely object oriented, including calling convention. Not much slower than c.
 
@@ -43,10 +43,9 @@ what is going on, and in finding bugs.
 
 ## Status
 
-Having finished Soml, it's time to compile ruby to it.
-
-This will mean more work on the type front.
+Most work on the statically typed layer should be done (and produces working binaries!).
 
+Next up: compiling ruby and typing it :-)
 
 ### Stary sky
 

lib/register/README.md

@@ -5,7 +5,7 @@ The RegisterMachine, is an abstract machine with registers. Think of it as an ar
 normal instruction names. It is not however an abstraction of existing hardware, but only
 of that subset that we need.
 
-Our primary objective is to compile Soml to this level, so the register machine has:
+Our primary objective is to compile typed code to this level, so the register machine has:
 - object access instructions
 - object load
 - object oriented call semantics

lib/register/builtin/README.md

@@ -16,9 +16,3 @@ C uses Assembler in this situation, we use Builtin functions.
 Slightly more here : http://salama.github.io/2014/06/10/more-clarity.html (then still called Kernel)
 
 The Builtin module is scattered into several files, but that is just so the file doesn't get too long.
-
-Note: This is about to change slightly with the arrival of Soml.  Soml is a lower level function,
-and as such there is not much that we need that can not be expressed in it. My current thinking
-is that i can code anything in Soml and will only need the Soml instruction set.
-So this whole Builtin approach may blow over in the next months. It had already become clear that
-mostly this was going to be about memory access, which in Soml is part of the language.

lib/typed/compiler/README.md

@@ -1,9 +1,9 @@
 ### Compiling
 
-The Ast (abstract syntax tree) is created by [salama-reader](https://github.com/salama/salama-reader)
- gem and the classes defined there
+The typed syntax tree is created by the ruby compiler.
 
-The code in this directory compiles the AST to the virtual machine code, and Parfait object structure.
+The code in this directory compiles the typed tree to the register machine code, and
+Parfait object structure.
 
 If this were an interpreter, we would just walk the tree and do what it says.
 Since it's not things are a little more difficult, especially in time.
@@ -19,13 +19,11 @@ Similarly, the result of compiling is two-fold: a static and a dynamic part.
 Too make things a little simpler, we create a very high level instruction stream at first and then
 run transformation and optimization passes on the stream to improve it.
 
-The compiler has a method for each type for ast, named along on_xxx with xxx as the type
+The compiler has a method for each class of typed tree, named along on_xxx with xxx as the type
 
 #### Compiler holds scope
 
-The Compiler instance can hold arbitrary scope needed during the compilation. Since we compile Soml
-(a static language) things have become more simple.
-
+The Compiler instance can hold arbitrary scope needed during the compilation.
 A class statement sets the current @clazz scope , a method definition the @method.
 If either are not set when needed compile errors will follow. So easy, so nice.
 
@@ -42,7 +40,7 @@ The general structure of the instructions is a graph
 
 #### Messages and frames
 
-Since the machine is virtual, we have to define it, and since it is oo we define it in objects.
+Since the machine is oo we define it in objects.
 
 Also it is important to define how instructions operate, which is is in a physical machine would
 be by changing the contents of registers or some stack.
@@ -57,13 +55,3 @@ When a Method needs to make a call, it creates a NewMessage object.
 Messages contain return addresses (yes, plural) and arguments.
 
 The important thing here is that Messages and Frames are normal objects.
-
-### Distinctly future proof
-
-Soml is designed to be used as an implementation language for a higher oo language. Some, or
-even many, features may not make sense on their own. But these features, like several return
-addresses, are important to implement the higher language.
-
-In fact, Soml's main purpose is not even to be written. The main purpose is to have a language to
-compile ruby to. In the same way that the assembler layer in salama is not designed to be written,
-we just need it to create our layers.

lib/typed/parfait/README.md

@@ -1,15 +1,7 @@
-## Notice of change
-
-The stuff below, like the whole of Parfait, was written before soml. Ie before there was a seperate
-language to compile a higher language to. Soml is not so dynamic, could do without much of the
-ObjectSpace that is the core of Parfait.
-
-So things will change. How will become clear when soml is finished.
-
 ### Parfait: a thin layer
 
-Parfait is the run-time of the **vm**.
-To be more precise, it is that part of the run-time needed to boot soml.
+Parfait is the run-time of the object system.
+To be more precise, it is that part of the run-time needed to boot.
 
 The run-time needs to contain quite a lot of functionality for a dynamic system.
 And a large part of that functionality must actually be used at compile time too.
@@ -17,9 +9,6 @@ And a large part of that functionality must actually be used at compile time too
 We reuse the Parfait code at compile-time, to create the data for the compiled vm.
 To do this the vm (re) defines the object memory (in parfait_adapter).
 
-To do the actual compiling we parse and compile the parfait code and inline it to
-appropriate places.
-
 A work in progress that started from here : http://salama.github.io/2014/06/10/more-clarity.html
 went on here http://salama.github.io/2014/07/05/layers-vs-passes.html
 

salama.gemspec

@@ -13,7 +13,6 @@ Gem::Specification.new do |s|
   s.require_paths = ['lib']
   s.summary = 'Salama is a native object vm without any c, one day possibly a ruby vm'
 
-  s.add_dependency "soml-parser" , "~> 0.5"
   s.add_dependency "parser" , "~> 2.2.0"
   s.add_dependency "salama-object-file" , "~> 0.3"
 end

stash/soml/helper.rb

@@ -4,7 +4,7 @@ require "rye"
 Rye::Cmd.add_command :ld, '/usr/bin/ld'
 Rye::Cmd.add_command :aout, './a.out'
 
-# machinery to run a soml program in 2 ways
+# machinery to run a typed program in 2 ways
 # - first by running it through the interpreter
 # - second by assembling to arm , pushing the binary to a remote machine and executing it there
 #
@@ -13,7 +13,7 @@ Rye::Cmd.add_command :aout, './a.out'
 #   the minimum is REMOTE_PI=username , and off course ssh keys have to be set up
 
 # btw can't test with ruby on a PI as code creation only works on 64bit
-#   that's because ruby nibbles 2 bits from a word, and soml code doesn't work around that
+#   that's because ruby nibbles 2 bits from a word, and typed code doesn't work around that
 module RuntimeTests
 
   def setup

stash/test_runner.rb

@@ -22,7 +22,6 @@ class TestRunner < MiniTest::Test
     parser = Parser::Salama.new
     object_space = Register::Program.new "Arm"
     #TODO : files would have to include s-expressions now
-    # those can be obtained with to_code utility in soml-parser
     syntax  = parser.parse_with_debug(string, reporter: Parslet::ErrorReporter::Deepest.new)
     assert syntax
     parts   = Parser::Transform.new.apply(syntax)

test/bench/c/hello.c

@@ -2,7 +2,7 @@
 
 int main(void)
 {
-	setbuf(stdout, NULL); /* to make it equivalent to the soml, otherwise it caches */
+	setbuf(stdout, NULL); /* to make it equivalent to the typed version, otherwise it caches */
 	int counter = 100352 - 352;
 	while(counter--) {
     printf("Hello there\n");

test/bench/results.md

@@ -10,7 +10,7 @@ Hello and puti and add run 100_000 iterations per program invocation to remove s
 Call only has 10000 iterations, as it much slower
 
 Gcc used to compile c on the machine
-soml produced by ruby (on another machine)
+typed produced by ruby (on another machine)
 
 # Results
 
@@ -24,7 +24,7 @@ But results should be seen as relative, not absolute.
 language  | loop    | hello   | itos    |  add    | call        
 c         | 0,0500  | 2,1365  | 0,2902  | 0,1245  | 0,8535  
 go        | 0.0485  | 4.5355  | 0.2143  | 0.0825  | 0.8769  
-soml      | 0,0374  | 1,2071  | 0,7263  | 0,2247  | 1,3625
+typed     | 0,0374  | 1,2071  | 0,7263  | 0,2247  | 1,3625
 
 ruby      | 0,3     | 8.882    | 0,8971 | 3,8452
 

test/bench/typed/helper.rb

@@ -1,4 +1,4 @@
-require_relative '../../soml/helper'
+require_relative '../../typed/helper'
 
 # Benchmarks for the stuff in results.md
 

test/bench/typed/integer.soml

@@ -10,7 +10,7 @@ class Integer < Value
 
 
 
-  int div10_soml()
+  int div10_typed()
     int tmp = self >> 1
     int q = self >> 2
     q = q + tmp