So, here's the "plan of attack" I'm envisioning for this. Right now, questions of cross-language module referencing can be ignored. I think it is mostly orthogonal to the current goal of running non-scheme scripts.
First, I'm going to try and write a proof-of-concept guile-elisp executable. This shouldn't be too hard, I think, and may shed some light on expected difficulties. Secondly, the more serious version. While I can't know all the details till I've done the previous stage, here is what I think I need to do. command-line parsing needs to be moved under the language/$lang directories, and a command line parser field added to guile's language objects. Languages that wish to customise it can add one, or we can have a default one that mostly mimics guile's current interface, and allows executing scripts, lines, etc. We may also want to all language objects to specify one or a set of allowed argv[0] names. While I do not know if anyone actually uses it, we will probably need to keep ice-9/command-line.scm functionally intact for backwards compatibility. With this additional layer of indirection[0], we now dispatch to the correct command-line parser based on the argv[0] name, set the repl language etc. etc. One important issue with this is that it is likely to slow down the time it takes guile to boot, however, is should accommodate any user-written languages. The other thing is, I'm not sure how this is going to affect the C code for guile. It _might_ be possible to do this all in Scheme, but until I've tried, I'm going to remain sceptical. If you have a better suggestion please tell me :) 0. as we all know, "in computer science, every problem can be solved with an additional layer of indirection" -- Ian Price -- shift-reset.com "Programming is like pinball. The reward for doing it well is the opportunity to do it again" - from "The Wizardy Compiled"
