Re: relative load-file

[Rocky Bernstein <rocky@gnu.org>]

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

On Wed, Nov 18, 2009 at 7:10 AM, Richard Stallman <rms@gnu.org> wrote:

>    require-relative allows me to load or eval and test any one of the
> subparts
>    without mucking with the load path yet ensure I am getting the right
> files
>    loaded.
>
> I see.  It is for when the program is NOT installed.
>

I am not sure you see. For me, installation is kind of a sketchy thing -
several different versions of a program may be "installed".  Furthermore,
testing, debugging, or running subparts in one of those "installations" for
me is no different than testing when the program is "not installed".

So for me, one thing that make a programming development agile is reducing
the overhead and distinction of this "install" step.


>
> But suppose it were enough had to add one parent directory to
> load-path, for instance ~/elisp, and you put all your directories of
> Lisp programs under that.  Suppose that you specify `foo/bar', and it
> would find that under ~/elisp.
>

load-path may be fine for finding initially where to get a package. However
it is cumbersome and unnecessary for referring to the submodules of a
program from inside the source code.

In compiled languages this distinction is pretty clear. For example in C one
doesn't confuse PATH with INCLUDE_PATH. And note that I can write #include
"./stidio.h" as well as #include <stdio.h> which are very different things;
both are equally valid and used.


> Would that be easy and reliable enough?
>

Well, let's check out the possibilities.

Do I write my program with subparts to assume that "." is first in the load
path? I not, and I just assume "." is first, then my program can break *at
run time *if that assumption is not valid.

Okay, so now suppose I check, and possibly add something like "." (And here
__FILE__ not "." would the most reliable thing to use) and finally remove it
someplace in the code where I know I don't need to load any more files. Now
my program is more clumsy. Furthermore it is possible I might not get those
stereotypical steps right. And I suppose I need to worry about error cases:
if load-path is added and some error condition is raised, I should make sure
that my addition is removed.

For these two reasons it sounds like it would be good to write a package to
do these steps.  But then, why do I need load-path at all? For internal
module loading, what *benefit* is it serving?

And so  that's what I've done. What makes this a little unreliable right now
is the fact that there isn't a solid definition of __FILE__, though the
package I guess is providing one which over time will get better.

Since people's heads explode at the idea of adding __FILE__ because as has
been noted there are some situations where it makes no sense, suppose
load-file-name is *extended* to include more cases.

load-file-name already returns nil in some situations, so I guess people may
be less put off it it returns nil is a couple fewer cases such being called
from eval-buffer.

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