have started myself, change text
This commit is contained in:
Torsten Ruger
parent
bff0e70556
commit
769b8432e7
|
|
@ -3,23 +3,17 @@ 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)
|
||||
2. The Type system needs work
|
||||
3. The Method-Function relationship needs to be created
|
||||
4. Ruby compiler needs to be written
|
||||
5. Parfait moves back completely into ruby land
|
||||
6. Soml parser should be scrapped (or will become redundant by 2-4)
|
||||
7. The memory model needs reworking (global not object based memory)
|
||||
|
||||
### 3. Type system
|
||||
### 2. 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.
|
||||
|
|
@ -38,7 +32,7 @@ The implementation needs to establish this graph (possibly lazily), so that the
|
|||
The most likely implementation seems a hash, so a hashing function has to be designed and the equals
|
||||
implemented.
|
||||
|
||||
### 4. Method-Function relationship
|
||||
### 3. Method-Function relationship
|
||||
|
||||
Just to get the naming clear: A method is at the ruby level, untyped. A Class has references to
|
||||
Methods.
|
||||
|
|
@ -54,7 +48,7 @@ A (ruby) Method has N Function "implementations". One function for each differen
|
|||
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
|
||||
### 4. Ruby Compiler
|
||||
|
||||
Currently there is only the Function level and the soml compiler. The ruby level / compiler is
|
||||
missing.
|
||||
|
|
@ -73,7 +67,7 @@ dependent on the BasicType that is being returned. This involves associating the
|
|||
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
|
||||
### 5. 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
|
||||
|
|
@ -86,16 +80,15 @@ strange at first, one must remember that the ruby-compiler creates N Functions o
|
|||
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
|
||||
### 6. 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
|
||||
### 7. 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
|
||||
|
|
@ -104,10 +97,3 @@ 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
|
||||
|
|
|
|||
Loading…
Reference in New Issue