From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Neil Jerram Newsgroups: gmane.lisp.guile.user Subject: Re: Modules Date: Sat, 29 Jan 2011 23:17:08 +0000 Message-ID: <87tygrcnbf.fsf@ossau.uklinux.net> References: <20101208124502.5f25b64d@halmanfloyd> <20110129131315.506f1e8c@halmanfloyd> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: dough.gmane.org 1296343048 32449 80.91.229.12 (29 Jan 2011 23:17:28 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Sat, 29 Jan 2011 23:17:28 +0000 (UTC) Cc: guile-user@gnu.org To: Andy Wingo Original-X-From: guile-user-bounces+guile-user=m.gmane.org@gnu.org Sun Jan 30 00:17:24 2011 Return-path: Envelope-to: guile-user@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1PjK2j-00085Y-Q8 for guile-user@m.gmane.org; Sun, 30 Jan 2011 00:17:22 +0100 Original-Received: from localhost ([127.0.0.1]:55450 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PjK2j-0007Gg-AK for guile-user@m.gmane.org; Sat, 29 Jan 2011 18:17:21 -0500 Original-Received: from [140.186.70.92] (port=33501 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PjK2f-0007Gb-MD for guile-user@gnu.org; Sat, 29 Jan 2011 18:17:18 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PjK2c-0003rs-V3 for guile-user@gnu.org; Sat, 29 Jan 2011 18:17:17 -0500 Original-Received: from mail3.uklinux.net ([80.84.72.33]:49413) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1PjK2c-0003rm-Ln for guile-user@gnu.org; Sat, 29 Jan 2011 18:17:14 -0500 Original-Received: from arudy (unknown [78.145.28.138]) by mail3.uklinux.net (Postfix) with ESMTP id D83B41F6662; Sat, 29 Jan 2011 23:17:11 +0000 (GMT) Original-Received: from neil-laptop (unknown [192.168.11.3]) by arudy (Postfix) with ESMTP id 0BA5E3801E; Sat, 29 Jan 2011 23:17:08 +0000 (GMT) In-Reply-To: (Andy Wingo's message of "Sat, 29 Jan 2011 18:04:14 +0100") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.4-2.6 X-Received-From: 80.84.72.33 X-BeenThere: guile-user@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: General Guile related discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: guile-user-bounces+guile-user=m.gmane.org@gnu.org Errors-To: guile-user-bounces+guile-user=m.gmane.org@gnu.org Xref: news.gmane.org gmane.lisp.guile.user:8401 Archived-At: Andy Wingo writes: > Hi Marek, > > On Sat 29 Jan 2011 13:13, Marek Kubica writes: > >> What about "the same directory that the file is in"? The point is, when >> writing scripts that become larger than one file, splitting them into >> modules becomes immensely painful because the modules cannot find each >> other. > > For what purpose? If you are using modules, they are already in one > global namespace, the various roots of which are in the %load-path > and/or %load-compiled-path. (resolve-module '(foo bar)) should work > regardless of what file calls it. If the modules are installed, that's true. What if they are not? Even if all of the non-installed modules are in a single tree, things are a bit fiddly. For work from a REPL or from Geiser, you can put (set! %load-path (cons "whatever" %load-path)) in ~/.guile, and (load (in-vicinity (getenv "HOME") ".guile")) in ~/.guile-geiser, but this doesn't do the job for scripts that want to use those modules. (Because scripts do not load ~/.guile.) For scripts that use uninstalled modules, then, some kind of solution is needed; ideally one that works for both 1.8 and 1.9/2.0, allows the code needed to live in a single common file, rather than duplicated at the top of each script; and continues to work if the script+module tree as a whole is moved to a different place in the filesystem. Also I think it's preferable if the solution is a Guile one, as opposed to based on the #! line, or needing a shell script wrapper. > Perhaps you are interested in `load', which is problematic regarding > compiled files; for example when loading from a compiled file, how will > `load' know what is the current directory? Note that .go files are > installed to e.g. /usr/lib64/guile, while source is in /usr/share/guile. Good point, thanks for the reminder about that. But (for 1.9/2.0) `include' will always be well-defined and reliably relative to the containing file's name, won't it? Regards, Neil