Is (provide 'foo) at the start good or bad?

Is (provide 'foo) at the start good or bad?

[William Xu]

Hi, 

I got a problem while configuring ffap.  I have this in my .emacs: 

  (eval-after-load 'ffap
    '(progn
       (setq ffap-c-path (cons "../inc" ffap-c-path))))

And when I M-x ffap, it will complain that ffap-c-path is not 
defined.  I figured it out it is due to (provide 'ffap) at the 
very start of ffap.el.  The easist solution is changing it to: 

  (eval-after-load "ffap"
    ...  
  
Then it will depend on loading of the file, not just the feature. 
But I always like to depend on the feature(at least typing one 
less char).  So what is the benefit of providing it at the very 
start? 

-- 
William

http://xwl.appspot.com

Re: Is (provide 'foo) at the start good or bad?

[Leo]

On 2009-06-11 13:56 +0100, William Xu wrote:
> Hi, 
>
> I got a problem while configuring ffap.  I have this in my .emacs: 
>
>  (eval-after-load 'ffap
>    '(progn
>       (setq ffap-c-path (cons "../inc" ffap-c-path))))
>
> And when I M-x ffap, it will complain that ffap-c-path is not defined.
> I figured it out it is due to (provide 'ffap) at the very start of
> ffap.el.  The easist solution is changing it to: 
>
>  (eval-after-load "ffap"
>    ...  Then it will depend on loading of the file, not just the
> feature. But I always like to depend on the feature(at least typing
> one less char).  So what is the benefit of providing it at the very
> start? 

I have run into this problem before. I prefer putting provide at the end
of the file.

-- 
Leo's Emacs uptime: 1 day, 3 hours, 18 minutes, 37 seconds

Re: Is (provide 'foo) at the start good or bad?

[Stephen J. Turnbull]

Leo writes:

 > > one less char).  So what is the benefit of providing it at the very
 > > start? 
 > 
 > I have run into this problem before. I prefer putting provide at the end
 > of the file.

Putting the provide form at the beginning allows mutually recursive
requires to succeed.  I also prefer it as a matter of style, sort of
serving as a `declare-package'.

Regarding work-arounds, I would do the OP's task (customizing a
variable) in a mode-hook using `add-to-list', rather than as an
eval-after-load.

Re: Is (provide 'foo) at the start good or bad?

[William Xu]

"Stephen J. Turnbull" <stephen@xemacs.org> writes:

> Leo writes:
>
>  > > one less char).  So what is the benefit of providing it at the very
>  > > start? 
>  > 
>  > I have run into this problem before. I prefer putting provide at the end
>  > of the file.
>
> Putting the provide form at the beginning allows mutually recursive
> requires to succeed.  I also prefer it as a matter of style, sort of
> serving as a `declare-package'.

That makes sense.  But looks like doesn't work very well? I tried the
following: 

a.el
==== 

  (provide 'a)
  
  (require 'b)
  
  (defun a-hi ()
    )
  
  (b-hi)

b.el
==== 

  (provide 'b)
  
  (require 'a)
  
  (defun b-hi ()
    )
  
  (a-hi)

Put them under load-path, now if I try (require 'a), i got: 

,----
| Debugger entered--Lisp error: (void-function a-hi)
|   (a-hi)
|   eval-buffer(#<buffer  *load*<2>> nil "q:/.emacs.d/site-lisp/b.el" nil t)  ; Reading at buffer position 55
|   load-with-code-conversion("q:/.emacs.d/site-lisp/b.el" "q:/.emacs.d/site-lisp/b.el" nil t)
|   require(b)
|   eval-buffer(#<buffer  *load*> nil "q:/.emacs.d/site-lisp/a.el" nil t)  ; Reading at buffer position 27
|   load-with-code-conversion("q:/.emacs.d/site-lisp/a.el" "q:/.emacs.d/site-lisp/a.el" nil t)
|   require(a)
|   eval((require (quote a)))
|   eval-last-sexp-1(nil)
|   eval-last-sexp(nil)
|   call-interactively(eval-last-sexp nil nil)
`----

So this doesn't really resolve the recursive requires? 

> Regarding work-arounds, I would do the OP's task (customizing a
> variable) in a mode-hook using `add-to-list', rather than as an
> eval-after-load.

Unfortunately, ffap has no such hook available, and it is not a mode.
add-to-list itself recommends eval-after-load at some point somehow:

,----[ C-h f add-to-list RET ]
| add-to-list is a compiled Lisp function in `subr.el'.
| 
| (add-to-list LIST-VAR ELEMENT &optional APPEND COMPARE-FN)
| 
| Add ELEMENT to the value of LIST-VAR if it isn't there yet.
| The test for presence of ELEMENT is done with `equal',
| or with COMPARE-FN if that's non-nil.
| If ELEMENT is added, it is added at the beginning of the list,
| unless the optional argument APPEND is non-nil, in which case
| ELEMENT is added at the end.
| 
| The return value is the new value of LIST-VAR.
| 
| If you want to use `add-to-list' on a variable that is not defined
| until a certain package is loaded, you should put the call to `add-to-list'
| into a hook function that will be run only after loading the package.
| `eval-after-load' provides one way to do this.  In some cases
| other hooks, such as major mode hooks, can do the job.
`----

-- 
William

http://xwl.appspot.com

Re: Is (provide 'foo) at the start good or bad?

[Thien-Thi Nguyen]

() William Xu <william.xwl@gmail.com>
() Fri, 12 Jun 2009 08:01:32 +0300

     (b-hi)

     (a-hi)

   Put them under load-path, now if I try (require 'a), i got: 

   ,----
   | Debugger entered--Lisp error: (void-function a-hi) [...]
   `----

   So this doesn't really resolve the recursive requires? 

Does it help if you comment out the load-time calls to `b-hi' and `a-hi'?

thi

Re: Is (provide 'foo) at the start good or bad?

[Stephen J. Turnbull]

William Xu writes:

 > That makes sense.  But looks like doesn't work very well? I tried the
 > following: 

Of course that doesn't work.  You've got a dependency loop.  In this
particular case you can break it by using "just-in-time" requires:

a.el:
(provide 'a)
(defun a-hi ())
(require 'b)
(b-hi)

b.el:
(provide 'b)
(defun b-hi ())
(require 'a)
(a-hi)

but that won't always work.  However, this:

a.el:
(require 'b)
(provide 'a)

b.el:
(require 'a)
(provide 'b)

is already an infloop.

Bottom line: In mutually recursive requires, provide at the top gives
you rope.  You can knit a hammock and enjoy life, or knot a noose and
die.  Your choice.  Provide at the bottom is an obtuse way to find out
how much memory you have.  No choice.

On the other hand you do have the original problem that
eval-after-load will not necessarily work right.  This is basically
the same issue, though, and probably needs to be fixed by refactoring
eventually.  Using a mode-activation hook is one such refactoring,
although it doesn't work in this case.

 > Unfortunately, ffap has no such hook available, and it is not a mode.
 > add-to-list itself recommends eval-after-load at some point somehow:

(eval-after-load
  ;; eventually fails silently if the list-variable was never defined
  ;; probably not what you want
  (when (boundp 'list-variable)
    (add-to-list 'list-variable element-to-add)))

or

(eval-after-load
  ;; eventually fails loudly if the list-variable was never defined
  ;; probably what you want
  (unless load-file-name
    (add-to-list 'list-variable element-to-add)))

might work, but I forget the original context.

Of course Alan is correct, there is no one right way, and you might
consider the "cures" above worse than the "disease".

Re: Is (provide 'foo) at the start good or bad?

[William Xu]

"Stephen J. Turnbull" <stephen@xemacs.org> writes:

> Provide at the bottom is an obtuse way to find out
> how much memory you have.  No choice.

Well, seems elisp evaluator detects this quite early, as shown below: 

,----
| Debugger entered--Lisp error: (error "Recursive `require' for feature `a'")
|   require(a)
|   eval-buffer(#<buffer  *load*<8>> nil "q:/.emacs.d/site-lisp/b.el" nil t)  ; Reading at buffer position 13
|   .  
|   .  
|   eval-buffer(#<buffer  *load*<2>> nil "q:/.emacs.d/site-lisp/b.el" nil t)  ; Reading at buffer position 13
|   load-with-code-conversion("q:/.emacs.d/site-lisp/b.el" "q:/.emacs.d/site-lisp/b.el" nil t)
|   require(b)
|   eval-buffer(#<buffer  *load*> nil "q:/.emacs.d/site-lisp/a.el" nil t)  ; Reading at buffer position 13
|   load-with-code-conversion("q:/.emacs.d/site-lisp/a.el" "q:/.emacs.d/site-lisp/a.el" nil t)
|   require(a)
|   eval((require (quote a)))
|   eval-last-sexp-1(nil)
|   eval-last-sexp(nil)
|   call-interactively(eval-last-sexp nil nil)
`----

So, the most reliable way would be just-in-time requires like you
explained.  Providing at the top might solve some problem, it look likes
a treat.  OTOH, this took me quite a while to figure out what is going
wrong.

-- 
William

http://xwl.appspot.com

Re: Is (provide 'foo) at the start good or bad?

[Alan Mackenzie]

Hi, Stephen,

On Fri, Jun 12, 2009 at 01:09:43PM +0900, Stephen J. Turnbull wrote:
> Leo writes:

>  > > one less char).  So what is the benefit of providing it at the
>  > > very start? 

>  > I have run into this problem before. I prefer putting provide at the
>  > end of the file.

> Putting the provide form at the beginning allows mutually recursive
> requires to succeed.  I also prefer it as a matter of style, sort of
> serving as a `declare-package'.

Putting `provide' at the end of the file means you've actually loaded
the file when the provision is done.  Thus if the load crashes (very
common when you're developing), you don't have a spurious provided
symbol.

Like in lots of things, there's no one Right Way to do it.

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: Is (provide 'foo) at the start good or bad?

[Stephen J. Turnbull]

Alan Mackenzie writes:

 > Putting `provide' at the end of the file means you've actually loaded
 > the file when the provision is done.  Thus if the load crashes (very
 > common when you're developing), you don't have a spurious provided
 > symbol.

Dunno about your Emacs, but my Emacs undoes the `provide' if `require'
does not complete successfully (assuming that Emacs itself is still
alive, of course :-).

This doesn't work for a plain `load', but I'm not sure I care, since
I rarely use a plain load in a program, and if a `load' crashes
interactively, presumably I intend to fix it immediately.

YMMV.

Re: Is (provide 'foo) at the start good or bad?

[Davis Herring]

> Putting the provide form at the beginning allows mutually recursive
> requires to succeed.

If you have two files which require each other, why do they each have a
feature symbol?  Requiring one is equivalent to requiring the other (and
equivalent to requiring both, in either order), and `featurep' will always
return the same value for each.  The only reasons I can think of to have
two such files separately are to
1. make them each smaller and easier to digest
2. hide some ugly hacks that aren't relevant to the package's interface
3. provide backwards compatibility with earlier versions of two packages
that used to not be interdependent
4. connect two packages which somehow depend on each other and yet are
maintained by different people.

#1 and #2 can be resolved by having the one that is found by `require'
`load' the other.  #3 can be resolved by replacing one or both "old"
packages with a "dummy" that merely requires the combined package and
provides itself.  #4 is likely to require more than merely turning the
third `require' into a no-op: putting one of the `require's at the bottom,
or doing something like (let ((combined-a-b-load t)) (require 'b)).

Put differently, `provide' is supposed to "Announce that FEATURE is a
feature of the current Emacs.".  If you put it at the beginning of a
package, you're lying (until the end of it).

Davis

-- 
This product is sold by volume, not by mass.  If it appears too dense or
too sparse, it is because mass-energy conversion has occurred during
shipping.

Re: Is (provide 'foo) at the start good or bad?

[Stephen J. Turnbull]

Davis Herring writes:

 > > Putting the provide form at the beginning allows mutually recursive
 > > requires to succeed.
 > 
 > If you have two files which require each other, why do they each have a
 > feature symbol?

Because external packages don't know about the mutual dependency, and
shouldn't have to.  Multiple versions of the files may support the
same interfaces, some with and some without mutual dependency.  Etc.

 > Put differently, `provide' is supposed to "Announce that FEATURE is a
 > feature of the current Emacs.".  If you put it at the beginning of a
 > package, you're lying (until the end of it).

Sure.  There are other standard techniques that involve such "lying",
like `(defvar foo)', which does exactly the same kind of thing that a
provide at the top does.  In both cases, there may be a path through
the code leaves something uninitialized.

Re: Is (provide 'foo) at the start good or bad?

[Davis Herring]

>  > If you have two files which require each other, why do they each have a
>  > feature symbol?
>
> Because external packages don't know about the mutual dependency, and
> shouldn't have to.  Multiple versions of the files may support the
> same interfaces, some with and some without mutual dependency.  Etc.

That was case #3, wasn't it?  Once you have such a dependency, you might
as well (internally, for development) treat the two files as one package. 
I didn't mean to imply that you never needed two symbols -- that's why I
gave solutions, for each case that I could think of, that didn't involve
putting `provide' at the top.

>  > Put differently, `provide' is supposed to "Announce that FEATURE is a
>  > feature of the current Emacs.".  If you put it at the beginning of a
>  > package, you're lying (until the end of it).
>
> Sure.  There are other standard techniques that involve such "lying",
> like `(defvar foo)', which does exactly the same kind of thing that a
> provide at the top does.  In both cases, there may be a path through
> the code leaves something uninitialized.

But the only thing which can even tell that (defvar foo) was present is
the byte-compiler; we know all about how to lie to it safely.  `provide'
has a globally-visible effect (that's its whole purpose!), so arbitrary
code may react badly if we lie when we use it.

Davis

-- 
This product is sold by volume, not by mass.  If it appears too dense or
too sparse, it is because mass-energy conversion has occurred during
shipping.

Re: Is (provide 'foo) at the start good or bad?

[Stephen J. Turnbull]

Davis Herring writes:

 > >  > If you have two files which require each other, why do they each have a
 > >  > feature symbol?
 > >
 > > Because external packages don't know about the mutual dependency, and
 > > shouldn't have to.  Multiple versions of the files may support the
 > > same interfaces, some with and some without mutual dependency.  Etc.
 > 
 > That was case #3, wasn't it?

No.  You're missing the "multiple versions" case.  (Although GNU Emacs
prefers to "support" 3rd party libraries by incorporating them, other
Emacsen try to support third parties as independent projects, and that
doesn't necessarily mean there's a blessed third party for each such
library, either.)

 > Once you have such a dependency, you might as well (internally, for
 > development)

You and I don't internally share a heart, and there's similarly no
reason to suppose the libraries are jointly developed, not even the
multiple versions of a single library.

 > >  > Put differently, `provide' is supposed to "Announce that FEATURE is a
 > >  > feature of the current Emacs.".  If you put it at the beginning of a
 > >  > package, you're lying (until the end of it).
 > >
 > > Sure.  There are other standard techniques that involve such "lying",
 > > like `(defvar foo)', which does exactly the same kind of thing that a
 > > provide at the top does.  In both cases, there may be a path through
 > > the code leaves something uninitialized.
 > 
 > But the only thing which can even tell that (defvar foo) was present is
 > the byte-compiler; we know all about how to lie to it safely.  `provide'
 > has a globally-visible effect (that's its whole purpose!), so arbitrary
 > code may react badly if we lie when we use it.

If you need to lie in programming, something is broken, and by
definition that's not safe.

Re: Is (provide 'foo) at the start good or bad?

[Davis Herring]

>  > > Because external packages don't know about the mutual dependency, and
>  > > shouldn't have to.  Multiple versions of the files may support the
>  > > same interfaces, some with and some without mutual dependency.  Etc.
>  >
>  > That was case #3, wasn't it?
>
> No.  You're missing the "multiple versions" case.  (Although GNU Emacs
> prefers to "support" 3rd party libraries by incorporating them, other
> Emacsen try to support third parties as independent projects, and that
> doesn't necessarily mean there's a blessed third party for each such
> library, either.)

(I think most of the productive ideas here have been stated.  Purely for
my edification:)  Why, if we have Av1 and Bv1, neither of which requires
the other (or at least only one requires the other), and Av2 and Bv2,
which are mutually dependent, can't we merge only the latter and have ABv2
(perhaps with one or two tiny files that let (require 'A) and (require 'B)
find it) while still leaving the old, independent versions separate?

...I suppose you could have the situation where Av1 requires Bv1, and then
Bv2 also requires Av1, and you'd like to not have to modify A.  But then
you could either make Av1.0.1 that just changes the `require's (not much
of a hassle since people that would need it are upgrading B anyway), or
else make A(+B)v2 (and a B stub) rather than Bv2 at all.  Right?

Later you said that the (mutually-dependent versions of the) libraries
might continue to be developed separately.  That seems odd to me, since
they will always be loaded together, and they might need to be upgraded
together.  But if it does happen, then perhaps the right thing is to put
`require's as late as possible and `provide's right before them, so that
both mutual recursion and `eval-after-load' will work (most of the time).

Davis

-- 
This product is sold by volume, not by mass.  If it appears too dense or
too sparse, it is because mass-energy conversion has occurred during
shipping.

Re: Is (provide 'foo) at the start good or bad?

[Stephen J. Turnbull]

Davis Herring writes:

 > > No.  You're missing the "multiple versions" case.
 > 
 > (I think most of the productive ideas here have been stated.  Purely for
 > my edification:)  Why, if we have Av1 and Bv1, neither of which requires
 > the other (or at least only one requires the other), and Av2 and Bv2,
 > which are mutually dependent, can't we merge only the latter

Emacs can, because Emacs offers neither support for 3rd party packages
nor support for previous versions of Emacs.  XEmacs cannot, because we
offer support for both.

That is, Emacs has a policy of doing what is best for Emacs, and if
third parties feel ill-used, let them integrate their code and Emacs
will of course ensure that their code works well in future versions of
Emacs.  Not everybody want to integrate their code into anything,
however.  XEmacs (and SXEmacs, AFAIK) deliberately encourages 3rd
parties to develop their projects separately, while providing tools to
integrate them smoothly at runtime.

 > Later you said that the (mutually-dependent versions of the) libraries
 > might continue to be developed separately.  That seems odd to me,

That doesn't surprise me.  There are a fair number of people in this
world who don't think that "odd" is a good reason to restrict freedom,
however, and even a few who act on the freedom thus granted.

 > since they will always be loaded together, and they might need to
 > be upgraded together.

"Always" is too strong; see the third option of `require'.

 > But if it does happen, then perhaps the right thing is to put
 > `require's as late as possible and `provide's right before them, so
 > that both mutual recursion and `eval-after-load' will work (most of
 > the time).

`eval-after-load' is an optimization.  Anything that can be done with
`eval-after-load' can be done with `require-before-doing'. :-)  The
right thing is to fix `eval-after-load' to wait until all loading is
done, then its environment should be in place, and it can do its
thing.

I don't know how to do this offhand, though.

Re: Is (provide 'foo) at the start good or bad?

[Stefan Monnier]

> char).  So what is the benefit of providing it at the very start? 

The convention is to put the `provide' at the end of the file.
Occasionally (usually because of mutual dependencies), it is a lot more
convenient to put it at the beginning.  But whenever possible, it should
be at the end (and indeed `eval-after-load' requires it to be at the
end for the feature to work properly).


        Stefan