From: Ian Price <ianprice90@googlemail.com>
To: Noah Lavine <noah.b.lavine@gmail.com>
Cc: Guile Mailing List <guile-devel@gnu.org>
Subject: Re: non-scheme scripts: proposed solutions and their pros/cons
Date: Sun, 25 Nov 2012 16:22:02 +0000 [thread overview]
Message-ID: <87zk25bql1.fsf@Kagami.home> (raw)
In-Reply-To: <CA+U71=M51eHeKrN1mr+O3FpvtgqRgPdn+NPWCE0ERyrxd1g83g@mail.gmail.com> (Noah Lavine's message of "Tue, 20 Nov 2012 08:14:46 -0500")
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"
next prev parent reply other threads:[~2012-11-25 16:22 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-11-20 12:15 non-scheme scripts: proposed solutions and their pros/cons Ian Price
2012-11-20 13:14 ` Noah Lavine
2012-11-25 16:22 ` Ian Price [this message]
2012-11-20 16:10 ` Ian Price
2012-11-25 16:06 ` Ian Price
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/guile/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87zk25bql1.fsf@Kagami.home \
--to=ianprice90@googlemail.com \
--cc=guile-devel@gnu.org \
--cc=noah.b.lavine@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).