Noah Lavine <noah.b.lav...@gmail.com> writes: > For instance, I think it's really important to be able to load modules > written in > other languages. However, this may be language-dependent to a certain extent, > because > some languages (Python) already have ways to define modules. In those cases > we should > stick with their conventions, and use our other methods for figuring out what > language the file is in. For now, I think we can kinda punt on this issue. Mixing languages is hard; getting an interpreter running isn't, and the two seem orthogonal enough we can tackle them separately.
> However, if we're using Guile in one language and loading an executable in a > different language, then we can't use a command-line argument or a different > executable to signal it. The only choices left are heuristics and explicit > markers. I > think the only reasonable choice is both - use heuristics, and let the user > supply a > marker if the heuristics are wrong. (In the module case, one can imagine a > heuristic > based on having a language-specific load path for each language, which might > be very > effective.) I said as much in my summary, but I really don't like any of the solutions to the mixed-modules problem, but I think we are going to need some proof-of-concepts and some experience for these before we know how good/bad they are really going to be. > But for using Guile as an interpreter for different languages, a command-line > argument or argv[0] switch make a lot of sense. I've had quite a few votes for argv[0] so that's probably what it's going to be. --lang might be worth adding as an option under the "guile" name (or --from to match "guild compile") -- 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"
