libera/#sicl - IRC Chatlog
Search
4:18:05
beach
nij-: Here is how you can think of those implementations that evolve by modification of an existing image: Imagine SBCL but the source code is lost, so all you have is a core file and the SBCL program. Now you want to add some feature. You then start SBCL, perhaps load a file with the code that creates the new feature, then do (SAVE-LISP-AND-DIE) to get a new core file. As you can see, since the source code is lost, there is no other
4:24:02
beach
Setting *COMPILE-VERBOSE* and *COMPILE-PRINT* to NIL makes it easier to spot warnings and such.
11:24:14
nij-
beach I see. Sounds like a dangerous way.. I wonder how they keep their modifications.
11:24:32
nij-
Perhaps.. they have their first lisp image stored, and the rest are written in a file.
11:25:34
nij-
Hmmm but then I wonder, take LW for example (which is developed with the image-based method), how do they support more external features (e.g. OS threads) simply by modifying the image?
11:36:37
beach
And, as I recall from the paper by Krystof, only SBCL (among the implementations written essentially in Common Lisp) can build from source. And they don't evaluate code in the host. So SICL is the only one going one step further.
11:39:37
beach
Another interesting thing is the, apparently widespread, idea that a Common Lisp system must be written in some (presumably lower level) language. I know ECL and Clasp were made that way for reasons of interoperability, but I hear this argument from relative newbies who want to write their on Lisp implementation.
11:44:12
nij-
Their initial image can be written in whatever low-level language (e.g. C), so that if they want to support other things, they can change it.
11:44:21
beach
I doubt it has those kinds of advantages. I mean, nothing prevents SBCL from developing that way, and then just do a final build from source.
11:44:31
nij-
They save the, say C, source and version control. The rest, they can all do with lisp.
11:47:25
nij-
Building from a lower-level lang certainly feels easier cause that's closer to the end result.
11:47:55
nij-
And while CL is very powerful, any naive way would produce an image of things you want and all the extra CL that you don't want, which are hard to tree-shake.
11:48:15
beach
But as I have explained, it is much harder because you then need to write additional modules in "pidgin" Lisp.
11:48:18
nij-
The actual difficulty of your approach seems to be figuring out a way to "remove" the unwanted part.
11:49:05
nij-
Right. I'm still trying to understand why that's "harder". I guess I need to have hands-on experience to feel that.
11:49:17
beach
I think you are still imagining that SBCL and SICL are built as additions to a host Common Lisp system. They are not.
11:51:00
nij-
So you still need to produce the end result, but you need to write it in a lang that is relatively unnative comparing to the target (e.g. x86 or asm).
11:51:53
nij-
But it gains something back (e.g. we can have independent cl libs written and maintained in CL.)
11:51:56
beach
You still have to write the compiler to produce machine code, unless go generate C the way ECL does.