Re: non-scheme scripts: proposed solutions and their pros/cons

[Ian Price <ianprice90@googlemail.com>]

Noah Lavine <noah.b.lavine@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"