Re: Adding to the end of the load path

[Mark H Weaver]

Hi Andreas,

Andreas Rottmann <address@hidden> writes:

> Ian Price <address@hidden> 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 <address@hidden>
> 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