Re: Adding to the end of the load path

[Andreas Rottmann]

Mark H Weaver <address@hidden> writes:

> Hi Andreas,
>
> Andreas Rottmann <address@hidden> writes:
>
>> Ian Price <address@hidden> writes:
>>
>> 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.
>
Good point.

> 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?
>
Another idea would be to use an additional environment variable,
e.g. GUILE_LOAD_{COMPILED_,}_PATH_SUFFIX.  If we cannot use the empty
string as special token, I'd prefer introducing additional environment
variables.  IMO, introducing a "special token", for which there is no
"natural" equivalent is not the most beautiful design.  The empty string
is the only "special token", for which the escape sequence is even more
natural than itself: just use the single dot for the current directory,
instead of the empty string.  I however undertand it's an incompatible
change, so I suggest using additional environment variables.

What's also still missing is a corresponding command-line switch, if we
want to even provide one -- notably, GUILE_LOAD_COMPILED_PATH also has
no corresponding command-line switch.  Any opinion on whether we want
these command-line switches, and if so, suggestions on names?

Regards, Rotty
-- 
Andreas Rottmann -- <http://rotty.xx.vu/>