Torsten Rüger
84b9811e55
When send has complex args, mostly more sends, we hoist those out and pass created temporary variables |
||
---|---|---|
.. | ||
array_statement.rb | ||
assignment.rb | ||
basic_values.rb | ||
block_statement.rb | ||
call_statement.rb | ||
class_method_statement.rb | ||
class_statement.rb | ||
hash_statement.rb | ||
if_statement.rb | ||
logical_statement.rb | ||
method_statement.rb | ||
normalizer.rb | ||
README.md | ||
return_statement.rb | ||
ruby_compiler.rb | ||
send_statement.rb | ||
statement.rb | ||
statements.rb | ||
variables.rb | ||
while_statement.rb | ||
yield_statement.rb |
Ruby
A representation of the ruby code.
Concrete Syntax tree
Ruby is parsed by the parser gem (big thanks to whitequark). Own attempts at this task have failed utterly, because ruby is a huge language (and not well defined at that)
Alas, the parser gem creates an abstract syntax tree, meaning one class is used to represent all node types.
Imho object oriented languages have a class system to do just that, ie represent what we may loosely call type here, ie the kind of statement.
The ruby layer is really all about defining classes for every kind of statement, thus "typing" the syntax tree, and making it concrete.
to Vool
In our nice layers, we are ont the way down to Vool, a simplified version of oo.
It has proven handy to have this layer, so the code for transforming each object is in the class representing that object. (As one does in oo, again imho).
Parfait objects
The compilation process ends up creating (parfait) objects to represent things like classes, types and constants. This is not done here yet, but in the vool layer.