freenode/#sicl - IRC Chatlog
Search
12:44:07
no-defun-allowed
Not exactly relevant is the way Squeak Smalltalk was bootstrapped, which I find a bit fascinating: http://ftp.squeak.org/docs/OOPSLA.Squeak.html
12:44:39
jackdaniel
if I understand correctly, you want to create a separate cl implementation for a sole purpose of bootstrapping from c (that is c -> cl -> cl); I think that ecl, as bootstrapped from c, already fills this gap so the task would be more or less opening the unlocked door. as of transpiling CL -> C, ecl's compiler also is capable of doing that, however it targets its own C-ish runtime of course
12:46:31
no-defun-allowed
That was produced by passing the source code for the interpreter in the Blue Book into a Smalltalk-to-C translator, as well as a small amount of C code for interfacing with the operating system. But HIR is much more complex than the subset of Smalltalk used in the interpreter, from memory.
12:46:46
beach
jackdaniel: Me? Yes, but the C code of ECL is more complicated than a BOCL would need, because ECL is designed with performance in mind. A BOCL could be much simpler, and then also simplify the C code of ECL, and even eliminate a lot of it.
12:47:46
beach
pjb: If you look at the channel logs, I asked the question (without expecting an answer) whether C code that is generated was acceptable as counting as "source code".
12:49:13
beach
shka_: But it has to be maintained. And, as I said, I am imagining ways of decreasing the maintenance burden of ECL and other Common Lisp implementations.
12:49:41
beach
jackdaniel: If there is a reader and/or an evaluator written in C, then to me, that is already complex.
12:50:33
no-defun-allowed
And then the Smalltalk I hacked on a Wii is someone's port of that interpreter from said Book to C++, with my own I/O code and some tweaks for endianness. But that interpreter is written (in my opinion) in a restricted way, so that it can be translated into a less expressive language.
12:50:58
beach
no-defun-allowed: HIR could definitely be translated to C. After all, it can be translated to assembly.
12:51:49
beach
no-defun-allowed: And, again, it is unclear whether generated code would count as "source code". It does not, according to the definition by the FSF, for instance.
12:55:11
no-defun-allowed
Defining that generated code is source code would probably break restrictive licenses that are used for, say, JavaScript libraries which are transmitted in obfuscated and compressed form, so it would be wise not to define it like that in the general case.
12:56:23
beach
Yeah, and I am pretty sure that jackdaniel would consider that solution unacceptable, or else, he would have thought of it before.
12:56:35
pjb
beach: "maintainable code" or not. But what's generated should not be considered as source. It can be considered as an intermediate representation compilable on a target system.
12:57:58
beach
But I am not going to pursue it. It is clear to me that jackdaniel is fine with the way ECL is currently written. So consider it as just a thought experiment.
12:58:17
no-defun-allowed
No doubt that HIR could be translated to C, but that would require more of a compiler than Squeak did...the interpreter is written with simple control flow and mostly works on words and vectors of words.
12:59:46
beach
I do think the idea of BOCL is interesting though. Write a Common Lisp in C, but in a way that makes it as easy as possible to maintain, rather than fast or whatever.
13:00:04
no-defun-allowed
So I wouldn't think it to be a SICL-y thing to do; but I don't know if that's a necessity in this context.
13:01:04
no-defun-allowed
I had better head out as well; I will reread this tomorrow and will see if anything else comes to mind.
13:09:04
MichaelRaskin
Speaking of layers-of-expanding-languages and bootstrap, I think GNU Guix people think that even C bootstrap is best implemented as a multi-layer process. Think, as in «have implemented such a multi-stage bootstrap».
13:11:13
jackdaniel
I imagine troubleshooting malfunctioning transpiled code could be harder to debug (the bug may be in Common Lisp reader source, in the transpiler source, or there might be some bootstrapping issue of the reader itself - i.e that it depends on something what is not available yet in the system)
13:11:50
jackdaniel
also, depending on such transpiled code may be a subject of metastability issues when indeed bootstrapping from i.e gcc
13:13:46
jackdaniel
in other words, it is not given that such dependency won't add /more/ complexity instead of removing it
13:14:05
pjb
jackdaniel: of course, you need to locate the bug, but it's not difficult to debug. As always, you need to determine if it's the "current" source that is in error, and if so, correct it and its producer.
13:14:34
pjb
jackdaniel: if you're a good programmer, you know what I mean: when you debug, you not only correct the bug, but you correct yourself to avoid producing the same bug again!
13:15:14
jackdaniel
maybe I'm a bad programmer, because sometimes understanding the issue takes me days or even weeks
13:18:57
jackdaniel
I'll stick to the interpretation, that I'm a bad programmer, if that's the implication of not finding "fixing bugs" easy. most bugs I encounter are architectural issues and I don't think tooling is much of help when you need to think of an architectural change which a) won't introduce regression, b) will fix the issue
13:21:19
MichaelRaskin
beach: just as you discussed in your talk — inner layers are more limited, lacking some of abilities.
13:30:25
beach
MOP question: I am reading the MOP page on Initialization of Class Metaobjects in chapter 6. It says that when the class is initialized, a default superclass may be added (as expected). But it doesn't say that when the class is reinitialized. So if I create a standard class with direct-superclasses being the empty list and then I reinitialize it with an empty list, is the class no longer a subclass of standard-object?
13:33:06
beach
SBCL still includes STANDARD-OBJECT if I do (reinitialize-instance (find-class '... :direct-superclasses '()))
13:35:13
pjb
My understanding is that it could be done lazily. So a change of the direct-superclass list can have no (immediate) effect.
13:36:00
beach
I think the page I am talking about makes that clear. Except I think it has an error on it.
14:38:49
beach
OK, so it seems the SICL code for "Initialization of Class Metaobjects" is all in the form of a primary method on SHARED-INITIALIZE and that is wrong, because some behavior differs between initialization and reinitialization. So I need to separate that code into a method on SHARED-INITIALIZE for things that behave the same, one on INITIALIZE-INSTANCE for initialization-specific behavior, and one on REINITIALIZE-INSTANCE for behavior
14:39:35
beach
Now, it is time to fix it. But not today. I am too tired, and if I try, I will make mistakes.
14:40:34
beach
Plus, I may need time after the change to debug anomalies, and if I implement the fix today, I won't have that time.