l...@gnu.org (Ludovic Courtès) writes: > Hi! > > Sorry for the delay. > > Andreas Rottmann <a.rottm...@gmx.at> skribis: > >> Ian Price <ianpric...@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/>