2014-08-15 13:59:38 +02:00
|
|
|
### Reading the code
|
|
|
|
|
2014-08-18 12:01:52 +02:00
|
|
|
Knowing what's going on while coding salama is not so easy: Hence the need to look at code dumps
|
2014-08-15 13:59:38 +02:00
|
|
|
|
2015-03-25 16:29:39 +01:00
|
|
|
Hence the need for a code/object file format
|
|
|
|
(remember an oo program is just objects, some data, some code, all objects)
|
2014-08-15 13:59:38 +02:00
|
|
|
|
2015-03-25 16:29:39 +01:00
|
|
|
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.
|
2014-08-15 13:59:38 +02:00
|
|
|
|
2014-08-28 18:12:46 +02:00
|
|
|
But the "sort of" started to get to me, because
|
|
|
|
|
|
|
|
- 1) it's way to verbose (long files, object groups over many pages) and
|
|
|
|
- 2) does not allow for (easy) ordering.
|
2014-08-15 13:59:38 +02:00
|
|
|
|
|
|
|
To fix this i started on Sof, with an eye to expand it.
|
|
|
|
|
|
|
|
The main starting goal was quite like yaml, but with
|
|
|
|
|
2014-08-18 12:01:52 +02:00
|
|
|
- more text per line, specifically objects with simple attributes to have a constructor like syntax
|
|
|
|
- also short versions of arrays and hashes
|
2014-08-15 13:59:38 +02:00
|
|
|
- Shorter class names (no ruby/object or even ruby/struct stuff)
|
|
|
|
- references at the most shallow level
|
2014-08-28 18:12:46 +02:00
|
|
|
- an easy way to order attributes and specify attributes that should not be serialized
|
2014-08-15 13:59:38 +02:00
|
|
|
|
2014-08-13 19:05:00 +02:00
|
|
|
### Salama Object File
|
|
|
|
|
2014-08-18 12:01:52 +02:00
|
|
|
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.
|
2014-08-13 19:05:00 +02:00
|
|
|
|
2015-03-25 16:29:39 +01:00
|
|
|
Much fewer know what they include, and that is not because they are not very useful,
|
|
|
|
but rather very complicated.
|
2014-08-13 19:05:00 +02:00
|
|
|
|
|
|
|
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
|
|
|
|
|
2014-08-18 12:01:52 +02:00
|
|
|
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.
|
2014-08-13 19:05:00 +02:00
|
|
|
|
|
|
|
I just want to be able to read my compiled code!!
|
|
|
|
|
|
|
|
And so this is a little start, just some outputter.
|
|
|
|
|
|
|
|
#### Direction
|
|
|
|
|
2015-03-25 16:29:39 +01:00
|
|
|
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).
|
2014-08-13 19:05:00 +02:00
|
|
|
|
|
|
|
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.
|
|
|
|
|
2015-03-25 16:29:39 +01:00
|
|
|
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 . ..
|