From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Mark H Weaver Newsgroups: gmane.lisp.guile.devel Subject: Re: Adding to the end of the load path Date: Sun, 11 Nov 2012 02:50:17 -0500 Message-ID: <87wqxs8tom.fsf@tines.lan> References: <87sj8o20v0.fsf@googlemail.com> <87liecucrz.fsf@delenn.home.rotty.xx.vu> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1352620242 798 80.91.229.3 (11 Nov 2012 07:50:42 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 11 Nov 2012 07:50:42 +0000 (UTC) Cc: Ian Price , guile-devel@gnu.org To: Andreas Rottmann Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Sun Nov 11 08:50:52 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 1TXSJd-0005EN-Sv for guile-devel@m.gmane.org; Sun, 11 Nov 2012 08:50:50 +0100 Original-Received: from localhost ([::1]:55058 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TXSJU-0005nq-DL for guile-devel@m.gmane.org; Sun, 11 Nov 2012 02:50:40 -0500 Original-Received: from eggs.gnu.org ([208.118.235.92]:60552) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TXSJQ-0005n3-GB for guile-devel@gnu.org; Sun, 11 Nov 2012 02:50:39 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TXSJN-0003Zs-Ec for guile-devel@gnu.org; Sun, 11 Nov 2012 02:50:36 -0500 Original-Received: from world.peace.net ([96.39.62.75]:33990) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TXSJN-0003Zo-A4 for guile-devel@gnu.org; Sun, 11 Nov 2012 02:50:33 -0500 Original-Received: from 209-6-91-212.c3-0.smr-ubr1.sbo-smr.ma.cable.rcn.com ([209.6.91.212] helo=tines.lan) by world.peace.net with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from ) id 1TXSJF-0000S9-IZ; Sun, 11 Nov 2012 02:50:25 -0500 In-Reply-To: <87liecucrz.fsf@delenn.home.rotty.xx.vu> (Andreas Rottmann's message of "Thu, 08 Nov 2012 02:03:12 +0100") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.2 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Received-From: 96.39.62.75 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:15151 Archived-At: Hi Andreas, Andreas Rottmann writes: > Ian Price writes: > >> Hi guilers, >> >> On the #guile IRC channel, Mark Weaver has stressed to me that he thinks >> it would be a good idea for us to be able to add paths to the end of the >> load path, since it would allow us to, for example, prefer a built-in guile >> implementation over a guildhall provided one, when this exists. Right >> now, for the srfi[0] and guile-lib, I have handled this by not adding >> files to the package where they have been adopted by guile (e.g. statprof). >> >> Andreas Rottmann suggested something similar in February[1]. >> > I've attached a patch implementing that suggestion, FWIW. > >> I don't have any concrete proposals better than what Andreas has >> suggested, but I felt I should make this post to the list, lest Mark and >> I forget. >> > > [...] > >> 1. http://lists.gnu.org/archive/html/guile-devel/2012-02/msg00038.html > > > From 1f72ddd3971a796a6f83a68ebedde7d7324c50b5 Mon Sep 17 00:00:00 2001 > From: Andreas Rottmann > Date: Thu, 8 Nov 2012 01:59:56 +0100 > Subject: [PATCH] More flexible %load-path and %load-compiled-path handling > > --- > libguile/load.c | 25 +++++++++++++++++++++---- > 1 file changed, 21 insertions(+), 4 deletions(-) > > diff --git a/libguile/load.c b/libguile/load.c > index af2ca45..a05cf76 100644 > --- a/libguile/load.c > +++ b/libguile/load.c > @@ -226,7 +226,9 @@ SCM_DEFINE (scm_parse_path, "parse-path", 1, 1, 0, > "Parse @var{path}, which is expected to be a colon-separated\n" > "string, into a list and return the resulting list with\n" > "@var{tail} appended. If @var{path} is @code{#f}, @var{tail}\n" > - "is returned.") > + "is returned. In case an empty string occurs as an element\n" > + "of @var{path}, @var{tail} is inserted at that point instead of\n" > + "being append at the end of the list.") Note that 'parse-path' is documented in the manual, which would also have to be updated. However, I'm really not comfortable with changing the behavior of 'parse-path'. It is a documented general-purpose procedure which users may use for their own purposes, and I have recommended it as such. If we decide to use this general approach, I'd want to leave 'parse-path' alone, make a new procedure that behaves differently, and then maybe change a few uses of 'parse-path' within Guile to use that new procedure. I'm also not comfortable with having the empty string be the special marker separating the prepend and append portions of the path. As you noted in your earlier email, the empty string is currently interpreted as the current directory, and users may have come to rely on that. If we do this, I think the special marker should be a path component that is highly unlikely to occur in practice. Some ideas off the top of my head are: "...", "*", or " ". I think I like "..." best. What do you think? Mark