From: Ian Price <ianprice90@googlemail.com>
To: Guile Mailing List <guile-devel@gnu.org>
Subject: non-scheme scripts: proposed solutions and their pros/cons
Date: Tue, 20 Nov 2012 12:15:38 +0000 [thread overview]
Message-ID: <87boesxyfp.fsf@googlemail.com> (raw)
As promised in the other thread, here is my list. This was really a
response to the even the earlier thread I started, which I
(unfortunately) didn't reply to at the time.
First off, they important question "why do we need this?". Well, guile
is a multi-language vm in principle, even if Scheme is it's first and
foremost citizen. If guile is to be a full-fledged vm for these other
languages, they need all (or at least most of) the rights and privileges
scheme does. This includes the ability to be run as scripts.
So, what are the solutions? Well, a few have cropped up, but I'm not
sure that individually any of them constitute a complete
solution. They are: a command-line argument, some marker in the
module, a different executable, and heuristics based on file
extension.
I shall treat these in order, though I can't pretend I will be
comprehensive. Clarifications and additions welcome.
* a command line argument
This was the position I initially proposed, and so had some bias
towards. The idea is very simple, we add a --language extension, the
argument to which would be the language of the file(s) we are trying
to execute.
** Pros
- Existing source files in the language do not need to be modified to
use this.
- Requires (in theory) modifying only the command-line parsing
** Cons
- Has nothing to say about how e.g. scheme modules interact with elisp modules.
- #! only gives you one argument, and not all languages are going to
support a \ type solution
* a file marker
The idea here it to have some way of marking in a file which language
it is written in, with some token like #!javascript, or perhaps
something like #!language javascript
** Pros
- works well with current module system
e.g. say we have a file foo/bar.js and that had a #!javascript
marker, then I could (use-modules (foo bar)) and guile would notice
the marker, switch to javascript mode for it.
- we already do this for switching to curly-infix and r6rs reader
modes
** Cons
- requires modifying existing source code, I couldn't just import an
existing elisp (or whatever) file and use as is.
- the existing mechanism allows switching reader mode at an arbitrary
part of the file. Not a big con, for #!language, I would simply say
we disallow it in arbitrary places. However, people that extend
guile as a language (i.e. lilypond), might disagree and would want
to take advantage of this.
* different executable
This was a position posed in response to mine, that I was initially
against, but am somewhat more open to now. The idea is that for every
language $foo, we have a script guile-$foo which invokes that
language.
Technically it need not be a different executable, but one whose
action depends on argv[0] and just performs the appropriate action,
but in many respects these can be treated the same.
** Pros
- Existing source files in the language do not need to be modified to
use this, they can change the existing languages symlink.
- We can handle common switches used by the language
- If you go for argv[0], may only require modifying the command-line
parsing.
** Cons
- proliferation of names, even if just symlinks
- has nothing to say about cross-language interoperability
* heuristics
This always gets proposed, and I never like it, but hey ho. The idea
is to have some simple way to guess what language a file is written
in, for example, with a mapping of file extensions to languages.
** Pros
Best case scenario, you do nothing. You type guile foo.js, and it just
works.
- same excutable name
- don't need to modify existing code
** Cons
*** guessing on file extension
- guile allows user defined extensions
Need to have a way of associating modes with new extensions
- some language share extensions
I'm thinking of .pl for perl and prolog, but I'm sure there are
other conflicts. Might not be a big con in practice
- Many files don't have an extension, think running with ./foo
*** guessing on content type
- Seems complicated to implement, especially for syntactically close
languages. Probably undecidable in general.
My thanks to William Leslie[0], Neil Jerram[1], and quotemstr on #emacs for
pointing out various pros/cons.
So, the million dollar question: what do we do?
Well, I don't know. :)
Maybe the argv[0] solution, with some extension for requiring modules
in other languages built into use-modules (similarly for other
languages). But that's less nice since now the calling module needs to
know the language of the module it's requiring.
0. https://lists.gnu.org/archive/html/guile-devel/2012-07/msg00067.html
1. https://lists.gnu.org/archive/html/guile-devel/2012-07/msg00068.html
--
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 reply other threads:[~2012-11-20 12:15 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-11-20 12:15 Ian Price [this message]
2012-11-20 13:14 ` non-scheme scripts: proposed solutions and their pros/cons Noah Lavine
2012-11-25 16:22 ` Ian Price
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=87boesxyfp.fsf@googlemail.com \
--to=ianprice90@googlemail.com \
--cc=guile-devel@gnu.org \
/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).