Lever upgrade: Weakened multimethods
I made an upgrade into Lever's multimethods that allow the system to clean up all methods whenever an interface becomes unreachable. This upgrade makes live programming with multimethods a bit cleaner.
Above you have a high-level illustration of the new implementation. Notice how the weak references isolate the multimethod from the interface and the function that implements the method.
The actual multimethod implementation is a bit more complex than what the above diagram proposes, those details not present in the diagram have stood the same.
In nutshell, when the multimethod is called, it observes the interfaces of its arguments and calls a method that is associated with those interfaces in it's dispatch table.
The multimethod has a weak reference to the multimethod record because the function often has reference chains to the interface.
The weak boundary ensures that the interface is correctly corrected.
The Interface
You can consider the interface to be same as the class.
The naming originates from the fact that Lever is not
strictly Object oriented and I'm not a fan of the OOP. Early
on I was not sure that my interfaces would resemble object
oriented classes.
The traditional class-like structuring was convenient for extending the language, so it stuck.
When Interface gets lost
Each interface in the runtime has a finalizer and an interface descriptor associated to it.
The interface descriptor is used to identify the interface in a vector of the multimethod. It ensures that when the weak reference is severed it does not change how the multimethod identifies the interface.
The finalizer informs the multimethod to remove the interface vector and method records associated to them, as well as informs the other interfaces that the multimethod record should be erased from their records.
This ensures that everything related to the interface is lost when the interface finally becomes inaccessible from the runtime.
The benefits
One of the things Lever supports is the live programming. The model of live programming it uses is oriented around modules, module-level scopes and persistent state. This means that when the module files change, the module itself is reloaded.
When the module is reloaded, every interface in the module is lost. This is not very convenient because the resulting program may easily end up having objects with outdated interfaces in them.
Lever has this kind of flaws, mainly because every other implementation that I've seen, that doesn't have more severe flaws has those flaws too. I haven't figured out how to solve all of these problems and I don't know if I will figure it out.
Status update for this week
The issues limiting the release of the next Lever release are still there:
- Graphics card on my Windows machine is too old to
support the
VK_KHX_external_memory_capabilities. - Oculus still requires that extension, and they haven't stepped ahead yet.
- Nvidia still has not released the stable driver
implementing the
VK_KHR_external_memory_capabilities. - I am unable to see whether my VR support for the Lever IDE is functioning.
- The Lever IDE is incomplete.
For the next week I have a backlog of several interesting projects where my help is needed. That gives some time for these obstacles to resolve themselves.