emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: relative load-file


From: Rocky Bernstein
Subject: Re: relative load-file
Date: Wed, 18 Nov 2009 08:39:11 -0500



On Wed, Nov 18, 2009 at 7:10 AM, Richard Stallman <address@hidden> 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.

 


reply via email to

[Prev in Thread] Current Thread [Next in Thread]