On 11/07/2014 06:17 PM, Stefan Monnier wrote:
>> The many add-function composition modes are useful for advice, but
>> counterproductive for customization points: the great variety of options
>> makes it hard to reason about the effect any particular effect.  With a
>> hook, you have a simple list of functions, possibly with a sentinel that
>> delegates to a global value.
> 
> It's a tradeoff, indeed.  It gives you extra flexibility (instead of
> the hook specifying that the functions will be composed with
> "until-failure", each and every function gets to decide how it's
> composed with the others), which of course means more choices to make.
> 
> As I said:
> 
>    If the :before-until is the problematic part, then I guess we should
>    look for ways to improve that (e.g. a better name, or some way for
>    a variable to say that :before-until is the default when adding
>    functions to it?).
> 
> So maybe we should arrange that the "typical" way to compose the
> functions for a particular variable be specified along with that
> variable, so that you can use (for example)

With the existing system, the hook runner gets to specify the "method
combiner" (to use CLOS terminology); with add-function, each hook gets
to specify a different method combiner. It's that possibility that
bothers me, although the lack of a good default increases the risk of
harmful diversity here.

Can you come up with a concrete example of an instance where a
hook-specified method combiner is actually useful?

>    (add-function nil next-error-function #'my-function)
> 
> and add-function would know to use :before-until.
> 
>> I don't see any compelling reason to avoid conventional hooks.
> 
> The extra flexibility.

I'm not yet convinced that the flexibility is worth the cost.