Adding to the end of the load path

Adding to the end of the load path

[Ian Price]

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 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.

0. My apologies to whomever it was who reported breakage in the srfi
package (and sorry that I've forgotten your name). I have been fixing
it, but my current version still has some issues. I promise I will post
a guildhall update to here, and guile-user sometime in the next week or
two.
1. http://lists.gnu.org/archive/html/guile-devel/2012-02/msg00038.html
-- 
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"

Re: Adding to the end of the load path

[Andreas Rottmann]

[-- Attachment #1: Type: text/plain, Size: 877 bytes --]

Ian Price <ianprice90@googlemail.com> 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


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-More-flexible-load-path-and-load-compiled-path-handl.patch --]
[-- Type: text/x-diff, Size: 1855 bytes --]

From 1f72ddd3971a796a6f83a68ebedde7d7324c50b5 Mon Sep 17 00:00:00 2001
From: Andreas Rottmann <a.rottmann@gmx.at>
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.")
 #define FUNC_NAME s_scm_parse_path
 {
 #ifdef __MINGW32__
@@ -237,9 +239,24 @@ SCM_DEFINE (scm_parse_path, "parse-path", 1, 1, 0,
   
   if (SCM_UNBNDP (tail))
     tail = SCM_EOL;
-  return (scm_is_false (path)
-	  ? tail
-	  : scm_append_x (scm_list_2 (scm_string_split (path, sep), tail)));
+  if (scm_is_false (path))
+    return tail;
+  else
+    {
+      SCM elements = scm_string_split (path, sep);
+      SCM seen = SCM_EOL;
+      SCM rest = elements;
+
+      for (; scm_is_pair (rest); rest = SCM_CDR (rest))
+        {
+          if (scm_is_true (scm_string_null_p (SCM_CAR (rest))))
+            return scm_append_x (scm_list_2 (scm_reverse_x (seen, tail),
+                                             SCM_CDR (rest)));
+          seen = scm_cons (SCM_CAR (rest), seen);
+        }
+
+      return scm_append_x (scm_list_2 (elements, tail));
+    }
 }
 #undef FUNC_NAME
 
-- 
1.7.10.4


[-- Attachment #3: Type: text/plain, Size: 63 bytes --]


Regards, Rotty
-- 
Andreas Rottmann -- <http://rotty.yi.org/>

Re: Adding to the end of the load path

[Mark H Weaver]

Hi Andreas,

Andreas Rottmann <a.rottmann@gmx.at> writes:

> Ian Price <ianprice90@googlemail.com> 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 <a.rottmann@gmx.at>
> 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

Re: Adding to the end of the load path

[Andreas Rottmann]

Mark H Weaver <mhw@netris.org> writes:

> Hi Andreas,
>
> Andreas Rottmann <a.rottmann@gmx.at> writes:
>
>> Ian Price <ianprice90@googlemail.com> writes:
>>
>> From 1f72ddd3971a796a6f83a68ebedde7d7324c50b5 Mon Sep 17 00:00:00 2001
>> From: Andreas Rottmann <a.rottmann@gmx.at>
>> 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/>

Re: Adding to the end of the load path

[Mark H Weaver]

Andreas Rottmann <a.rottmann@gmx.at> writes:

> Mark H Weaver <mhw@netris.org> writes:
>
>> 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.

This is certainly the cleanest solution, but there is a complication: if
a user has multiple versions of Guile installed on their system, some of
which look for GUILE_LOAD_PATH_SUFFIX and some which do not, there is no
way for them to configure their environment variables that will work
correctly for all versions.  Guile 2.0.5 will be widely deployed until
at least 2017, since it is part of Ubuntu 12.04 LTS.  We have to cope
with that somehow.

With the "special path component" approach, a user can configure their
GUILE_LOAD_PATH properly today, and it will behave reasonably well on
all versions of Guile.  For older versions of Guile, it will prepend all
components to the path, including the special token which adds two
stat(2) calls per module-load but is otherwise harmless.  For newer
versions, it will do what we want.

Although not as elegant as I'd like, this seems to be the only workable
solution to our problems regarding SRFIs in Guildhall.  It means that we
can immediately start asking users to put "..." in their GUILE_LOAD_PATH
when configuring Guildhall.  The fact that older versions of Guile will
prepend _all_ path components is not a problem, because our Guildhall
repositories we include only SRFIs that are not yet included in core
Guile.  The additional functionality will start working precisely when
it needs to, because only future versions of Guile will include SRFIs
that are also included in Guildhall.

What do you think?

If we can come up with a more elegant solution to this problem that
works with both old and new versions of Guile, I'm open to suggestions.

    Regards,
      Mark

Re: Adding to the end of the load path

[Bruce Korb]

On 11/11/12 13:51, Mark H Weaver wrote:
> This is certainly the cleanest solution, but there is a complication: if
> a user has multiple versions of Guile installed on their system, some of
> which look for GUILE_LOAD_PATH_SUFFIX and some which do not, there is no
> way for them to configure their environment variables that will work
> correctly for all versions.  Guile 2.0.5 will be widely deployed until
> at least 2017, since it is part of Ubuntu 12.04 LTS.  We have to cope
> with that somehow.

Declare Guile 2.0.5 to be buggy and recommend Ubuntu/Debian to
upgrade with a patch that fixes the LD_LIBRARY_PATH/*_LOAD_PATH stuff?

> What do you think?

Maybe a 2.0.5.1 release that just fixes this bit and fold it
into the main branch, too.

Re: Adding to the end of the load path

[Ludovic Courtès]

Hi!

Sorry for the delay.

Andreas Rottmann <a.rottmann@gmx.at> skribis:

> Ian Price <ianprice90@googlemail.com> writes:

[...]

>> 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

Like Mark, I’m not comfortable with changing the meaning of the empty
string in the load path, and the behavior of ‘%parse-path’.

I pretty much like Mark’s suggestion of using ‘...’ as a special marker,
even though that’s a valid file name.

How would that work for you?

Thanks,
Ludo’.

Re: Adding to the end of the load path

[Andreas Rottmann]

ludo@gnu.org (Ludovic Courtès) writes:

> Hi!
>
> Sorry for the delay.
>
> Andreas Rottmann <a.rottmann@gmx.at> skribis:
>
>> Ian Price <ianprice90@googlemail.com> writes:
>
> [...]
>
>>> 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
>
> Like Mark, I’m not comfortable with changing the meaning of the empty
> string in the load path, and the behavior of ‘%parse-path’.
>
I agree to that -- there's quite a risk breaking existing setups this
way.

> I pretty much like Mark’s suggestion of using ‘...’ as a special marker,
> even though that’s a valid file name.
>
Well, there's a workaround -- specifying "./..." as an "escape sequence"
for "..." if you really need to have a three-dot relative directory in
the path.

> How would that work for you?
>
I would like the approach using separate _SUFFIX variables better, as it
doesn't have this special case.  While I don't think the special case
will be a problem for a user setting the environment variables
themselves, if you want to set them programatically, you now have to
consider treat "..." specially, escaping it like mentioned above, to be
general.  However, I can live with that, but maybe we can have it both
ways:

- Add the _SUFFIX environment variables, making it clear in the docs
  that they are supported only from Guile 2.0.7 onward.

- Additonally, add "..." as a special marker, but mention it is just
  provided to support Guile < 2.0.7, and should not be used in code that
  needs to depend on Guile 2.0.7 or newer for other reasons
  (e.g. reliance on another added feature or significant bugfix).

I'm not sure how the deprecation strategy is employed exactly, but we
could mark the "..." feature as deprecated right away, or at least in
master, and remove it in 2.2 or 2.4. This would also kind of lift the
"burden" from programs manipulating *_LOAD_PATH programatically, as they
can still be "general" wrt. _undeprecated_ features.  Opinions?

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

Re: Adding to the end of the load path

[Ludovic Courtès]

Hi Andreas,

Andreas Rottmann <a.rottmann@gmx.at> skribis:

> ludo@gnu.org (Ludovic Courtès) writes:

[...]

>> I pretty much like Mark’s suggestion of using ‘...’ as a special marker,
>> even though that’s a valid file name.
>>
> Well, there's a workaround -- specifying "./..." as an "escape sequence"
> for "..." if you really need to have a three-dot relative directory in
> the path.

Right.  In general, it’s a bad idea to use relative file names in such
variables anyway.

>> How would that work for you?
>>
> I would like the approach using separate _SUFFIX variables better, as it
> doesn't have this special case.

OK.  I dislike the proliferation of environment variables, but yeah, it
might somewhat less ugly than ‘...’.

> - Add the _SUFFIX environment variables, making it clear in the docs
>   that they are supported only from Guile 2.0.7 onward.
>
> - Additonally, add "..." as a special marker, but mention it is just
>   provided to support Guile < 2.0.7, and should not be used in code that
>   needs to depend on Guile 2.0.7 or newer for other reasons
>   (e.g. reliance on another added feature or significant bugfix).

Blech, that second part is terrrible.

Mark is right that ‘...’ is the only workable solution, in terms of
compatibility.  So we need that one.

A potential problem is that in .bashrc, shell scripts, etc., it’s going
to be hard to make sure that ‘...’ remains first, when that’s what you
want, because you’ll inevitable find legacy code that does things like:

  export GUILE_LOAD_PATH="$HOME/soft/share/guile/site/2.0${GUILE_LOAD_PATH:+:}$GUILE_LOAD_PATH"

thereby moving ‘...’ further away.

Pfff, this is really terrible.

Mark: WDYT?

Ludo’.

Re: Adding to the end of the load path

[Mark H Weaver]

Hi Andreas,

Andreas Rottmann <a.rottmann@gmx.at> writes:

> ludo@gnu.org (Ludovic Courtès) writes:
>
>> I pretty much like Mark’s suggestion of using ‘...’ as a special marker,
>> even though that’s a valid file name.
>>
> Well, there's a workaround -- specifying "./..." as an "escape sequence"
> for "..." if you really need to have a three-dot relative directory in
> the path.
>
>> How would that work for you?
>>
> I would like the approach using separate _SUFFIX variables better, as it
> doesn't have this special case.

As I wrote earlier, I certainly agree that the _SUFFIX approach is
cleaner.  Unfortunately, we need a solution that will work nicely with
earlier versions of Guile.

> While I don't think the special case
> will be a problem for a user setting the environment variables
> themselves, if you want to set them programatically, you now have to
> consider treat "..." specially, escaping it like mentioned above, to be
> general.

Note that PATH-style variables are already not general, because they
provide no way to include filenames containing ':' (a colon).

In general, it's best to avoid setting GUILE_LOAD_PATH programmatically,
because it will affect more than just the instance of Guile you
intended; it will also affect any subprocesses that use Guile.  It's
better to use -L which is fully general without any special cases, or to
modify %load-path within the program itself.

> However, I can live with that, but maybe we can have it both
> ways:
>
> - Add the _SUFFIX environment variables, making it clear in the docs
>   that they are supported only from Guile 2.0.7 onward.

Yes, I agree this is a good idea.

> - Additonally, add "..." as a special marker, but mention it is just
>   provided to support Guile < 2.0.7, and should not be used in code that
>   needs to depend on Guile 2.0.7 or newer for other reasons
>   (e.g. reliance on another added feature or significant bugfix).

Again, these environment variables are not specific to any particular
piece of code.  They are usually associated with an entire user account.

> I'm not sure how the deprecation strategy is employed exactly, but we
> could mark the "..." feature as deprecated right away, or at least in
> master, and remove it in 2.2 or 2.4.

I don't think we can mark it deprecated until versions of Guile older
than 2.0.7 have become very rare, which won't be until at least 2017
(due to Ubuntu 12.04 LTS), and then it will need to be deprecated for a
couple more years before we can get rid of it entirely.  Therefore, I
think it's premature to emphasize the transient nature of the "..."
marker.  Like it or not, we'll probably be stuck with it for 7 or 8
years.

Does that make sense?

    Regards,
      Mark

Re: Adding to the end of the load path

[Ludovic Courtès]

Mark H Weaver <mhw@netris.org> skribis:

>> However, I can live with that, but maybe we can have it both
>> ways:
>>
>> - Add the _SUFFIX environment variables, making it clear in the docs
>>   that they are supported only from Guile 2.0.7 onward.
>
> Yes, I agree this is a good idea.

But then, what would happen when GUILE_LOAD_PATH_SUFFIX is present *and*
GUILE_LOAD_PATH contains ‘...’?

Seems like a can of worms to me.

Ludo’.

Re: Adding to the end of the load path

[Noah Lavine]

[-- Attachment #1: Type: text/plain, Size: 4558 bytes --]

Hello,

This is coming late in the discussion, but I'd like to suggest a somewhat
different approach. I hope this is helpful.

It seems to me that in the end, the module-lookup system may need to be
more complex than having regular and suffix lookup paths. For instance, one
of the big concerns here was reducing the number of stat() calls. What if
we know that some load directories only contain certain modules? We might
want a way for the user to say "all the (foo ...) modules live in ~/foo,
but you don't have to look for any other modules there". Or what if I want
to use a backup version of a module that's also included in the regular
Guile distribution, because I haven't ported my code to a new version yet
(yes, I should use module versions, but I don't)? There might be more
complicated scenarios too.

Given that the module-lookup system is fundamentally complicated, I'm going
to suggest that we *don't* try to make it all configurable by environment
variables. If people want full control of lookups, they can write a
site-wide Guile init file or a personal ~/.guile. The regular load-path
would still be part of the system, and that would be configurable by an
environment variable, so legacy setups would continue to work. However, I'd
be happy saying that if you wanted to access all of the functionality, you
need to write Scheme code. Let's start by adding Scheme interfaces to the
functionality we want, and maybe not worry about environment variables if
they're complicated.

What do you think?
Noah



On Thu, Nov 15, 2012 at 5:44 PM, Mark H Weaver <mhw@netris.org> wrote:

> Hi Andreas,
>
> Andreas Rottmann <a.rottmann@gmx.at> writes:
>
> > ludo@gnu.org (Ludovic Courtès) writes:
> >
> >> I pretty much like Mark’s suggestion of using ‘...’ as a special marker,
> >> even though that’s a valid file name.
> >>
> > Well, there's a workaround -- specifying "./..." as an "escape sequence"
> > for "..." if you really need to have a three-dot relative directory in
> > the path.
> >
> >> How would that work for you?
> >>
> > I would like the approach using separate _SUFFIX variables better, as it
> > doesn't have this special case.
>
> As I wrote earlier, I certainly agree that the _SUFFIX approach is
> cleaner.  Unfortunately, we need a solution that will work nicely with
> earlier versions of Guile.
>
> > While I don't think the special case
> > will be a problem for a user setting the environment variables
> > themselves, if you want to set them programatically, you now have to
> > consider treat "..." specially, escaping it like mentioned above, to be
> > general.
>
> Note that PATH-style variables are already not general, because they
> provide no way to include filenames containing ':' (a colon).
>
> In general, it's best to avoid setting GUILE_LOAD_PATH programmatically,
> because it will affect more than just the instance of Guile you
> intended; it will also affect any subprocesses that use Guile.  It's
> better to use -L which is fully general without any special cases, or to
> modify %load-path within the program itself.
>
> > However, I can live with that, but maybe we can have it both
> > ways:
> >
> > - Add the _SUFFIX environment variables, making it clear in the docs
> >   that they are supported only from Guile 2.0.7 onward.
>
> Yes, I agree this is a good idea.
>
> > - Additonally, add "..." as a special marker, but mention it is just
> >   provided to support Guile < 2.0.7, and should not be used in code that
> >   needs to depend on Guile 2.0.7 or newer for other reasons
> >   (e.g. reliance on another added feature or significant bugfix).
>
> Again, these environment variables are not specific to any particular
> piece of code.  They are usually associated with an entire user account.
>
> > I'm not sure how the deprecation strategy is employed exactly, but we
> > could mark the "..." feature as deprecated right away, or at least in
> > master, and remove it in 2.2 or 2.4.
>
> I don't think we can mark it deprecated until versions of Guile older
> than 2.0.7 have become very rare, which won't be until at least 2017
> (due to Ubuntu 12.04 LTS), and then it will need to be deprecated for a
> couple more years before we can get rid of it entirely.  Therefore, I
> think it's premature to emphasize the transient nature of the "..."
> marker.  Like it or not, we'll probably be stuck with it for 7 or 8
> years.
>
> Does that make sense?
>
>     Regards,
>       Mark
>
>

[-- Attachment #2: Type: text/html, Size: 5544 bytes --]

Re: Adding to the end of the load path

[Noah Lavine]

[-- Attachment #1: Type: text/plain, Size: 5464 bytes --]

And replying to myself, I remembered something else that had been in the
back of my mind: a while ago on this list, there was discussion of bundling
some modules with libguile, perhaps as static C arrays. This could make it
easier to embed Guile, as a program could embed all the modules it needs
and not have to worry about load-paths.

However, this is another extension to the module-lookup system which really
cannot be well-specified by environment variables. This is more evidence
for my theory that module-lookup is fundamentally too complicated to be
conveniently represented by environment variables.

Of course, I would be very happy to be proven wrong,
Noah



On Thu, Nov 15, 2012 at 7:10 PM, Noah Lavine <noah.b.lavine@gmail.com>wrote:

> Hello,
>
> This is coming late in the discussion, but I'd like to suggest a somewhat
> different approach. I hope this is helpful.
>
> It seems to me that in the end, the module-lookup system may need to be
> more complex than having regular and suffix lookup paths. For instance, one
> of the big concerns here was reducing the number of stat() calls. What if
> we know that some load directories only contain certain modules? We might
> want a way for the user to say "all the (foo ...) modules live in ~/foo,
> but you don't have to look for any other modules there". Or what if I want
> to use a backup version of a module that's also included in the regular
> Guile distribution, because I haven't ported my code to a new version yet
> (yes, I should use module versions, but I don't)? There might be more
> complicated scenarios too.
>
> Given that the module-lookup system is fundamentally complicated, I'm
> going to suggest that we *don't* try to make it all configurable by
> environment variables. If people want full control of lookups, they can
> write a site-wide Guile init file or a personal ~/.guile. The regular
> load-path would still be part of the system, and that would be configurable
> by an environment variable, so legacy setups would continue to work.
> However, I'd be happy saying that if you wanted to access all of the
> functionality, you need to write Scheme code. Let's start by adding Scheme
> interfaces to the functionality we want, and maybe not worry about
> environment variables if they're complicated.
>
> What do you think?
> Noah
>
>
>
> On Thu, Nov 15, 2012 at 5:44 PM, Mark H Weaver <mhw@netris.org> wrote:
>
>> Hi Andreas,
>>
>> Andreas Rottmann <a.rottmann@gmx.at> writes:
>>
>> > ludo@gnu.org (Ludovic Courtès) writes:
>> >
>> >> I pretty much like Mark’s suggestion of using ‘...’ as a special
>> marker,
>> >> even though that’s a valid file name.
>> >>
>> > Well, there's a workaround -- specifying "./..." as an "escape sequence"
>> > for "..." if you really need to have a three-dot relative directory in
>> > the path.
>> >
>> >> How would that work for you?
>> >>
>> > I would like the approach using separate _SUFFIX variables better, as it
>> > doesn't have this special case.
>>
>> As I wrote earlier, I certainly agree that the _SUFFIX approach is
>> cleaner.  Unfortunately, we need a solution that will work nicely with
>> earlier versions of Guile.
>>
>> > While I don't think the special case
>> > will be a problem for a user setting the environment variables
>> > themselves, if you want to set them programatically, you now have to
>> > consider treat "..." specially, escaping it like mentioned above, to be
>> > general.
>>
>> Note that PATH-style variables are already not general, because they
>> provide no way to include filenames containing ':' (a colon).
>>
>> In general, it's best to avoid setting GUILE_LOAD_PATH programmatically,
>> because it will affect more than just the instance of Guile you
>> intended; it will also affect any subprocesses that use Guile.  It's
>> better to use -L which is fully general without any special cases, or to
>> modify %load-path within the program itself.
>>
>> > However, I can live with that, but maybe we can have it both
>> > ways:
>> >
>> > - Add the _SUFFIX environment variables, making it clear in the docs
>> >   that they are supported only from Guile 2.0.7 onward.
>>
>> Yes, I agree this is a good idea.
>>
>> > - Additonally, add "..." as a special marker, but mention it is just
>> >   provided to support Guile < 2.0.7, and should not be used in code that
>> >   needs to depend on Guile 2.0.7 or newer for other reasons
>> >   (e.g. reliance on another added feature or significant bugfix).
>>
>> Again, these environment variables are not specific to any particular
>> piece of code.  They are usually associated with an entire user account.
>>
>> > I'm not sure how the deprecation strategy is employed exactly, but we
>> > could mark the "..." feature as deprecated right away, or at least in
>> > master, and remove it in 2.2 or 2.4.
>>
>> I don't think we can mark it deprecated until versions of Guile older
>> than 2.0.7 have become very rare, which won't be until at least 2017
>> (due to Ubuntu 12.04 LTS), and then it will need to be deprecated for a
>> couple more years before we can get rid of it entirely.  Therefore, I
>> think it's premature to emphasize the transient nature of the "..."
>> marker.  Like it or not, we'll probably be stuck with it for 7 or 8
>> years.
>>
>> Does that make sense?
>>
>>     Regards,
>>       Mark
>>
>>
>

[-- Attachment #2: Type: text/html, Size: 6743 bytes --]

Re: Adding to the end of the load path

[Bruce Korb]

On 11/15/12 16:10, Noah Lavine wrote:
> Given that the module-lookup system is fundamentally complicated, I'm going to
> suggest that we *don't* try to make it all configurable by environment variables.
> If people want full control of lookups, they can write a site-wide Guile init
> file or a personal ~/.guile. The regular load-path would still be part of the
> system, and that would be configurable by an environment variable, so legacy
> setups would continue to work. However, I'd be happy saying that if you wanted
> to access all of the functionality, you need to write Scheme code. Let's start
> by adding Scheme interfaces to the functionality we want, and maybe not worry
> about environment variables if they're complicated.
> 
> What do you think?

Yes!!  With that, can the LD_LIBRARY_PATH be freed from fiddling?

Re: Adding to the end of the load path

[Mark H Weaver]

Hi Noah,

Noah Lavine <noah.b.lavine@gmail.com> writes:
> Given that the module-lookup system is fundamentally complicated, I'm
> going to suggest that we *don't* try to make it all configurable by
> environment variables. If people want full control of lookups, they
> can write a site-wide Guile init file or a personal ~/.guile.

In general, I think the idea of requiring people to write scheme code to
manipulate %load-path (and other settings) is a fine approach.  Maybe
you're right that this is better than adding a bunch of new environment
variables.

However, neither init.scm nor ~/.guile is sufficient for this job.
init.scm is site-wide, and generally only editable by root, and ~/.guile
is only run by interactive REPL sessions.  So to do as you suggest, we'd
need to add another user-specific file that is read when initializing
guile, even for non-interactive sessions.

Also, note that this still doesn't solve our immediate problem regarding
Guildhall and SRFIs in a backward-compatible way, so we still need to
support the "..." marker for the next 7-8 years, unless someone has a
better suggestion.

   Regards,
     Mark

Re: Adding to the end of the load path

[Noah Lavine]

[-- Attachment #1: Type: text/plain, Size: 1531 bytes --]

On Fri, Nov 16, 2012 at 1:52 PM, Mark H Weaver <mhw@netris.org> wrote:

> Hi Noah,
>

Hello,


> In general, I think the idea of requiring people to write scheme code to
> manipulate %load-path (and other settings) is a fine approach.  Maybe
> you're right that this is better than adding a bunch of new environment
> variables.


> However, neither init.scm nor ~/.guile is sufficient for this job.
> init.scm is site-wide, and generally only editable by root, and ~/.guile
> is only run by interactive REPL sessions.  So to do as you suggest, we'd
> need to add another user-specific file that is read when initializing
> guile, even for non-interactive sessions.
>

Ah, I didn't realize that was an issue. I was modeling this on what Emacs
does, but it doesn't run in batch mode very much. Three configuration files
with different meanings seems like a lot, but there's no other way that
preserves backwards compatibility. Maybe we could use the $XDG_CONFIG
directory for it (not that I like their default value).


> Also, note that this still doesn't solve our immediate problem regarding
> Guildhall and SRFIs in a backward-compatible way, so we still need to
> support the "..." marker for the next 7-8 years, unless someone has a
> better suggestion.
>

I see your point, but leaving it like this doesn't fix anything that isn't
already broken; is that right? If so, I think we could justify saying that
people need to upgrade to get the new behavior, especially if the
complexity of supporting old versions is high.

Noah

[-- Attachment #2: Type: text/html, Size: 2300 bytes --]

[PATCH] Add parse-path-with-ellipsis, and use it for GUILE_LOAD_PATH et al

[Mark H Weaver]

[-- Attachment #1: Type: text/plain, Size: 319 bytes --]

Hi Ludovic,

ludo@gnu.org (Ludovic Courtès) writes:
> I pretty much like Mark’s suggestion of using ‘...’ as a special marker,
> even though that’s a valid file name.

Here's a patch to implement the "..." special marker.
It would be good to have this in 2.0.7.

What do you think?

      Mark



[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: [PATCH] Add parse-path-with-ellipsis, and use it for GUILE_LOAD_PATH et al --]
[-- Type: text/x-diff, Size: 3958 bytes --]

From 4a78f4a638334a5bd8eb08308891b541bbde9b1e Mon Sep 17 00:00:00 2001
From: Mark H Weaver <mhw@netris.org>
Date: Wed, 28 Nov 2012 18:01:35 -0500
Subject: [PATCH] Add parse-path-with-ellipsis, and use it for GUILE_LOAD_PATH
 et al.

* libguile/load.c (scm_parse_path_with_ellipsis): New procedure.
  (scm_init_load_path): Use 'scm_parse_path_with_ellipsis' to
  handle GUILE_LOAD_PATH and GUILE_LOAD_COMPILED_PATH.

* libguile/load.h (scm_parse_path_with_ellipsis): Add prototype.

* doc/ref/api-evaluation.texi (Load Paths): Add docs.
---
 doc/ref/api-evaluation.texi |    9 +++++++++
 libguile/load.c             |   31 +++++++++++++++++++++++++++++--
 libguile/load.h             |    1 +
 3 files changed, 39 insertions(+), 2 deletions(-)

diff --git a/doc/ref/api-evaluation.texi b/doc/ref/api-evaluation.texi
index 37e41e1..6a442c7 100644
--- a/doc/ref/api-evaluation.texi
+++ b/doc/ref/api-evaluation.texi
@@ -943,6 +943,15 @@ a list and return the resulting list with @var{tail} appended. If
 @var{path} is @code{#f}, @var{tail} is returned.
 @end deffn
 
+@deffn {Scheme Procedure} parse-path-with-ellipsis path base
+@deffnx {C Function} scm_parse_path_with_ellipsis (path, base)
+Parse @var{path}, which is expected to be a colon-separated string, into
+a list and return the resulting list with @var{base} (a list) spliced in
+place of the @code{...} path component, if present, or else @var{base}
+is added to the end.  If @var{path} is @code{#f}, @var{base} is
+returned.
+@end deffn
+
 @deffn {Scheme Procedure} search-path path filename [extensions [require-exts?]]
 @deffnx {C Function} scm_search_path (path, filename, rest)
 Search @var{path} for a directory containing a file named
diff --git a/libguile/load.c b/libguile/load.c
index af2ca45..76bbd83 100644
--- a/libguile/load.c
+++ b/libguile/load.c
@@ -243,6 +243,33 @@ SCM_DEFINE (scm_parse_path, "parse-path", 1, 1, 0,
 }
 #undef FUNC_NAME
 
+SCM_DEFINE (scm_parse_path_with_ellipsis, "parse-path-with-ellipsis", 2, 0, 0,
+            (SCM path, SCM base),
+	    "Parse @var{path}, which is expected to be a colon-separated\n"
+	    "string, into a list and return the resulting list with\n"
+	    "@var{base} (a list) spliced in place of the @code{...} path\n"
+            "component, if present, or else @var{base} is added to the end.\n"
+            "If @var{path} is @code{#f}, @var{base} is returned.")
+#define FUNC_NAME s_scm_parse_path_with_ellipsis
+{
+  SCM ellipsis = scm_from_latin1_string ("...");
+  SCM lst = scm_parse_path (path, SCM_EOL);
+  SCM walk = lst;
+  SCM *prev = &lst;
+
+  while (!scm_is_null (walk) &&
+         scm_is_false (scm_equal_p (scm_car (walk), ellipsis)))
+    {
+      prev = SCM_CDRLOC (walk);
+      walk = *prev;
+    }
+  *prev = scm_is_null (walk)
+    ? base
+    : scm_append (scm_list_2 (base, scm_cdr (walk)));
+  return lst;
+}
+#undef FUNC_NAME
+
 
 /* Initialize the global variable %load-path, given the value of the
    SCM_SITE_DIR and SCM_LIBRARY_DIR preprocessor symbols and the
@@ -316,11 +343,11 @@ scm_init_load_path ()
 
   env = getenv ("GUILE_LOAD_PATH");
   if (env)
-    path = scm_parse_path (scm_from_locale_string (env), path);
+    path = scm_parse_path_with_ellipsis (scm_from_locale_string (env), path);
 
   env = getenv ("GUILE_LOAD_COMPILED_PATH");
   if (env)
-    cpath = scm_parse_path (scm_from_locale_string (env), cpath);
+    cpath = scm_parse_path_with_ellipsis (scm_from_locale_string (env), cpath);
 
   *scm_loc_load_path = path;
   *scm_loc_load_compiled_path = cpath;
diff --git a/libguile/load.h b/libguile/load.h
index 0bddac2..698bbaf 100644
--- a/libguile/load.h
+++ b/libguile/load.h
@@ -27,6 +27,7 @@
 
 \f
 SCM_API SCM scm_parse_path (SCM path, SCM tail);
+SCM_API SCM scm_parse_path_with_ellipsis (SCM path, SCM base);
 SCM_API SCM scm_primitive_load (SCM filename);
 SCM_API SCM scm_c_primitive_load (const char *filename);
 SCM_API SCM scm_sys_package_data_dir (void);
-- 
1.7.10.4

Re: [PATCH] Add parse-path-with-ellipsis, and use it for GUILE_LOAD_PATH et al

[Ludovic Courtès]

Hi Mark,

Mark H Weaver <mhw@netris.org> skribis:

> From 4a78f4a638334a5bd8eb08308891b541bbde9b1e Mon Sep 17 00:00:00 2001
> From: Mark H Weaver <mhw@netris.org>
> Date: Wed, 28 Nov 2012 18:01:35 -0500
> Subject: [PATCH] Add parse-path-with-ellipsis, and use it for GUILE_LOAD_PATH
>  et al.
>
> * libguile/load.c (scm_parse_path_with_ellipsis): New procedure.
>   (scm_init_load_path): Use 'scm_parse_path_with_ellipsis' to
>   handle GUILE_LOAD_PATH and GUILE_LOAD_COMPILED_PATH.
>
> * libguile/load.h (scm_parse_path_with_ellipsis): Add prototype.
>
> * doc/ref/api-evaluation.texi (Load Paths): Add docs.
> ---
>  doc/ref/api-evaluation.texi |    9 +++++++++
>  libguile/load.c             |   31 +++++++++++++++++++++++++++++--
>  libguile/load.h             |    1 +
>  3 files changed, 39 insertions(+), 2 deletions(-)

[...]

> +a list and return the resulting list with @var{base} (a list) spliced in
> +place of the @code{...} path component, if present, or else @var{base}
> +is added to the end.  If @var{path} is @code{#f}, @var{base} is
> +returned.

Looks clean to me.

> +#define FUNC_NAME s_scm_parse_path_with_ellipsis
> +{
> +  SCM ellipsis = scm_from_latin1_string ("...");

Use ‘SCM_SYMBOL’ instead.

Modulo that, feel free to commit.

Thanks for working on this!

Ludo’.

PS: I’ve started updating NEWS.

Re: [PATCH] Add parse-path-with-ellipsis, and use it for GUILE_LOAD_PATH et al

[Mark H Weaver]

[-- Attachment #1: Type: text/plain, Size: 600 bytes --]

Hi Ludovic,

ludo@gnu.org (Ludovic Courtès) writes:
> Mark H Weaver <mhw@netris.org> skribis:
>
>> +#define FUNC_NAME s_scm_parse_path_with_ellipsis
>> +{
>> +  SCM ellipsis = scm_from_latin1_string ("...");
>
> Use ‘SCM_SYMBOL’ instead.

It's a string, not a symbol.  I changed it to a global static SCM
initialized by 'scm_init_load'.

I've attached a revised patch that also does a much better job of
updating the docs.  I also noticed that the documentation of the default
load path did not match reality.

Comments and suggestions welcome.

    Thanks,
      Mark



[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: [PATCH] Add parse-path-with-ellipsis, and use it for GUILE_LOAD_PATH et al --]
[-- Type: text/x-diff, Size: 8933 bytes --]

From bd31bce6ac5df7e45d0ec802d9d0738cbc32d9bf Mon Sep 17 00:00:00 2001
From: Mark H Weaver <mhw@netris.org>
Date: Wed, 28 Nov 2012 18:01:35 -0500
Subject: [PATCH] Add parse-path-with-ellipsis, and use it for GUILE_LOAD_PATH
 et al.

* libguile/load.c (scm_ellipsis): New Variable.
  (scm_parse_path_with_ellipsis): New procedure.
  (scm_init_load): Initialize 'scm_ellipsis'.
  (scm_init_load_path): Use 'scm_parse_path_with_ellipsis' to
  handle GUILE_LOAD_PATH and GUILE_LOAD_COMPILED_PATH.

* libguile/load.h (scm_parse_path_with_ellipsis): Add prototype.

* doc/ref/guile-invoke.texi (Environment Variables):
  doc/ref/api-evaluation.texi (Load Paths): Add documentation.
  Correct description of default load path to reflect reality.
  Remove 'GUILE_LOAD_PATH' from the concept index; it is already
  in the variable index.  Add cross references between these two
  sections of the manual.
---
 doc/ref/api-evaluation.texi |   27 ++++++++++++++++++++-------
 doc/ref/guile-invoke.texi   |   25 ++++++++++++++++---------
 libguile/load.c             |   35 +++++++++++++++++++++++++++++++++--
 libguile/load.h             |    1 +
 4 files changed, 70 insertions(+), 18 deletions(-)

diff --git a/doc/ref/api-evaluation.texi b/doc/ref/api-evaluation.texi
index 37e41e1..2e5a3d2 100644
--- a/doc/ref/api-evaluation.texi
+++ b/doc/ref/api-evaluation.texi
@@ -838,14 +838,16 @@ The procedure in the previous section look for Scheme code in the file
 system at specific location.  Guile also has some procedures to search
 the load path for code.
 
-@cindex @env{GUILE_LOAD_PATH}
 @defvar %load-path
 List of directories which should be searched for Scheme modules and
-libraries.  @code{%load-path} is initialized when Guile starts up to
-@code{(list (%site-dir) (%library-dir) (%package-data-dir))}, prepended
-with the contents of the @env{GUILE_LOAD_PATH} environment variable, if
-it is set.  @xref{Build Config}, for more on @code{%site-dir} and
-related procedures.
+libraries.  When Guile starts up, @code{%load-path} is initialized to
+the default load path @code{(list (%library-dir) (%site-dir)
+(%global-site-dir) (%package-data-dir))}.  The @env{GUILE_LOAD_PATH}
+environment variable can be used to prepend or append additional
+directories (@pxref{Environment Variables}).
+
+@xref{Build Config}, for more on @code{%site-dir} and related
+procedures.
 @end defvar
 
 @deffn {Scheme Procedure} load-from-path filename
@@ -913,7 +915,9 @@ using @code{load-compiled}.
 @defvar %load-compiled-path
 Like @code{%load-path}, but for compiled files.  By default, this path
 has two entries: one for compiled files from Guile itself, and one for
-site packages.
+site packages.  The @env{GUILE_LOAD_COMPILED_PATH} environment variable
+can be used to prepend or append additional directories
+(@pxref{Environment Variables}).
 @end defvar
 
 When @code{primitive-load-path} searches the @code{%load-compiled-path}
@@ -943,6 +947,15 @@ a list and return the resulting list with @var{tail} appended. If
 @var{path} is @code{#f}, @var{tail} is returned.
 @end deffn
 
+@deffn {Scheme Procedure} parse-path-with-ellipsis path base
+@deffnx {C Function} scm_parse_path_with_ellipsis (path, base)
+Parse @var{path}, which is expected to be a colon-separated string, into
+a list and return the resulting list with @var{base} (a list) spliced in
+place of the @code{...} path component, if present, or else @var{base}
+is added to the end.  If @var{path} is @code{#f}, @var{base} is
+returned.
+@end deffn
+
 @deffn {Scheme Procedure} search-path path filename [extensions [require-exts?]]
 @deffnx {C Function} scm_search_path (path, filename, rest)
 Search @var{path} for a directory containing a file named
diff --git a/doc/ref/guile-invoke.texi b/doc/ref/guile-invoke.texi
index 08c1698..5a9a3f7 100644
--- a/doc/ref/guile-invoke.texi
+++ b/doc/ref/guile-invoke.texi
@@ -295,8 +295,10 @@ variable.  By default, the history file is @file{$HOME/.guile_history}.
 @vindex GUILE_LOAD_COMPILED_PATH
 This variable may be used to augment the path that is searched for
 compiled Scheme files (@file{.go} files) when loading.  Its value should
-be a colon-separated list of directories, which will be prefixed to the
-value of the default search path stored in @code{%load-compiled-path}.
+be a colon-separated list of directories.  If it contains the special
+path component @code{...} (ellipsis), then the default path is put in
+place of the ellipsis, otherwise the default path is placed at the end.
+The result is stored in @code{%load-compiled-path} (@pxref{Load Paths}).
 
 Here is an example using the Bash shell that adds the current directory,
 @file{.}, and the relative directory @file{../my-library} to
@@ -312,18 +314,23 @@ $ guile -c '(display %load-compiled-path) (newline)'
 @vindex GUILE_LOAD_PATH
 This variable may be used to augment the path that is searched for
 Scheme files when loading.  Its value should be a colon-separated list
-of directories, which will be prefixed to the value of the default
-search path stored in @code{%load-path}.
+of directories.  If it contains the special path component @code{...}
+(ellipsis), then the default path is put in place of the ellipsis,
+otherwise the default path is placed at the end.  The result is stored
+in @code{%load-path} (@pxref{Load Paths}).
 
-Here is an example using the Bash shell that adds the current directory
-and the parent of the current directory to @code{%load-path}:
+Here is an example using the Bash shell that prepends the current
+directory to @code{%load-path}, and adds the relative directory
+@file{../srfi} to the end:
 
 @example
-$ env GUILE_LOAD_PATH=".:.." \
+$ env GUILE_LOAD_PATH=".:...:../srfi" \
 guile -c '(display %load-path) (newline)'
-(. .. /usr/local/share/guile/2.0 \
+(. /usr/local/share/guile/2.0 \
 /usr/local/share/guile/site/2.0 \
-/usr/local/share/guile/site /usr/local/share/guile)
+/usr/local/share/guile/site \
+/usr/local/share/guile \
+../srfi)
 @end example
 
 (Note: The line breaks, above, are for documentation purposes only, and
diff --git a/libguile/load.c b/libguile/load.c
index af2ca45..723f3fd 100644
--- a/libguile/load.c
+++ b/libguile/load.c
@@ -221,6 +221,9 @@ static SCM *scm_loc_fresh_auto_compile;
 /* The fallback path for auto-compilation */
 static SCM *scm_loc_compile_fallback_path;
 
+/* Ellipsis: "..." */
+static SCM scm_ellipsis;
+
 SCM_DEFINE (scm_parse_path, "parse-path", 1, 1, 0, 
             (SCM path, SCM tail),
 	    "Parse @var{path}, which is expected to be a colon-separated\n"
@@ -243,6 +246,32 @@ SCM_DEFINE (scm_parse_path, "parse-path", 1, 1, 0,
 }
 #undef FUNC_NAME
 
+SCM_DEFINE (scm_parse_path_with_ellipsis, "parse-path-with-ellipsis", 2, 0, 0,
+            (SCM path, SCM base),
+	    "Parse @var{path}, which is expected to be a colon-separated\n"
+	    "string, into a list and return the resulting list with\n"
+	    "@var{base} (a list) spliced in place of the @code{...} path\n"
+            "component, if present, or else @var{base} is added to the end.\n"
+            "If @var{path} is @code{#f}, @var{base} is returned.")
+#define FUNC_NAME s_scm_parse_path_with_ellipsis
+{
+  SCM lst = scm_parse_path (path, SCM_EOL);
+  SCM walk = lst;
+  SCM *prev = &lst;
+
+  while (!scm_is_null (walk) &&
+         scm_is_false (scm_equal_p (scm_car (walk), scm_ellipsis)))
+    {
+      prev = SCM_CDRLOC (walk);
+      walk = *prev;
+    }
+  *prev = scm_is_null (walk)
+    ? base
+    : scm_append (scm_list_2 (base, scm_cdr (walk)));
+  return lst;
+}
+#undef FUNC_NAME
+
 
 /* Initialize the global variable %load-path, given the value of the
    SCM_SITE_DIR and SCM_LIBRARY_DIR preprocessor symbols and the
@@ -316,11 +345,11 @@ scm_init_load_path ()
 
   env = getenv ("GUILE_LOAD_PATH");
   if (env)
-    path = scm_parse_path (scm_from_locale_string (env), path);
+    path = scm_parse_path_with_ellipsis (scm_from_locale_string (env), path);
 
   env = getenv ("GUILE_LOAD_COMPILED_PATH");
   if (env)
-    cpath = scm_parse_path (scm_from_locale_string (env), cpath);
+    cpath = scm_parse_path_with_ellipsis (scm_from_locale_string (env), cpath);
 
   *scm_loc_load_path = path;
   *scm_loc_load_compiled_path = cpath;
@@ -1047,6 +1076,8 @@ scm_init_load ()
   scm_loc_fresh_auto_compile
     = SCM_VARIABLE_LOC (scm_c_define ("%fresh-auto-compile", SCM_BOOL_F));
 
+  scm_ellipsis = scm_from_latin1_string ("...");
+
   the_reader = scm_make_fluid_with_default (SCM_BOOL_F);
   scm_c_define("current-reader", the_reader);
 
diff --git a/libguile/load.h b/libguile/load.h
index 0bddac2..698bbaf 100644
--- a/libguile/load.h
+++ b/libguile/load.h
@@ -27,6 +27,7 @@
 
 \f
 SCM_API SCM scm_parse_path (SCM path, SCM tail);
+SCM_API SCM scm_parse_path_with_ellipsis (SCM path, SCM base);
 SCM_API SCM scm_primitive_load (SCM filename);
 SCM_API SCM scm_c_primitive_load (const char *filename);
 SCM_API SCM scm_sys_package_data_dir (void);
-- 
1.7.10.4

Re: [PATCH] Add parse-path-with-ellipsis, and use it for GUILE_LOAD_PATH et al

[Ludovic Courtès]

Hi Mark!

Mark H Weaver <mhw@netris.org> skribis:

> Hi Ludovic,
>
> ludo@gnu.org (Ludovic Courtès) writes:
>> Mark H Weaver <mhw@netris.org> skribis:
>>
>>> +#define FUNC_NAME s_scm_parse_path_with_ellipsis
>>> +{
>>> +  SCM ellipsis = scm_from_latin1_string ("...");
>>
>> Use ‘SCM_SYMBOL’ instead.
>
> It's a string, not a symbol.

Oops, right.  Then there’s SCM_IMMUTABLE_STRING.  :-)

> I've attached a revised patch that also does a much better job of
> updating the docs.  I also noticed that the documentation of the default
> load path did not match reality.

Excellent, looks great to me.

If everything goes well, we may be able to tag tonight.  WDYT?

Thanks,
Ludo’.