Just for future, as this gives us a way to know immediately in the type, which represent normal, and which singleton classes
Also instantiate singleton class lazily (with singleton type)
This makes the type of class single, ie unique, immediately when it is used, ie methods or variables defined.
Fixes a design mistake, where all singletonn classes shared the same type, and thus unique methods per class were impossible
(Also some misc in commit)
the typed method has to be created in the to_pafait pass for it to work correctly, ie for the sends to have something to call
also means that when during compilation creating (raising?) a method, not only vool. but also callable has to be created
resolve had the wrong approach, sort of class based oo
It took methods from "derived" types and just used them
To be correct, those methods would have to be recompiled for the current type, rubyx is type, not class based.
Started on that, still soe strange hang though
Later, type and method analysis may reveal "compatible" types (down only off course) where one could use the exact same code, but that is phase 2
seems more appropriate, as it is the class for a single object
Also seems to be called that on the net (don't remember where the meta came from, but it's gone)
after some serious recursive thinking it now actually makes sense.
The key was to change the actual type of the class that the meta_class manages
For objects it's (still) ok just to change the instance_type, but since the class object exists and has type, when adding instance variables, that actual type has to change
as they are just the type of the meta_class, that was relatively simple.
I feel this is what oo is meant to be, instance variables and methods for the objects, and since classes are objects, for them too.
Class variables seem like a design mistake, weird scoping rules and no data hiding (left as an exercise to the reader)
I call it macro because it lets you insert basically arbitrary risc code into the ruby level. The way it works:
Reserve namespace X
map any X.some_call to a Mom instruction
by the name SomeCall
which must take the same args in constructor as given
And obviously produce whatever risc it wants
Hoping to rewrite builtin around this idea (with the existing Mom builtn instructions)
When the lambda is passed as argument, it must be moved. This triggers the generation of a corresponding parfait object (as before, and as for other constants) but now also triggers the code build. The code being the constant as it were
Also some more name fixes from renames
previous commit affected rather many test, as the implicit returns add extra instructions
Also added some explicit returns, so as not to test the return logic too much. return (ie return nl) is a knonwn 3 risc operation.
Same same, just have to remembe to actually execute the condition if it is a send
Having send a possible expression, removes one tmp variable and associated move, for a little extra work.
Next return and assign (rest)
Before, when the type was determined, it was assumed that the method can be resolved. But off course tis is not true, as methods may be defined later in the file.
Two solutions for that. One could (and should) define all methods and only then start to compile. Thus having the type safety.
Or (as now) make a dynamic call and let it fail at runtime.
Since Builtin generates risc, just like mom instructions, it was a design mistake to put builtin into risc in the first place. Now that borders are coming more into focus, it make much more sense to have the builtin in mom.
In fact the instructions should be moved out and a seperate invocation mechanism used , so functions can be parsed, not generated (wip)
