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: Re: non-scheme scripts: proposed solutions and their pros/cons Date: Sun, 25 Nov 2012 16:22:02 +0000 Message-ID: <87zk25bql1.fsf@Kagami.home> References: <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 1353860535 11153 80.91.229.3 (25 Nov 2012 16:22:15 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 25 Nov 2012 16:22:15 +0000 (UTC) Cc: Guile Mailing List To: Noah Lavine Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Sun Nov 25 17:22:26 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 1TceyO-0004uf-NU for guile-devel@m.gmane.org; Sun, 25 Nov 2012 17:22:24 +0100 Original-Received: from localhost ([::1]:41902 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TceyD-000780-Rp for guile-devel@m.gmane.org; Sun, 25 Nov 2012 11:22:13 -0500 Original-Received: from eggs.gnu.org ([208.118.235.92]:36578) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TceyA-00077t-0E for guile-devel@gnu.org; Sun, 25 Nov 2012 11:22:11 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Tcey8-0005Wc-IL for guile-devel@gnu.org; Sun, 25 Nov 2012 11:22:09 -0500 Original-Received: from mail-wg0-f41.google.com ([74.125.82.41]:32958) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Tcey8-0005WM-Br for guile-devel@gnu.org; Sun, 25 Nov 2012 11:22:08 -0500 Original-Received: by mail-wg0-f41.google.com with SMTP id ds1so1507288wgb.0 for ; Sun, 25 Nov 2012 08:22:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:subject:references:date:in-reply-to:message-id :user-agent:mime-version:content-type; bh=b+WaXO7rJPxKoOmuJf7sZobtpBxK8t32H1XuFpMjlp4=; b=l64CoqgGdxCg/DGi8q+If5lEVjx6qq/qd33CBoDcbqJ+uR0v5dk3xEgwQrDbqjbf/6 49od7JL9zyOpG9v+T40RNh2Czqa570W8SSfhRSnnHoICIV8d8h5ADTZzPAElxxqIQTER H0OpBqNVUZy8sUrCGWQvx0+wuzzAmFuJPTtaVF6SFUU092ya4XBshLRfo30O+9zEzCw9 z+OMLlL8uTzSiE1/Ocoe4mp0plcdoVB+Jvx3GFpEt26IvoMXZ0dCaB7ZM8QqlLoytvWG KCqXY5Vh2W0EX+QE2mj/NOO2NCSqRjNcnsqrj68W6QmULhbXF7Iwkz32wrCy+8QnPtEL Ekzw== Original-Received: by 10.216.226.137 with SMTP id b9mr3234149weq.137.1353860527472; Sun, 25 Nov 2012 08:22:07 -0800 (PST) Original-Received: from Kagami.home (host86-182-157-241.range86-182.btcentralplus.com. [86.182.157.241]) by mx.google.com with ESMTPS id p3sm17426931wic.8.2012.11.25.08.22.05 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 25 Nov 2012 08:22:06 -0800 (PST) In-Reply-To: (Noah Lavine's message of "Tue, 20 Nov 2012 08:14:46 -0500") 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.41 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:15250 Archived-At: Noah Lavine 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"