libera/#sicl - IRC Chatlog
Search
7:49:33
beach
At some point, I introduced HOST-SYMBOL as a subclass of SYMBOL during bootstrapping. Now I am thinking that was a mistake. Instead, I am thinking I should work harder to pretend that host symbols are also SICL symbols.
7:50:42
beach
Such work would involve programming the HIR evaluator and the AST evaluator to get the right class when CLASS-OF is asked for, to get the unique number of the class when the STAMP is asked for, and to handle SYMBOL-NAME and SYMBOL-PACKAGE differently.
7:51:13
beach
For SYMBOL-NAME I am thinking of lazily generate SICL strings in a hash table mapping symbols to such strings.
7:52:24
beach
For packages, I am thinking I should integrate packages much earlier in the bootstrapping process, and change the way DEFPACKAGE is handled so that it also creates a SICL package.
7:54:01
splittist
Moving 'sophisticated' things like packages closer to the beginning of the bootstrap process seems consistent with the Tao of SICL.
7:54:09
beach
Oh and the hash table for symbol names could be created lazily, because I think SYMBOL-NAME is only asked for during printing.
12:46:24
beach
So it appears that I am working toward having fewer types of host objects in environment E5. And one such type that has created "problems" (i.e requiring special treatment) for me has been host functions, either those imported from the host, or created by the HIR evaluator.
12:46:25
beach
But I have a solution to that problem i think. Rather than using those objects directly, I can create instances of SICL SIMPLE-FUNCTION which is a standard object with a header and such, and then call SET-FUNCALLABLE-INSTANCE-FUNCTION to make the SIMPLE-FUNCTION instance executable, passing it the original host function.
12:47:32
beach
Then, I have a perfectly good SICL object that is both a SICL function, with a rack, a CLASS slot, and a stamp, so it will work as an argument to generic functions and such without special treatement.
12:49:25
beach
Furthermore, this idea could be the basis of much better debugging tools during bootstrapping. I simply keep the "original function", i.e., the one that was passed to SET-FUNCALLABLE-INSTANCE-FUNCTION in a slot in the header object, so that I can call SET-FUNCALLABLE-INSTANCE-FUNCTION again. Then I can wrap the original function in other code, for the purpose of tracing or setting breakpoints, etc.
12:50:19
beach
The usual way of doing that is to use the NAME of the function and the environment in which it is defined for wrapping. But it is much safer to modify the function object itself.
13:51:28
pjb
beach: don't you have "built-in-functions" that are not (cannot be) implemented using sicl?
13:52:44
beach
Well, the native function can always be implemented. It is just a matter of generating the right machine code. But some such functions can not be executed during bootstrapping in the host.
13:53:32
beach
But now I have a host object in there, and if it ever becomes the argument of a SICL generic function, its stamp is going to be asked for.
13:54:15
beach
What I do now is that I fake it, i.e., I configure the HIR evaluator to give me the unique number of a SICL class representing functions.