clear plan for the road ahead

_posts/2016-07-26-the-road-ahead.md

@@ -0,0 +1,113 @@
+---
+layout: news
+author: Torsten
+---
+
+The sad fact is that i will not have time to finish this. I am now running a development bootcamp
+called [WebDev Camp](http://webdev.camp). The good news is that this produces money, so i am now
+looking for paid help. The budget is thin to start with, but in fact i am quite happy to change the
+model, and hope to find people where even a little makes a difference.
+
+So, the plan, in short:
+
+1. I need to work a little more on docs. Reading them i notice they are still not up to date
+2. I need to find one or two people to do the rest of the points
+3. The Type system needs work
+4. The Method-Function relationship needs to be created
+5. Ruby compiler needs to be written
+6. Parfait moves back completely into ruby land
+7. Soml parser should be scrapped (or will become redundant by 3-5)
+8. The memory model needs reworking (global not object based memory)
+
+### 3. Type system
+
+A Type is an ordered list of associations from name to BasicType (Object/Integer). The class exists
+off course and has been implemented as an array with the names and BasicTypes laid out in sequence.
+This is basically fine, but support for navigation is missing.
+
+The whole type system is basically graph. A type *A* is connected to a type *B* if it has exactly
+one different BasicType. So *A* needs to have **exactly** the same names, and **exactly** one
+different BasicType. Another way of saying this is that the two types are related if in the class
+that Type represents, exactly one variable changes type. This is off course exactly what happens
+when an assignment assigns a different type.
+
+*A* and *B* are also related when *A* has exactly one more name entry than *B* , but os otherwise
+identical. This is what happens when a new variable is added too a class, or one is removed.
+
+The implementation needs to establish this graph (possibly lazily), so that the traversal is fast.
+The most likely implementation seems a hash, so a hashing function has to be designed and the equals
+implemented.
+
+### 4. Method-Function relationship
+
+Just to get the naming clear: A method is at the ruby level, untyped. A Class has references to
+Methods.
+
+Whereas a Function is at the level below, fully typed.
+Function's arguments and local variables have a BasicType.
+Type has references to Functions.
+
+A Function's type is fully described by the combination of the arguments Type and the Frame Type.
+The Frame object is basically a wrapper for all local variables.
+
+A (ruby) Method has N Function "implementations". One function for each different combination of
+BasicTypes for arguments and local variables. Functions know which Method they belong to, because
+their parent Type class holds a reference to the Class that the Type describes.
+
+### 5. Ruby Compiler
+
+Currently there is only the Function level and the soml compiler. The ruby level / compiler is
+missing.
+
+The Compiler generates Class objects, and Type objects as far as it can determine name and
+BasicTypes of the instance variables.
+
+Then it creates Method objects for every Method parsed. Finally it must create all functions that
+needed. In a first brute-force approach this may mean creating functions for all possible
+type combinations.
+
+Call-sites must then be "linked". Linking here refers to the fact that the compiler can not
+determine how to call a function before it is created. So the functions get created in a first pass
+and calls and returns "linked" in a second. The return addresses used at the "soml" level are
+dependent on the BasicType that is being returned. This involves associating the code labels (at
+the function level) with the ast nodes they come from (at the method level). With this, the compiler
+ensures that the type of the variable receiving the return value is correct.
+
+### 6. Parfait in ruby
+
+After SOML was originally written, parts of the run-time (parfait) was ported to soml. This was done with the
+idea that the run-time is low level and thus needs to be fully typed. As it turns out this is only
+partly correct, in the sense that there needs to exist Function definitions (in the sense above)
+that implement basic functionality. But as the sub-chapter on the ruby compiler should explain,
+this does not mean the code has to written in a typed language.
+
+After the ruby-compiler is implemented, the run-time can be implemented in ruby. While this may seem
+strange at first, one must remember that the ruby-compiler creates N Functions of each method for
+all possible type combinations. This means if the ruby method is correctly implemented, error
+handling, for type errors, will be correctly generated by the compiler.
+
+### 7. SOML goodbye
+
+By this time the soml language can be removed. Meaning the parser for the language and all
+documentation is not needed. The ruby-complier compilers straight into the soml internal
+representation (as the soml parser) and because parfait is back in ruby land, soml should be
+removed. Which is a relief, because there are definitely enough languages in the world.
+
+A twist on this would be to rename SOML to SOML, so it would become the Salama Object Machine Layer :-)
+
+### 8. Memory model rework
+
+Slightly unrelated to the above (read: can be done at the same time), the memory model needs to be
+expanded. The current per object *fake* memory works fine, but leaves memory management in
+the compiler.
+
+Since ultimately memory management should be part of the run-time, the model needs to be changed
+to a global one. This means class Page and Space should be implemented, and the *fake* memory
+mapped to a global array.
+
+## In Conclusion
+
+- [WebDev Camp](http://webdev.camp) will sponsor some or all of the work above
+- Candidates should understand the work and be interested.
+- Candidates need to know ruby and speak english
+- apply to torsten@webdev.camp , time and compensation model negotiable