Re: Strange eval-after-load

[Alan Mackenzie]

On Wed, Jul 05, 2006 at 11:09:24AM +0200, David Kastrup wrote:
> Alan Mackenzie <address@hidden> writes:

> > On Wed, Jul 05, 2006 at 06:20:41AM +0300, Eli Zaretskii wrote:
> >> > Date: Tue, 4 Jul 2006 22:08:05 +0100
> >> > From: Alan Mackenzie <address@hidden>
> >> > Cc: address@hidden

> >> > (eval-after-load "edebug" '(def-edebug-spec c-point t))

> >> > To construe this form as "modifying the behaviour of another Lisp file
> >> > (?edebug, presumably) in an invisible way" seems like a total perversion
> >> > of reality to me.  I would call this e-a-l "Telling another Lisp file
> >> > how to handle the current one" - in essence, the module which is
> >> > modified by this e-a-l is cc-defs, not edebug.

> >> Doesn't "Telling another Lisp file how to handle the current one"
> >> modify the behavior of that other package in a way that isn't visible
> >> if you look at the code of that other package?

> > Whether it does or not is surely independent of whether
> > `def-edebug-spec' is called directly, or through eval-after-load.
> > Again, this change is just as visible, whichever way the function is
> > called.  Surely?

> The change is not visible where it happens, namely at the (provide 'edebug).

That is WHEN the change happens.  Loading edebug is the trigger.  I'm
not sure what you mean by "where", here.  Do you mean the module whose
data is changed?  Or do you mean the module whose functions make the
change?  If you could say what you wanted to see and why, that might
help me.

> > There is nothing objectionable about using the documented functional
> > interface `def-edebug-spec'.

> Straw man.  Nobody objected to its use.  What is objectional is that
> its call happens at the (provide 'edebug) line without any visible
> indication in edebug.el, and without any user-accessible variables or
> hook that would allow for inspection and modification of the behavior.

Don't all hooks work this way?  What do you mean by "visible"?  I'm
sorry, but the rest of the paragraph is too vague to make any sense to
me.  A call happening without user-accessible variables or a hook is
like a cuckoo clock chiming without Pythagoras's theorem.  There are
several behaviours which you could mean by "the" behaviour.  When would
a user want to access these variables, and why?  What would be the
purpose of using a hook to modify whichever behaviour?

> A user won't have cause to be surprised if he added eval-after-load
> himself.  But expecting and tracking every such use that might be
> hidden in Emacs' code base is a bit much.

It's no more or less difficult that tracking down every place a hook is
used.  eval-after-load is conceptually the same as add-hook.  Why is
using e-a-l worse than using LaTeX-mode-hook,  for example?

> >> In your example above, Edebug's behavior is modified, but one cannot
> >> know that by reading Edebug's code alone.

> > Why is this bad?

> The reasons have been cited to you several times and it is in the
> manual which also has been cited to you.
 
Resorts to hand waving abstractions have been made, but no descent to the
concrete.  I think that you and Richard and Eli must have experienced
problems with eval-after-load - I've not.  The only problems I've had
with it were those cause by bugs in its code and documentation, not its
use, and I've tried to fix these bugs.

Since I haven't experienced these problems, the level of abstraction you
have been talking at is meaningless to me.  It's obvious that
eval-after-load can be used very stupidly, but that's not the point.

I cannot conceive of any (real) problems which might be caused by

   (eval-after-load "edebug" '(def-edebug-spec c-point t))

If you're still willing to carry on trying to help me get the point,
perhaps you could cite a specific problem caused by a specific
"nice" use of eval-after-load.  I'd be grateful.

> David Kastrup, Kriemhildstr. 15, 44793 Bochum

-- 
Alan Mackenzie (Munich, Germany)