freenode/#sicl - IRC Chatlog
Search
3:32:12
beach
I guess it may not look like I am doing a lot of work these days, and that is because I haven't checked it in, in case it fails. I am working on a new bootstrapping procedure. It has three advantages compared to the existing one.
3:32:16
beach
First, it uses Clostrum, which will allow me to do more compile-time information registration, like the class and method class of a generic function.
3:32:21
beach
Second, it uses the AST evaluator in phases that do not create functions that need to be compiled to native code.
3:32:26
beach
Third, it changes the environment in which DEFGENERIC and DEFMETHOD forms are executed, though the result happens in the same environment as before.
3:32:32
beach
The third change allows me to put a DEFGENERIC <foo> followed by a DEFMETHOD <foo> or a DEFCLASS with <foo> as a slot accessor in the same file I didn't think that this feature would be important because I have complete control over the SICL sources, so I can organize them the way I please, but I also didn't see how to accomplish it.
3:32:46
beach
As it turns out, it becomes important when I start loading code that I don't control, like the portable condition system, though code like the compiler will still work because it comes later in the bootstrapping procedure. Furthermore, allowing DEFGENERIC followed by DEFCLASS will make the code look more "natural", which is an important goal.
3:32:48
beach
Also, using the AST evaluator I hope will allow me to make the SICL code more "natural", since the AST evaluator should be fast enough that I hope not to have to separate macro definitions and their expanders as often as I do now.
3:35:02
beach
I introduced a function SICL-CLOS:GENERIC-FUNCTION-CLASS-NAMES that takes the name of a generic function and returns two values, the name of a generic-function class and the name of a method class.
3:35:40
beach
It is called by DEFMETHOD at macro-expansion time, so that it can determine what arguments to pass to MAKE-METHOD-LAMBDA.
3:36:04
Bike
when you dump a couple paragraphs into chat like this every few days, the last thought on my mind is that you're not working :)
3:36:10
beach
By default, the new function returns the two symbols STANDARD-GENERIC-FUNCTION and STANDARD-METHOD.
3:37:46
beach
Under normal circumstances, when the file compiler is invoked, the function looks first in the compilation environment to see whether DEFMETHOD has dumped any information there.
3:38:31
beach
Then it looks in the evaluation environment for a generic function, and returns the information associated with it. Last, it looks in the startup environment again for an existing generic function.
3:40:34
beach
I think I have found the secret recipe for the new bootstrapping procedure, and it is almost as if the standard and the MOP were written to make it possible.
3:41:36
beach
I can define ENSURE-CLASS and ENSURE-GENERIC-FUNCTION in a special way during bootstrapping, so that they don't immediately use FDEFINITION and FIND-CLASS.
3:42:07
beach
That way, different environments are involved when a generic function is called, and when one is defined.
3:42:54
beach
Also, DEFCLASS needs to find superclasses and metaclasses in different environments, but I can hide that problem inside a temporary definition of ENSURE-CLASS.
3:44:53
beach
So FDEFINITION and FIND-CLASS will look up in the same environment as they execute in (say En), which is convenient. ENSURE-GENERIC-FUNCTION will look up or create in a different environment (En+1). ENSURE-CLASS will look up superclasses in En, but metaclasses in En-1.
3:45:41
beach
I may very well run into some problems that make this new scheme hard or impossible, but so far it is looking good. Keep your fingers crossed.
12:57:32
beach
I just had an epiphany!!!! Strange as it may seem, I have been thinking of an aspect of one of my own inventions (first-class global environments) the wrong way. I have been confusing two different concepts, namely 1. Loading compiled code (i.e. an AST) into some environment E1, and 2. "tying" the code to an environment E2.
12:57:49
beach
Up until now, I have been thinking that 1 implies 2, so that E1 = E2. Recall that a direct reference to a function (by name, say F) in compiled code gets turned into the de-referencing of some "cell".
12:57:57
beach
Also recall that this cell is found in E2 when the compiled code is loaded into E1 and then the cell is put into the static environment of the functions in the compiled code that refer to F. As I said, up until now, I always supplied the cell from E1 when the compiled code was loaded into E1.
12:58:05
beach
But that does not have to be the case. In fact, the essence of the epiphany is that the only role of E1 is to supply definitions of function to be executed at load time. My mistake was to refer directly to protocol functions for first-class global environments (or Clostrum) with a specific environment (E1) when the code is loaded.
12:58:14
beach
Instead, I should refer to functions such as (SETF CL:FDEFINITION), and FUNCTION-CELL (not the first-class global environments protocol function, but a function yet to be defined), etc. That way, these load-time functions can set the FDEFINITION in E2 and return the function cell in E2.
12:58:24
beach
Why is this important, you might ask? Well, as it turns out, it holds the key to a problem that I have not had a clue how to solve, namely how to create the initial native first-class global environments for the SICL executable. All the environments during bootstrapping are host objects, and I have been unable to figure out how to create the initial target environment as a SICL object.
12:58:25
beach
Now I know!!! One environment represented as a host object, into which code will be loaded, will contain functions to tie the code to a target environment, represented as a SICL object.
13:02:15
beach
This epiphany may also change how SICL code is executed in the host. Perhaps it could make HIR evaluation unnecessary (sorry if so, heisig). But I am not sure about that yet. More thinking is required.
13:07:35
beach
The hunch goes like this: In the last step of bootstrapping, Compiled code is loaded into some first-class global environments En, represented as a host object. The result of this action is native SICL code in some first-class global environments Esicl, but the code in that environment will never need to be executed in the host.
13:08:17
beach
I don't know what that means, and I haven't made up my mind about the terminology for the different environments.
13:09:46
beach
I used "loading" for E1 above, but that word is loaded [sic], so I need a different one.