5:12:50beachBut a lot has to do with the enthusiasm of the speaker.
5:13:01beachtheemacsshibe[m]: The #clim channel will answer questions about CLIM and McCLIM. I usually hang out there, but I am traveling at the moment. I'll be back online on Wednesday.
5:31:18vtomoleAs long as it's not split up too much. I think this stays true to SICL's goal of separating a CL implementation into modules. An implementer will clone the sub-components he/she wants.
5:31:31beachstylewarning: Since the basic specification (i.e. the Common Lisp HyperSpec) is stable, I don't think it will be a big problem.
5:33:28beachvtomole: It is still non-trivial to use those modules though. For Eclector, either an implementation uses it as a second reader (it has to have a reader in order to read the Eclector source code) or the implementation must cross compile on a different implementation the way SICl does.
5:33:39stylewarningbeach: I guess if you expose CL-compatible symbols that’s good
5:37:01beachRight. But you are right. Take Eclector again. It has functionality that extends the Common Lisp HyperSpec, and that functionality is essential for client code, in particular source tracking. And it is important not to break client code that uses it.
5:39:37vtomolebeach: To me, Common Lisp implementations are overwhelming. How is the back-end of SICL going? Are you still planning on compiling to x86_64? How much resources (time) does it take to write a "good" optimizing compiler?
5:42:52beachvtomole: The back-end is almost done. I have a separate repository containing an assembler for x86-64.
5:43:11beachvtomole: So, what's left is bootstrapping.
5:43:40beachvtomole: Also optimizations both at the HIR and at the MIR level must be improved.
5:44:25beachvtomole: Hard to say how long it takes. I am not working on it full time, so it is taking longer.
5:46:15vtomoleFor sure, a lot of implementors compile their languages to LLVM because they don't want to deal with writing optimizers. But you are not worried about performance being equal to SBCL are you?
5:47:20beachI am not afraid of writing optimizers. There are plenty of published algorithms.
5:47:32beachBut they have to be adapted to the specific case of Common Lisp.
5:47:47beachI don't think it is going to work to rely on LLVM for optimizations.
5:48:29beachIt doesn't know how to do things like type inference, path replication, escape analysis and other things that are crucial to Common Lisp performance.
5:48:59beachThings like that have to be done before low-level code is generated.
5:50:15beachI'm off to have breakfast. I'll be back in a little while.