From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Rocky Bernstein Newsgroups: gmane.emacs.devel Subject: Re: relative load-file Date: Sat, 14 Nov 2009 10:44:01 -0500 Message-ID: <6cd6de210911140744t75b84417udfa6921cc8fe424f@mail.gmail.com> References: <6cd6de210911110901v24307163i253e69e89c72c9e@mail.gmail.com> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=001636b2bc833daad1047856a5a1 X-Trace: ger.gmane.org 1258213463 10931 80.91.229.12 (14 Nov 2009 15:44:23 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 14 Nov 2009 15:44:23 +0000 (UTC) Cc: emacs-devel@gnu.org To: rms@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Nov 14 16:44:16 2009 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1N9KnP-0006Q0-9y for ged-emacs-devel@m.gmane.org; Sat, 14 Nov 2009 16:44:15 +0100 Original-Received: from localhost ([127.0.0.1]:34642 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1N9KnO-00066A-Rf for ged-emacs-devel@m.gmane.org; Sat, 14 Nov 2009 10:44:14 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1N9KnJ-00064E-V8 for emacs-devel@gnu.org; Sat, 14 Nov 2009 10:44:10 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1N9KnF-00060z-Vi for emacs-devel@gnu.org; Sat, 14 Nov 2009 10:44:09 -0500 Original-Received: from [199.232.76.173] (port=55602 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1N9KnF-00060w-Rh for emacs-devel@gnu.org; Sat, 14 Nov 2009 10:44:05 -0500 Original-Received: from mail-px0-f183.google.com ([209.85.216.183]:45528) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1N9KnD-00061x-4n; Sat, 14 Nov 2009 10:44:03 -0500 Original-Received: by pxi13 with SMTP id 13so490157pxi.24 for ; Sat, 14 Nov 2009 07:44:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type; bh=haxQoKGdMTf6LPkns8fOBJBjw7cH//K3470kCbIR2zE=; b=fn+IZMIGY7KOLAQ7swnLkZRYUkJfJZebjzjhJCK3bYeqhtRBaNdche/zDWj3Vf3Qw+ YMQl256S5N/od0mh7UXFZQ5FDzO3rCoC8dJFVJiEjn8z5vB3RKoKvN5cXUyvXW5/Rykr 79iDVmn1XfcJNxKOaob3Wdkr9GC08RmaMA6Iw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; b=wrimFQvOqajoJwJIwN0DtDZLG57BTB3qrd9bItJAcwUOIf5adL//Dv+0Pof+GooxNm m+3VaoscK3Z80Vjxb2zWUtfyV1em/k5W5dDTOD391VNFxny+Fq7dRNdh/mGO1kp4evsM u1yoQbQwfYSG542Up+PPq+vz1B117bk6s5a5g= Original-Received: by 10.142.55.11 with SMTP id d11mr481991wfa.334.1258213441644; Sat, 14 Nov 2009 07:44:01 -0800 (PST) In-Reply-To: X-Google-Sender-Auth: 28671207a65b1071 X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6 (newer, 2) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:116981 Archived-At: --001636b2bc833daad1047856a5a1 Content-Type: text/plain; charset=ISO-8859-1 On Sat, Nov 14, 2009 at 6:24 AM, Richard Stallman wrote: > The basic idea of `require' is that you specify a feature which gets > found through a search of all libraries. The idea is that these are > general features which anything might want to use. > Require has* two* parts which are distinct. One part has the searching for a file in it. The other part is the conditional load depending on whether or not a feature has already been loaded > You want something different: > > That is, one wants to > load an Emacs Lisp file relative the file that issues the load which is > often in the same directory or a nearby directory. > > It seems to me that this is useful only for loading other parts of one > single multi-file program. > No. A large modular program can be composed of other smaller modular programs. In theory, one can package each file or subsets of files as their own package, but often those smaller modules may be custom enough that it doesn't make sense to do so. Or at least not initially. However when developing or working on the program, one wants may want to work with each of the subparts independently. Here's an example that no doubt you are familiar with: a compile has a parser, code generator and code optimizer. In a well-written modular compiler one may want to work on and test the parser as an independent unit even though I'm not sure you would want to package the front-end for a specific language independently. So what require-relative and load-relative allow one to do is create these little independent units without the overhead of using a more elaborate packaging systems. require/provide in fact does this too. However it pulls in file searching which is not desired here. Instead, what we want to do in a program built of custom modules but is just change how the file searching is managed. The second benefit of this is that we can develop out of the source tree (that is without having to "install" the submodules) and have another version or many versions "installed" at the same time. Starting with a member of each version stays within that version of the code. > If you have a program which is in multiple files, you can write a > function similar to `require' which searches for files in any way you > like, and then you can use it. The function can be in your program; > it does not need to be built-in. It can load the chosen file using > `load'. > > The files should each use `provide' in the usual way, and your > function should use the variable `features' to see if the desired > feature has already been loaded. The only difference would be in > choosing which file to load. > That's in fact what I have done. The only "primitive" needed is Ruby's __FILE__ which is the same thing as the C preprocessor __FILE__. $# and load-file-name are close; better is (car-safe current-load-list). How these differ, and where __FILE__ is better, is that a macro substitution of the file name is done at compile time inside the code the if compiled, or at eval time if not. --001636b2bc833daad1047856a5a1 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Sat, Nov 14, 2009 at 6:24 AM, Richard= Stallman <rms@gnu.org> wrote:
The basic idea of `require' is that you specify a feature which gets found through a search of all libraries. =A0The idea is that these are
general features which anything might want to use.
Require has two parts which are distinct. One part has the searchin= g for a file in it. The other part is the conditional load depending on whe= ther or not a feature has already been loaded


You want something different:

=A0 =A0That is, one wants to
=A0 =A0load an Emacs Lisp file relative the file that issues the load whic= h is
=A0 =A0often in the same directory or a nearby directory.

It seems to me that this is useful only for loading other parts of on= e
single multi-file program.

No. A large modular pro= gram can be composed of other smaller modular programs. In theory, one can = package each file or subsets of files as their own package, but often those= smaller modules may be custom enough that it doesn't make sense to do = so. Or at least not initially.

However when developing or working on the program, one wants may want t= o work with each of the subparts independently.

Here's an exampl= e that no doubt you are familiar with: a compile has a parser, code generat= or and code optimizer. In a well-written modular compiler one may want to w= ork on and test the parser as an independent unit even though I'm not s= ure you would want to package the front-end for a specific language indepen= dently.

So what require-relative and load-relative allow one to do is create th= ese little independent units without the overhead of using a more elaborate= packaging systems. require/provide in fact does this too. However it pulls= in file searching which is not desired here. Instead, what we want to do i= n a program built of custom modules but is just change how the file searchi= ng is managed.

The second benefit of this is that we can develop out of the source tre= e (that is without having to "install" the submodules) and have a= nother version or many versions "installed" at the same time. Sta= rting with a member of each version stays within that version of the code.<= br>

If you have a program which is in multiple files, you can write a
function similar to `require' which searches for files in any way you like, and then you can use it. =A0The function can be in your program;
it does not need to be built-in. =A0It can load the chosen file using
`load'.

The files should each use `provide' in the usual way, and your
function should use the variable `features' to see if the desired
feature has already been loaded. =A0The only difference would be in
choosing which file to load.

=A0
That's in fact = what I have done.=A0 The only "primitive" needed is Ruby'= s __FILE__=A0 which is the same thing as the C preprocessor=A0 __FILE__.
$# and load-file-name are close; better is (car-safe current-load-list). Ho= w these differ, and where __FILE__ is better, is that a macro substitution = of the file name is done at compile time inside the code the if compiled, o= r at eval time if not.

--001636b2bc833daad1047856a5a1--