rubyx/lib/sof
2015-03-25 17:29:39 +02:00
..
all.rb inlining references into objects as simple data 2014-08-18 14:54:03 +03:00
array.rb short version for array 2014-08-18 14:28:28 +03:00
hash.rb short hash, inline like for array. with curly braces off course 2014-08-27 14:46:34 +03:00
members.rb fix the missing reference bug on class 2014-08-21 15:35:55 +03:00
node.rb fix the missing reference bug on class 2014-08-21 15:35:55 +03:00
occurence.rb fix the missing reference bug on class 2014-08-21 15:35:55 +03:00
README.md bit of line wrapping 2015-03-25 17:29:39 +02:00
util.rb make attributes available outside sof (iw as module funtion) 2014-08-19 22:39:58 +03:00
volotile.rb fixing import order 2014-10-03 14:33:06 +03:00
writer.rb fix the missing reference bug on class 2014-08-21 15:35:55 +03:00

Reading the code

Knowing what's going on while coding salama is not so easy: Hence the need to look at code dumps

Hence the need for a code/object file format (remember an oo program is just objects, some data, some code, all objects)

I started with yaml, which is nice in that it has a solid implementation, reads and writes, handles arbitrary objects, handles graphs and is a sort of readable text format.

But the "sort of" started to get to me, because

    1. it's way to verbose (long files, object groups over many pages) and
    1. does not allow for (easy) ordering.

To fix this i started on Sof, with an eye to expand it.

The main starting goal was quite like yaml, but with

  • more text per line, specifically objects with simple attributes to have a constructor like syntax
  • also short versions of arrays and hashes
  • Shorter class names (no ruby/object or even ruby/struct stuff)
  • references at the most shallow level
  • an easy way to order attributes and specify attributes that should not be serialized

Salama Object File

Ok, so we all heard about object files, it's the things compilers create so we don't have to have huge compiles and can link them later.

Much fewer know what they include, and that is not because they are not very useful, but rather very complicated.

An object machine must off course have it's own object files, because:

  • otherwise we'd have to express the object machine in c (nischt gut)
  • we would be forced to read the source every time (slow)
  • we would have no language independant format

And i was going to get there, juust not now. I mean i think it's a great idea to have many languages compile and run on the same object machine. Not neccessarily my idea, but i haven't seen it pulled off. Not that i will.

I just want to be able to read my compiled code!!

And so this is a little start, just some outputter.

Direction

The way this is meant to go (planned for 2020+) was a salama core with only a sof parser (as that is soo much simpler).

Then to_ruby for all the ast classes to be able to roundtrip ruby code.

Then go to storing sof in git, rather than ruby.

Then write a python/java parser and respective runtime conversion. Extracting common features. With the respective to_python on the ast's to roundtrip that too. Have to since by now we work on sof's. Etc . ..