freenode/#sicl - IRC Chatlog
Search
9:07:08
beach
OK, I decided to add another phase to the bootstrapping procedure. It is a new phase 5 that is pretty much identical to phase 4. The purpose is to make the blue objects be the preferred ones for obtaining circularity.
9:07:14
beach
As heisig suggested, I should then be able to mostly keep track of allocations of blue objects and change the class of each one at the end.
9:07:20
beach
There is more to it though. I need to choose candidate generic functions to manage the cyclic graph. Different candidates might exist in different environments.
9:08:32
beach
By the way, the new phase was quite painless to do. It kind of just worked to copy phase 4 and change to a new set of environments. I should take advantage of this situation to factor the code.
9:18:08
beach
I want generic functions to access classes and other function in the same environment.
9:19:56
beach
Additional generic functions such as compute-discriminating-function exist in different environments and they call different sets of accessors.
9:20:29
beach
So I need to choose precisely the set of generic functions that will work for a single environment.
9:21:30
beach
The more phases I have, the more likely it is that generic functions in different environments are interchangeable.
9:22:36
beach
In order to invoke a generic function, its discriminating function might have to be computed. And that process goes to the preceding environment with its accessors.
9:23:16
beach
But there is a limit. I only need to back up by so many environments. I don't know exactly how many, but my guess is that 2 is max.
9:24:31
beach
So the more phases I have, the more likely it is that generic functions in the last few environments behave the same on ersatz objects.
9:25:18
beach
I know, this is not a very precise description, but at the moment, it is just intuition in my head.
9:29:50
heisig
Your bootstrapping technique is starting to look like a fixed point iteration for MOP behavior. I love it.
9:33:53
beach
It all works because an accessor that has had its discriminating function computed goes directly to the rack with the right index.
9:36:55
beach
So green, red, and blue accessor behave the same, provided they have had their discriminating functions computed.
9:39:01
beach
And yellow ones as well, of course, but they definitely have not had their discriminating functions computed.
16:50:22
beach
As a result of the work from this morning, I now have this situation: http://metamodular.com/fig-environments.pdf
17:08:19
beach
Working hypothesis for phase 6 (where I turn the acyclic graph into a cyclic graph): 1. Change the class slot of every blue object so that it points to a blue class instead of a red class. 2. Copy the blue classes over to E5. 3. (this is the tough one) redefine functions in E5 that look for classes en E4 so that they look for classes in E5 instead. 4. Maybe something else that I am unaware of.
17:10:51
beach
What I think I need to do is to start with all operations I need to do in E5 (call a function, define a generic function, define a method, define a class), then trace every function call made as a result of that, figure out where the functions are located that get called in the process, and check what needs to be modified in order for things to continue to work.
17:30:32
beach
What stassats did worked. I just had to figure out what FASLs to remove after I reinstalled the new SBCL.