2008/4/25 Ludovic Courtès <[EMAIL PROTECTED]>: > Guile-VM is written as an independent project currently, so I don't > think it would fit well into core Guile, and I'm actually not sure it'd > be a good idea to put it there, at least for now.
[Jumping in again although I shouldn't since I don't normally follow activity on the list.] I might be missing something, but I think Andy's idea of putting guile-vm in the core is obviously the right thing to do. In fact, as soon as the vm is fully functional and stable (which may take time, I grant you that) I think it should replace the current evaluator except possibly for debugging. (Currently, the evaluator code is compiled twice---once for generating the sluggish version of the evaluator, and yet another time to produce the even more sluggish debugging evaluator. A vm could replace the sluggish evaluator. The debugging evaluator could be kept for supporting backtraces and the debugger.) I wanted to do this from the first instance when I tried out Keisuke's vm, but could never find time to do it. Even though other properties of Guile *should* be reasons for people to use Guile, I'm personally convinced that people take the slugishness as a sign of poor code and think this is the major reason why Guile hasn't been adopted to an extent several magnitudes more than currently. Another note: The author of QScheme (which has a very efficient byte-code interpreter) once teamed up with us with the aim to combine ideas from QScheme and Keisuke's vm to implement the Guile bytecode interpreter, but this never got started for real. Maybe it's worth looking at QScheme? Also, if I moved a bytecode interpreter into the core, I would probably look at the possibility to place GOOPS method dispatch as a central mechanism---maybe this could be the only form of type dispatch? I would try to remove type checking in all Guile primivites and move the responsibility for this to this core dispatch mechanism. In order not to loose backward compatibility for those using the Guile API from C in their applications, one could have type-dispatching glue-code with the old C API names. But if this seems too futuristic, just replacing the sluggish evaluator with the vm would give Guile a major boost. Be sure to test it against code using threads, though...
