add ast gem

Gemfile

@@ -4,6 +4,7 @@ gem "rake"
 
 gem "salama-reader" , :path => "."
 
+gem "ast" , :path => "../ast"
 
 # Add dependencies to develop your gem here.
 # Include everything needed to run rake, tests, features, etc.

Gemfile.lock

@@ -2,8 +2,14 @@ PATH
   remote: .
   specs:
     salama-reader (0.2.0)
+      ast (~> 2.1.0)
       parslet (~> 1.7.0)
 
+PATH
+  remote: ../ast
+  specs:
+    ast (2.1.0)
+
 GEM
   remote: http://rubygems.org/
   specs:
@@ -13,7 +19,7 @@ GEM
     docile (1.1.5)
     minitest (5.6.1)
     multi_json (1.11.2)
-    parslet (1.7.0)
+    parslet (1.7.1)
       blankslate (>= 2.0, <= 4.0)
     rake (10.4.2)
     rubygems-tasks (0.2.4)
@@ -27,8 +33,12 @@ PLATFORMS
   ruby
 
 DEPENDENCIES
+  ast!
   codeclimate-test-reporter
   minitest
   rake
   rubygems-tasks
   salama-reader!
+
+BUNDLED WITH
+   1.10.5

README.md

@@ -3,18 +3,47 @@
 [![Code Climate](https://codeclimate.com/github/salama/salama-reader/badges/gpa.svg)](https://codeclimate.com/github/salama/salama-reader)
 [![Test Coverage](https://codeclimate.com/github/salama/salama-reader/badges/coverage.svg)](https://codeclimate.com/github/salama/salama-reader)
 
-## Currently in limbo
-
-Possibly writing a salama machine language and using whitequark's parser
-
 ## Salama Reader
 
-The parser part of salama is now a standalone gem. It parses ruby using Parslet and no other dependencies.
-
-This is interesting if you want to generate executable code, like salama, but also for other things, like code analysis.
+The parser part of salama is now a standalone gem. It parses bosl using Parslet and no other dependencies.
 
 Also it is very educational, as it is very readable code, and not too much of it.
 
+## Bosl Basic Object System Language
+
+Bosl is just forming after a major insight. I used to nag about C quite randomly before, but now i
+found the two main things that make it (as a system language)unsuitable for implementing an Object
+system:
+
+- C has inherrent non object features. But one could just use structs to get around that.
+  One would have to (unlike c++ eg) forbid the usage of large parts of the language
+- The calling convention is not object based, ie not upward compatible in an oo system.
+
+Contrary to what i thought before, other features of c are actually needed. Programming
+an oo vm without a system language is like programming an os in assembler. All right for some, but
+not most.
+
+Specifically a static language is not an obstacle, or even a good thing. One pretends the world
+is closed until run-time. Then one needs to have the same compiling capabilities.
+
+Types, or a static type system, is also quite necessary to stay sane. It is "just" a matter of
+extending that for oo later. Luckily i have found a system to do that.
+
+### Syntax
+
+Syntax (and semantics) of bosl are just forming, but some things are clear:
+
+- statically typed (in the beginning with just two types) meaning all variable declarations,
+  functions and arguments shall be typed.
+- objects but without data hiding
+- probably nil objects
+- static blocks (a bit ala crystal)
+- call syntax as already discussed, ie message based
+
+Some things we shall leave behind from the ruby approach are a lot of sugar, like missing brackets,
+random code everywhere, expressions galore . . .
+
+
 ### Parser
 
 The main parser per se is in parser/salama , but it just pulls in all the parts.
@@ -37,12 +66,12 @@ Most names are quite self explanatory, but here is a list:
 
 ### Ast
 
-The Abtract Syntax Tree (ast) layer puts the parsed code into objects, so they are nice and easy to work with.
+The ast layer now uses the ast gem. That approach is to use a single class to represent all
+types of node and use a type symbol (instead of different classes)
 
-The Classes don't really define any functionality, that is done in Salama, or can be done in any code using this. Salama just adds a compile function to each class, but a visitor pattern would do just as well.
-
-The functionality that is in there is mainly to do with testing. Equality is defined, but also **inspect** in such a way that it's output (which you get from a failing test) can be pasted straight into the test case as the expected result.
+This works well, and is much less work.
 
+The following step of compiling use the same kind of visitor approach as before
 
 ### Parslet
 
@@ -56,20 +85,10 @@ Especially the last point is great. Since it is separate it does not clutter up
 And it can generate a layer that has no links to the actual parser anymore, thus saving/automating
 a complete transformation process.
 
-### Todo
-
-A random list of things left for the future
-
-- extract commonality of function call/definition,array, hash and multi assignment comma lists
-- break and next
-- blocks
-- more loops, i'm not even sure what ruby supports
-- ifs without else, also elsif
-- negative tests
-
 ### Operators
 
-Parslets operator support is **outstanding** and such it was a breeze to implement most of rubies operators very simply. See the operators.rb for details. Below is a list from the web of how it should be.
+Parslets operator support is **outstanding** and such it was a breeze to implement most operators
+very simply. See the operators.rb for details. Below is a list from the web of how it should be.
 
 
 Operator list from http://stackoverflow.com/questions/21060234/ruby-operator-precedence-table

salama-reader.gemspec

@@ -14,5 +14,6 @@ Gem::Specification.new do |s|
   s.summary = 'Ruby parser for the salama machine'
 
   s.add_dependency 'parslet', '~> 1.7.0'
+  s.add_dependency 'ast', '~> 2.1.0'
 
 end