From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Ian Price Newsgroups: gmane.lisp.guile.devel Subject: non-scheme scripts: proposed solutions and their pros/cons Date: Tue, 20 Nov 2012 12:15:38 +0000 Message-ID: <87boesxyfp.fsf@googlemail.com> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1353413760 3579 80.91.229.3 (20 Nov 2012 12:16:00 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 20 Nov 2012 12:16:00 +0000 (UTC) To: Guile Mailing List Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Tue Nov 20 13:16:11 2012 Return-path: Envelope-to: guile-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1TamkJ-0000pk-Ie for guile-devel@m.gmane.org; Tue, 20 Nov 2012 13:16:07 +0100 Original-Received: from localhost ([::1]:38661 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Tamk9-0004Em-0s for guile-devel@m.gmane.org; Tue, 20 Nov 2012 07:15:57 -0500 Original-Received: from eggs.gnu.org ([208.118.235.92]:40659) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Tamk5-0004EQ-9m for guile-devel@gnu.org; Tue, 20 Nov 2012 07:15:54 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Tamjy-00023A-A7 for guile-devel@gnu.org; Tue, 20 Nov 2012 07:15:53 -0500 Original-Received: from mail-we0-f169.google.com ([74.125.82.169]:53348) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Tamjx-000221-OV for guile-devel@gnu.org; Tue, 20 Nov 2012 07:15:46 -0500 Original-Received: by mail-we0-f169.google.com with SMTP id t49so95148wey.0 for ; Tue, 20 Nov 2012 04:15:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:subject:date:message-id:user-agent:mime-version :content-type; bh=Evzq2IpuKhzhUJB5BB/PxiAEbpI1zIYGEGhCkhJiMjE=; b=h5Ka94LDqBJcNI4YiCf1DUjmoOi4VfW1D9dLds3VtE4nrp7M7+QnKulSFNV1IMpR4C mbP6rMjbnqEozb6s59VvFJpV1Eld6kPtezUKs278IkxJMFA0VNgXPAUpS2UHF3JO84D+ 8T0xJ9zmeZoW3HOYxhwbqaFZpDKGebb+a6JN+WjwGYFjy+zuyqQ7E1yl7pG77qp8raBB LjNi9osKXgidBS2bo3BWPTeyKZqg1d8UzrDLC19QcqhA6dNHjxtVZa3Pun5v/MBQxrJP t5gAoCqtar4zP+5D/1fxsmPjtdwr8xHZuAkV38ivUVoR3ICjFGJqgF4Su37lNlHalzbu n4pw== Original-Received: by 10.181.11.163 with SMTP id ej3mr14096650wid.11.1353413744893; Tue, 20 Nov 2012 04:15:44 -0800 (PST) Original-Received: from Kagami (host86-174-103-169.range86-174.btcentralplus.com. [86.174.103.169]) by mx.google.com with ESMTPS id az2sm17513150wib.7.2012.11.20.04.15.42 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 20 Nov 2012 04:15:43 -0800 (PST) User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.3 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x [fuzzy] X-Received-From: 74.125.82.169 X-BeenThere: guile-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Developers list for Guile, the GNU extensibility library" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Original-Sender: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.lisp.guile.devel:15216 Archived-At: 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"