Always-true predicate?

Always-true predicate?

[Lars Ingebrigtsen]

Currently, Emacs has:

----
   Sometimes, when you call a functional, it is useful to supply a no-op
function as the argument.  Here are two different kinds of no-op
function:

 -- Function: identity argument
     This function returns ARGUMENT and has no side effects.

 -- Function: ignore &rest arguments
     This function ignores any ARGUMENTS and returns ‘nil’.
----

`identity' is kinda-sorta used as the opposite of `ignore' many places
where you're feeding predicates to functions, but takes only one
parameter and, of course, returns nil if you give it nil.

Would it make sense to add a function that's exactly the opposite of
`ignore' (for symmetry and convenience)?  If so, what would it be
called?

I've googled to see what other languages do.  Rust and NPM has "always",
and many more Java-inspired frameworks have "truePredicate", but this
isn't trivial to google for...

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: Always-true predicate?

[Andrea Corallo via Emacs development discussions.]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> Currently, Emacs has:
>
> ----
>    Sometimes, when you call a functional, it is useful to supply a no-op
> function as the argument.  Here are two different kinds of no-op
> function:
>
>  -- Function: identity argument
>      This function returns ARGUMENT and has no side effects.
>
>  -- Function: ignore &rest arguments
>      This function ignores any ARGUMENTS and returns ‘nil’.
> ----
>
> `identity' is kinda-sorta used as the opposite of `ignore' many places
> where you're feeding predicates to functions, but takes only one
> parameter and, of course, returns nil if you give it nil.
>
> Would it make sense to add a function that's exactly the opposite of
> `ignore' (for symmetry and convenience)?  If so, what would it be
> called?
>
> I've googled to see what other languages do.  Rust and NPM has "always",
> and many more Java-inspired frameworks have "truePredicate", but this
> isn't trivial to google for...

Maybe something like CONSTANTLY would be more generic?

<http://www.lispworks.com/documentation/HyperSpec/Body/f_cons_1.htm>

  Andrea

Re: Always-true predicate?

[Lars Ingebrigtsen]

Andrea Corallo <akrl@sdf.org> writes:

> Maybe something like CONSTANTLY would be more generic?
>
> <http://www.lispworks.com/documentation/HyperSpec/Body/f_cons_1.htm>

I'm not sure that's a net win.  The use case here is, for instance

(defalias 'mouse-sel--ignore #'ignore)
(defvar after-focus-change-function #'ignore

etc, which is fast and easy to read.  If you're doing a predicate, you
now have to say

(setq some-predicate #'ignore)

but

(setq some-predicate (lambda (&rest _) t))

or

(setq some-predicate (constantly t))

which seems unsymmetric.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: Always-true predicate?

[Barry Fishman]

On 2021-02-17 13:40:14 +01, Lars Ingebrigtsen wrote:
> Andrea Corallo <akrl@sdf.org> writes:
>
>> Maybe something like CONSTANTLY would be more generic?
>> <http://www.lispworks.com/documentation/HyperSpec/Body/f_cons_1.htm>

> I'm not sure that's a net win.  The use case here is, for instance
>
> (defalias 'mouse-sel--ignore #'ignore)
> (defvar after-focus-change-function #'ignore
>
> etc, which is fast and easy to read.  If you're doing a predicate, you
> now have to say
>
> (setq some-predicate #'ignore)
>
> but
>
> (setq some-predicate (lambda (&rest _) t))
>
> or
>
> (setq some-predicate (constantly t))
>
> which seems unsymmetric.

Something symmetric would be:

(setq some-predicate (constantly nil))

Ignore seems more about its lack of effects rather than its return value.

--
Barry Fishman

Re: Always-true predicate?

[Stefan Kangas]

Andrea Corallo via "Emacs development discussions."
<emacs-devel@gnu.org> writes:

> Maybe something like CONSTANTLY would be more generic?
>
> <http://www.lispworks.com/documentation/HyperSpec/Body/f_cons_1.htm>

See also this feature request to add `constantly' to Emacs:

    https://debbugs.gnu.org/cgi/bugreport.cgi?bug=21584

Re: Always-true predicate?

[Basil L. Contovounesios]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> Would it make sense to add a function that's exactly the opposite of
> `ignore' (for symmetry and convenience)?

+1.

> If so, what would it be called?

> I've googled to see what other languages do.  Rust and NPM has "always",
> and many more Java-inspired frameworks have "truePredicate", but this
> isn't trivial to google for...

I'm okay with any of 'always', 'true', 'non-nil', 'top', ...

-- 
Basil

Re: Always-true predicate?

[Pip Cet]

On Wed, Feb 17, 2021 at 1:18 PM Basil L. Contovounesios <contovob@tcd.ie> wrote:
> Lars Ingebrigtsen <larsi@gnus.org> writes:
>
> > Would it make sense to add a function that's exactly the opposite of
> > `ignore' (for symmetry and convenience)?

t

> > If so, what would it be called?

t

> > I've googled to see what other languages do.  Rust and NPM has "always",
> > and many more Java-inspired frameworks have "truePredicate", but this
> > isn't trivial to google for...
>
> I'm okay with any of 'always', 'true', 'non-nil', 'top', ...

How about 't'?

I do realize there'd be a problem with hooks, which use 't' as a flag
in a list of functions...

Of course, there's an unfortunate tradition in computing to consider
1, rather than infinity, the canonical "true" value, so (t nil) might
be expected to be nil, but apart from that, I don't think confusion is
that likely, at least with a single argument.

Re: Always-true predicate?

[Lars Ingebrigtsen]

Pip Cet <pipcet@gmail.com> writes:

>> > Would it make sense to add a function that's exactly the opposite of
>> > `ignore' (for symmetry and convenience)?
>
> t

You want to defun t?

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: Always-true predicate?

[Pip Cet]

On Wed, Feb 17, 2021 at 7:19 PM Lars Ingebrigtsen <larsi@gnus.org> wrote:
> Pip Cet <pipcet@gmail.com> writes:
> >> > Would it make sense to add a function that's exactly the opposite of
> >> > `ignore' (for symmetry and convenience)?
> > t
> You want to defun t?

(Resisting the temptation to answer with the same single-letter response...)

Strictly speaking, I only want to special-case it so (funcall t ...)
is t. Defuning it would be one way of achieving that, but not the only
possible one.

(lambda (&rest args) t) is the top element of the lattice of functions
in several senses: it's the pointwise logical or of all functions, it
has the largest possible codomain, and it's the universal predicate.
Such top elements are usually represented as 't'.

Note that ignore is the bottom element of only two of those lattices,
so there's less of an argument to be made for it. An always-throwing
function that accepts no possible argument list would make just as
much sense.

(apply nil), of course, should continue to crash Emacs.

Re: Always-true predicate?

[Lars Ingebrigtsen]

Pip Cet <pipcet@gmail.com> writes:

> (apply nil), of course, should continue to crash Emacs.

Heh heh.  I hate to disappoint you, but it no longer does that in Emacs
28.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: Always-true predicate?

[Teemu Likonen]

[-- Attachment #1: Type: text/plain, Size: 809 bytes --]

* 2021-02-17 20:37:19+0100, Lars Ingebrigtsen wrote:

> Pip Cet <pipcet@gmail.com> writes:
>> (apply nil), of course, should continue to crash Emacs.
>
> Heh heh.  I hate to disappoint you, but it no longer does that in Emacs
> 28.

Could you please make it optional? So that those who want the new
behaviour of (apply nil) can get it by doing something like:

    M-x customize-variable RET apply-nil-will-not-segfault-anymore RET

There are many users and third-party packages which depend on the old
behaviour. I'll show you stats in a minute...

Seriously: I remember one case when I tried to find CONSTANTLY or
similar but failed. I wrote some LAMBDA form. No big deal.

-- 
/// Teemu Likonen - .-.. https://www.iki.fi/tlikonen/
// OpenPGP: 4E1055DC84E9DFF613D78557719D69D324539450

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 251 bytes --]

RE: [External] : Re: Always-true predicate?

[Drew Adams]

> Could you please make it optional? So that those who want the new
> behaviour of (apply nil) can get it by doing something like:
> 
>     M-x customize-variable RET apply-nil-will-not-segfault-anymore RET
> 
> There are many users and third-party packages which depend on the old
> behaviour. I'll show you stats in a minute...
> 
> Seriously: I remember one case when I tried to find CONSTANTLY or
> similar but failed. I wrote some LAMBDA form. No big deal.

Agreed, no big deal.
___

But if it's decided to do this, then clearly a function
that accepts an optional arg and just returns that arg
is preferable to either one that always returns `t' or
one that requires (instead of just accepts) an arg.

And the name `constantly' has a connotation of
repetition, which isn't relevant.  This is essentially
just the SKI logical combinator `K'.  Call it `constant'
or some such, perhaps.

OTOH, with Lisp, if the argument can return different
values when its evaluated then this really isn't a
constant-returning function.
___

But again, I agree with Teemu: YAGNI.

Re: [External] : Re: Always-true predicate?

[Basil L. Contovounesios]

Drew Adams <drew.adams@oracle.com> writes:

> But again, I agree with Teemu: YAGNI.

I think you meant *You* AGNI.

-- 
Basil

RE: [External] : Re: Always-true predicate?

[Drew Adams]

> > But again, I agree with Teemu: YAGNI.
> 
> I think you meant *You* AGNI.

You're right that _I_ won't need it.  But my
impression is also that Emacs doesn't need it.

I guess you feel strongly that you are going
to need it?  Or that Emacs will?

Typically in a case like this (some simple
code that people write and use over and over)
we find that users have written local named
functions for such things, which they use.

That was the case, for instance, for things
like `remove-if(-not)'.  Because people wrote
such functions locally so much, for multiple
libraries, we decided to add them to Emacs.

Is something like that the case here?  Do you
(for example) already define a named function
for this, for your own use?

If no one actualy does that, and people are
fine with (lambda () t), then, yeah, I'd think
E(macs)AGNI.

Re: Always-true predicate?

[Stefan Monnier]

> Seriously: I remember one case when I tried to find CONSTANTLY or
> similar but failed. I wrote some LAMBDA form. No big deal.

Maybe we should let `lambda` take arguments like Scheme does, i.e.
(lambda (a b . c) FOO) instead of (lambda (a b &rest c) FOO), and in that
case we could simple use "lambda _" as a shorthand for "constantly".


        Stefan

Re: Always-true predicate?

[Pip Cet]

On Wed, Feb 17, 2021 at 11:01 PM Stefan Monnier
<monnier@iro.umontreal.ca> wrote:
> > Seriously: I remember one case when I tried to find CONSTANTLY or
> > similar but failed. I wrote some LAMBDA form. No big deal.
>
> Maybe we should let `lambda` take arguments like Scheme does, i.e.
> (lambda (a b . c) FOO) instead of (lambda (a b &rest c) FOO), and in that
> case we could simple use "lambda _" as a shorthand for "constantly".

That would break things like pcase-lambda, though: we would no longer
be able to generalize lambda meaningfully.

TL;DR - let's make (lambda (&rest) t) valid for the universal
predicate and leave it at that.

Anyway, my problem with variadic functions isn't defining them, it's
calling them. I think I should be able to say

(f a b c &rest d)

rather than

(apply #'f a b c d)

which would make usage mimic declaration. Kind of like JavaScript's
... operator (and in fact that would be a better name for it than
&rest, IMHO, though of course it should be a symbol rather than extra
syntax). (For extra fun, consider

(f &rest a &rest b) = (apply #'f (append a b))

and

(f &rest keywords values) = (apply #'f (zip keywords values))

(I don't like apply, even when it's not (apply nil), mostly because

(apply #'f 'a 'b nil)

isn't necessarily equivalent to

(f 'a 'b) [1])

As for the universal predicate, I'd like to be able to write (lambda
(&rest) t), which would save two characters. (lambda (...) t) would
save another one :-) )

And if we can require optional arguments, why can't we provide them
optionally? For example, let's say in Emacs 33 we want to expand
copy-marker with a new argument to more clearly describe how the
marker repositions itself relative to other markers (or implicit)
markers at the same character position. But (copy-marker marker nil
&optional 'something) would work in Emacs 32 (which would include the
optionally-provided argument extension), and be equivalent to
(copy-marker marker nil) there.

Pip

[1] - if f is a macro, for example. The byte compiler has a fun bug if
you feed it this input:

(defun eval-then-throw (a b)
  (apply #'or a (eval b) nil))

(eval-then-throw t '(message "printme"))
(byte-compile 'eval-then-throw)
(eval-then-throw t '(message "printme"))

Re: Always-true predicate?

[Stefan Monnier]

>> > Seriously: I remember one case when I tried to find CONSTANTLY or
>> > similar but failed. I wrote some LAMBDA form. No big deal.
>> Maybe we should let `lambda` take arguments like Scheme does, i.e.
>> (lambda (a b . c) FOO) instead of (lambda (a b &rest c) FOO), and in that
>> case we could simple use "lambda _" as a shorthand for "constantly".
> That would break things like pcase-lambda, though: we would no longer
> be able to generalize lambda meaningfully.

[ Not sure if you missed the implied smiley or if you're going along with
  the crazy idea.  ]

`pcase-lambda` wouldn't have to follow suit, so it'd be affected only if
it decides to.

> Anyway, my problem with variadic functions isn't defining them, it's
> calling them. I think I should be able to say
>
> (f a b c &rest d)
>
> rather than
>
> (apply #'f a b c d)

I don't think it's sufficiently nicer to justify making such a change,
but yes, it would make it more clear when apply is used to call
a known function.

OTOH, the nice thing about `apply` is that it's just a function: no
special treatment, no new syntax, nothing.  Try `grep apply
lisp/emacs-lisp/bytecomp.el` and see how it really needs no
special treatment.

> (f &rest a &rest b) = (apply #'f (append a b))
>
> and
>
> (f &rest keywords values) = (apply #'f (zip keywords values))

I find the left hand side worse than the right hand side, FWIW.

I'd rather reduce the use of `&rest` and `apply` than try to make it
more sexy, since it's fundamentally quite inefficient (since it ends up
having to take the list of args, put them on the stack only to recreate
a new list for them on the other side; in theory it can optimized in
many cases, but in practice it's extremely hard to find those cases
reliably).

> And if we can require optional arguments, why can't we provide them
> optionally? For example, let's say in Emacs 33 we want to expand
> copy-marker with a new argument to more clearly describe how the
> marker repositions itself relative to other markers (or implicit)
> markers at the same character position. But (copy-marker marker nil
> &optional 'something) would work in Emacs 32 (which would include the
> optionally-provided argument extension), and be equivalent to
> (copy-marker marker nil) there.

This seems difficult to make it work reliably.
E.g. imagine the case where you've added an advice to `copy-marker`, so
it's now redefined to

    (lambda (rest args)
      (message "About to call copy-marker")
      (apply #<subr copy-marker> args))

how would the caller know whether it should pass that `&optional 'something` ?

I can see ways it could work, but I can't see an easy way to get there
from where we are without introducing either a lot of extra complexity
(and runtime cost) in the implementation, or backward incompatibility
for some use cases, or both.


        Stefan

Re: Always-true predicate?

[Pip Cet]

On Fri, Feb 19, 2021 at 3:07 PM Stefan Monnier <monnier@iro.umontreal.ca> wrote:
> >> Maybe we should let `lambda` take arguments like Scheme does, i.e.
> >> (lambda (a b . c) FOO) instead of (lambda (a b &rest c) FOO), and in that
> >> case we could simple use "lambda _" as a shorthand for "constantly".
> > That would break things like pcase-lambda, though: we would no longer
> > be able to generalize lambda meaningfully.
>
> [ Not sure if you missed the implied smiley or if you're going along with
>   the crazy idea.  ]

I mistook it for a serious proposal, sorry.

> `pcase-lambda` wouldn't have to follow suit, so it'd be affected only if
> it decides to.

Then its docstring would need changing, because it would no longer be
like lambda.

> > Anyway, my problem with variadic functions isn't defining them, it's
> > calling them. I think I should be able to say
> >
> > (f a b c &rest d)
> >
> > rather than
> >
> > (apply #'f a b c d)
>
> I don't think it's sufficiently nicer to justify making such a change,

I think "usage mimics declaration" is a very important concept, but if
we're making sunk-cost arguments, one could argue against fairly much
any change...

> OTOH, the nice thing about `apply` is that it's just a function: no
> special treatment, no new syntax, nothing.  Try `grep apply
> lisp/emacs-lisp/bytecomp.el` and see how it really needs no
> special treatment.

...but it gets that special treatment, which is why (apply #'or) is
mis-compiled.

Note that it would be valid, but not required, for us to define what
(or &rest args) means, something apply cannot provide.

> > (f &rest a &rest b) = (apply #'f (append a b))
> >
> > and
> >
> > (f &rest keywords values) = (apply #'f (zip keywords values))
>
> I find the left hand side worse than the right hand side, FWIW.

That's probably a matter of taste and JavaScript exposure :-)

> I'd rather reduce the use of `&rest` and `apply` than try to make it
> more sexy, since it's fundamentally quite inefficient

I think the inefficiency is fundamental to "apply", not to "&rest".
When you call a known procedure all the packing and unpacking of
arguments can be inlined...

> (since it ends up
> having to take the list of args, put them on the stack only to recreate
> a new list for them on the other side; in theory it can optimized in
> many cases, but in practice it's extremely hard to find those cases
> reliably).

I agree our current way of doing things needs work, FWIW.

> > And if we can require optional arguments, why can't we provide them
> > optionally? For example, let's say in Emacs 33 we want to expand
> > copy-marker with a new argument to more clearly describe how the
> > marker repositions itself relative to other markers (or implicit)
> > markers at the same character position. But (copy-marker marker nil
> > &optional 'something) would work in Emacs 32 (which would include the
> > optionally-provided argument extension), and be equivalent to
> > (copy-marker marker nil) there.
>
> This seems difficult to make it work reliably.
> E.g. imagine the case where you've added an advice to `copy-marker`, so
> it's now redefined to
>
>     (lambda (rest args)
>       (message "About to call copy-marker")
>       (apply #<subr copy-marker> args))
>
> how would the caller know whether it should pass that `&optional 'something` ?

The alternative is to use func-arity at runtime, which breaks just as badly.

I think we're back to a fundamental question here: if I understand
correctly, to you, an ELisp function is fundamentally of the "take a
list, return a Lisp object or throw" type, as though it were defined
like this:

(defan f args (if (/= (length args) 2) (throw
'wrong-number-of-arguments)) (+ (car args) (cadr args)))

except not even the symbol "args" is part of the interface or function type.

To me, a function is defined like

(defun f (a b) "Add A and B." (+ a b))

The docstring, argument list, argument names, function name, and the
actual lambda are all part of what makes "f" "f", and it's legitimate
to use them all when calling it.

In your world, (lambda (&rest args) (apply #'f args)) is the same as
f. In my world, we have "func-arity", to which it isn't.

So, yes, wrappers would need a special symbol to use instead of &rest
which would make them receive (at run time) all the information the
caller provided (potentially at compile time). That would also be the
natural place to trap calls inquiring about the docstring, function
name, or arg spec.

So something like

(defun wrap (f)
  "Wrap F into a function object indistinguishable from it."
  (lambda (&universal-arg-list args)
    (cond ((eq args 'docstring)
       (function-docstring f))
      ((eq args 'argspec)
       (function-argspec f))
      ((eq args 'name)
       (function-name f))
      ((apply-universal-arg-list f args)))))

> I can see ways it could work, but I can't see an easy way to get there
> from where we are without introducing either a lot of extra complexity
> (and runtime cost) in the implementation, or backward incompatibility
> for some use cases, or both.

I don't think we can have all three, but then, we're in a pretty sorry
state to begin with. As far as I know, there's no way to define a
wrapper today that preserves arity, docstring, and arg spec, not even
if you cons and eval a lambda list at run time. On the other hand,
there's no way to define a "fast" wrapper function even if you keep
all those things fixed, because you have to go through the apply
machinery, which is fairly slow at present.

Pip

Re: Always-true predicate?

[Stefan Monnier]

>> > (f a b c &rest d)
>> > rather than
>> > (apply #'f a b c d)
>> I don't think it's sufficiently nicer to justify making such a change,
>
> I think "usage mimics declaration" is a very important concept,

I generally agree and the above syntax is indeed satisfactory from that
point of view (and funnily enough Scheme's neat (lambda (x . y) body)
syntax (which is arguably inspired by a similar desire) does not enjoy
such a nice equivalent at call sites since (f x . (append a b)) can't
be distinguished from (f x append a . b)).

> but if we're making sunk-cost arguments, one could argue against
> fairly much any change...

One can argue against any change, indeed (as demonstrated daily on this
list ;-), so in the end it's always a judgment call on the
overall tradeoff.

>> OTOH, the nice thing about `apply` is that it's just a function: no
>> special treatment, no new syntax, nothing.  Try `grep apply
>> lisp/emacs-lisp/bytecomp.el` and see how it really needs no
>> special treatment.
> ...but it gets that special treatment, which is why (apply #'or) is
> mis-compiled.

Actually, it's not the compiler, it's the optimizer.
[ Yes, it's a nitpick, but nevertheless...
  Also, I'm not completely sure in which sense it "miscompiles" it,
  since it can't be compiled correctly, AFAIK.  ]

>> I'd rather reduce the use of `&rest` and `apply` than try to make it
>> more sexy, since it's fundamentally quite inefficient
> I think the inefficiency is fundamental to "apply", not to "&rest".
> When you call a known procedure all the packing and unpacking of
> arguments can be inlined...

IMO it's more fundamental to `&rest` because the callee can rely on the
`&rest` list being a fresh new list (it can safely perform destructive
update on it).

> I think we're back to a fundamental question here: if I understand
> correctly, to you, an ELisp function is fundamentally of the "take a
> list, return a Lisp object or throw" type, as though it were defined
> like this:
>
> (defan f args (if (/= (length args) 2) (throw
> 'wrong-number-of-arguments)) (+ (car args) (cadr args)))

Indeed.

> In your world, (lambda (&rest args) (apply #'f args)) is the same as
> f. In my world, we have "func-arity", to which it isn't.

In my view, a function value of the form (closure ...) or (lambda ...)
or #[...] has arity, but a function value represented by a SYMBOL does
not because it can change at any time.


        Stefan

Re: Always-true predicate?

[Pip Cet]

On Fri, Feb 19, 2021 at 8:11 PM Stefan Monnier <monnier@iro.umontreal.ca> wrote:
> >> > (f a b c &rest d)
> >> > rather than
> >> > (apply #'f a b c d)
> >> I don't think it's sufficiently nicer to justify making such a change,
> >
> > I think "usage mimics declaration" is a very important concept,
>
> I generally agree and the above syntax is indeed satisfactory from that
> point of view (and funnily enough Scheme's neat (lambda (x . y) body)
> syntax (which is arguably inspired by a similar desire) does not enjoy
> such a nice equivalent at call sites since (f x . (append a b)) can't
> be distinguished from (f x append a . b)).

I discovered this the hard way :-)

> >> OTOH, the nice thing about `apply` is that it's just a function: no
> >> special treatment, no new syntax, nothing.  Try `grep apply
> >> lisp/emacs-lisp/bytecomp.el` and see how it really needs no
> >> special treatment.
> > ...but it gets that special treatment, which is why (apply #'or) is
> > mis-compiled.
>
> Actually, it's not the compiler, it's the optimizer.

I didn't say "by bytecomp.el", I only said it's mis-compiled. Which it
is. By the optimizer. Which is part of the compiler.

> [ Yes, it's a nitpick, but nevertheless...

If you think the optimizer isn't part of the byte compiler, please
change the first line of byte-opt.el which says it is ;-)

>   Also, I'm not completely sure in which sense it "miscompiles" it,
>   since it can't be compiled correctly, AFAIK.  ]

???

It's perfectly valid ELisp. It should throw. It doesn't.

> >> I'd rather reduce the use of `&rest` and `apply` than try to make it
> >> more sexy, since it's fundamentally quite inefficient
> > I think the inefficiency is fundamental to "apply", not to "&rest".
> > When you call a known procedure all the packing and unpacking of
> > arguments can be inlined...
>
> IMO it's more fundamental to `&rest` because the callee can rely on the
> `&rest` list being a fresh new list (it can safely perform destructive
> update on it).

So to avoid having to cons up a new list you have to know about the
callee to know it doesn't do that, which apply prevents you from
doing.

> > I think we're back to a fundamental question here: if I understand
> > correctly, to you, an ELisp function is fundamentally of the "take a
> > list, return a Lisp object or throw" type, as though it were defined
> > like this:
> >
> > (defan f args (if (/= (length args) 2) (throw
> > 'wrong-number-of-arguments)) (+ (car args) (cadr args)))
>
> Indeed.

Looking forward to your patch removing all argument names from defuns
everywhere ;-)

I'd like to know what equivalence relation you're using when you say
two bare functions f and g are "the same".

I'm pretty sure it's not any of the following:
- their defuns are the same
- they produce the same values for the same inputs
- they produce the same values for the same inputs at the same complexity

> > In your world, (lambda (&rest args) (apply #'f args)) is the same as
> > f. In my world, we have "func-arity", to which it isn't.
>
> In my view, a function value of the form (closure ...) or (lambda ...)
> or #[...] has arity, but a function value represented by a SYMBOL does
> not because it can change at any time.

In my view, every callable function has arity, which can change at any
time in the case of functions that are symbols (which might become
uncallable, too). (It can also change for closures or lambdas if their
underlying lists are mutable).

It seems obvious to me that if f and g are "the same", (func-arity f)
and (func-arity g) should return equal cons cells. That means unless f
is a subr of arity (0 . many), f is not the same as (lambda (&rest
args) (apply #'f args)).

BTW, I made a mistake in my previous email:

(f a &rest b c) should be equivalent to (apply #'f a (append b (list
c))). No zips, and no spreadification of the last argument.

Pip

Re: Always-true predicate?

[Stefan Monnier]

>>   Also, I'm not completely sure in which sense it "miscompiles" it,
>>   since it can't be compiled correctly, AFAIK.  ]
>
> ???
>
> It's perfectly valid ELisp. It should throw. It doesn't.

You're right, technically.  But most of the time that code like that
shows up, it's just a bug and the intended semantics is different.
IOW I'd be surprised if there is a piece of code out there that wants
this to signal an error ;-)

[ But, just to clarify: I'm not trying to defend this as "not a bug".
  It *is* a bug in the optimizer, no more, no less.  ]

> So to avoid having to cons up a new list you have to know about the
> callee to know it doesn't do that, which apply prevents you from
> doing.

I don't see what you mean by "apply prevents you from doing".  But in
any case, I'd happy to change my stance to say that the guilt is shared
between `apply` and `&rest`.

And yet another way to look at it is that the real culprit is the fact
that `cons` cells are mutable ;-)

> Looking forward to your patch removing all argument names from defuns
> everywhere ;-)

It's almost ready.

> It seems obvious to me that if f and g are "the same",

Function equality and "obvious" just don't belong in the same sentence, IMO.

> BTW, I made a mistake in my previous email:
>
> (f a &rest b c) should be equivalent to (apply #'f a (append b (list
> c))). No zips, and no spreadification of the last argument.

That reminds me of the macro `gnus--,@` I introduced recently (it's
not the same, since ,@ would splice at macro-expansion time, whereas
your &rest here wants to splice at run time).


        Stefan

Re: Always-true predicate?

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > Would it make sense to add a function that's exactly the opposite of
  > `ignore' (for symmetry and convenience)?  If so, what would it be
  > called?

Is there real use for it?  Is it useful often enough that
(lambda (&rest ignore) t) won't suffice?

-- 
Dr Richard Stallman
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: Always-true predicate?

[Robert Pluim]

>>>>> On Fri, 19 Feb 2021 00:39:01 -0500, Richard Stallman <rms@gnu.org> said:

    Richard> [[[ To any NSA and FBI agents reading my email: please consider    ]]]
    Richard> [[[ whether defending the US Constitution against all enemies,     ]]]
    Richard> [[[ foreign or domestic, requires you to follow Snowden's example. ]]]

    >> Would it make sense to add a function that's exactly the opposite of
    >> `ignore' (for symmetry and convenience)?  If so, what would it be
    >> called?

    Richard> Is there real use for it?  Is it useful often enough that
    Richard> (lambda (&rest ignore) t) won't suffice?

Sometimes you just want to return t, and writing out the lambda is
verbose and tedious. We have #'ignore, what's wrong with
#'pretend-to-pay-attention?

Robert

Re: Always-true predicate?

[Eli Zaretskii]

> From: Robert Pluim <rpluim@gmail.com>
> Date: Fri, 19 Feb 2021 09:52:55 +0100
> Cc: Lars Ingebrigtsen <larsi@gnus.org>, emacs-devel@gnu.org
> 
>     Richard> Is there real use for it?  Is it useful often enough that
>     Richard> (lambda (&rest ignore) t) won't suffice?
> 
> Sometimes you just want to return t, and writing out the lambda is
> verbose and tedious.

Why would you need to express t as a function, though? why not just
the value t?

I must diverge somewhat here, and express my uneasiness, to say the
least, with the recent-ish fashion of making too many user options
have function values.  It makes "M-x set-variable" much less
convenient than it should be, and it makes customizing such options
harder for users who aren't proficient in Lisp.  We should limit such
option values to the absolute minimum, IMO.  I'd very much prefer to
have simple atomic values (symbols, numbers, or strings) that are then
interpreted by the relevant commands to run the necessary code or call
out to necessary subroutines to do the job.  I feel that some of us
think that putting functions with the necessary code directly in the
option's value is somehow "cleaner" or "more elegant".  I disagree.

I think that the urge to have the always-true predicate comes from
this tendency.  Lars wrote it soon after introducing an option whose
values _had_ to be functions, so he needed a function that would
always return t.  I say such design of user options is itself a
problem, and if avoided, the need for an always-true function will not
arise, at least not frequently enough to have a canonical solution.

Originally, 'ignore' was used only internally, and for semi-kludgey
solutions that would otherwise require much more coding.  They
recently spread out too much, IMO, which is also a sign of some
trouble.  Let's not let this genie too much space, and minimize the
reasons for asking for such "functions".

Re: Always-true predicate?

[Eli Zaretskii]

> Date: Fri, 19 Feb 2021 11:10:37 +0200
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: larsi@gnus.org, rms@gnu.org, emacs-devel@gnu.org
> 
> I must diverge somewhat here
         ^^^^^^^
Sorry, this was supposed to say "digress".

Re: Always-true predicate?

[Stefan Kangas]

Eli Zaretskii <eliz@gnu.org> writes:

> I must diverge somewhat here, and express my uneasiness, to say the
> least, with the recent-ish fashion of making too many user options
> have function values.  It makes "M-x set-variable" much less
> convenient than it should be, and it makes customizing such options
> harder for users who aren't proficient in Lisp.

Could you elaborate on how it makes it harder to customize?  Doesn't
`customize-option' hide that away?

BTW, should perhaps `set-variable' support completing on the forms in
:type somehow?  Is that a realistic idea?

Re: Always-true predicate?

[Lars Ingebrigtsen]

Stefan Kangas <stefankangas@gmail.com> writes:

> BTW, should perhaps `set-variable' support completing on the forms in
> :type somehow?  Is that a realistic idea?

That'd be nice -- I think it's been suggested a few times before, but
nobody has come up with a UI that would be comfortable to use.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: Always-true predicate?

[Eli Zaretskii]

> From: Stefan Kangas <stefankangas@gmail.com>
> Date: Fri, 19 Feb 2021 06:52:57 -0600
> Cc: larsi@gnus.org, rms@gnu.org, emacs-devel@gnu.org
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > I must diverge somewhat here, and express my uneasiness, to say the
> > least, with the recent-ish fashion of making too many user options
> > have function values.  It makes "M-x set-variable" much less
> > convenient than it should be, and it makes customizing such options
> > harder for users who aren't proficient in Lisp.
> 
> Could you elaborate on how it makes it harder to customize?

Isn't it clear that typing a function at set-variable's prompt is much
less convenient than typing an atom, like a symbol, a string, or a
number?  For starters, it is much more typing.  And then it's easy to
make a mistake, which will require you to start over again.

> Doesn't `customize-option' hide that away?

I was talking about set-variable, not about customize-option.

But even with customize-option things are much less convenient when
using function values.  You say "hide", and mean the values that are
already in the :choice list.  But what about values that aren't?
Customization is about _changing_ the defaults, not about leaving them
unchanged.  Typing a function's name, let alone a lambda-expression,
in the Custom form is no fun.  So having a user option whose value
_must_ be a function is a PITA.

And then we have this annoyance from "C-h v" as well:

  read-extended-command-predicate is a variable defined in ‘simple.el’.
  Its value is
  #f(compiled-function
  (s b)
  #<bytecode 0x5a5068802147c83>)

That's not very useful display for a user option.

> BTW, should perhaps `set-variable' support completing on the forms in
> :type somehow?

It already does, sort-of.  Try typing a value that doesn't fit :type,
and you'll see that in action.

Re: Always-true predicate?

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

> And then we have this annoyance from "C-h v" as well:
>
>   read-extended-command-predicate is a variable defined in ‘simple.el’.
>   Its value is
>   #f(compiled-function
>   (s b)
>   #<bytecode 0x5a5068802147c83>)
>
> That's not very useful display for a user option.

That's what prompted my query about adding something like `always'.
(Although I've been missing the predicate for years.)

I think using function values in user options is fine -- the Emacs
developers can never get cover all behavioural permutations that people
would like to see, so allowing them to supply their own code is helpful.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: Always-true predicate?

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: Stefan Kangas <stefankangas@gmail.com>,  rpluim@gmail.com,  rms@gnu.org,
>   emacs-devel@gnu.org
> Date: Fri, 19 Feb 2021 14:40:32 +0100
> 
> I think using function values in user options is fine -- the Emacs
> developers can never get cover all behavioural permutations that people
> would like to see, so allowing them to supply their own code is helpful.

Allowing a function as _one_ of the values is okay-ish, provided that
we don't do that too willy-nilly, where atoms could do the job.  One
example of what I'd like NOT to see is using 'ignore as such a
function value -- we should use nil instead.  (And likewise for the
always-true predicate being discussed here.)

But my main gripe is about options whose values can only be functions,
and nothing else.  No one will convince me that Emacs developers
cannot come up with meaningful values that aren't functions for some
option.

Re: Always-true predicate?

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

> But my main gripe is about options whose values can only be functions,
> and nothing else.  No one will convince me that Emacs developers
> cannot come up with meaningful values that aren't functions for some
> option.

Yeah, that's true.  Having nil/t values is often handy.  I guess the
only reason for not adding those is laziness.  I.e., every
implementation of these options end up looking like

(pcase foo-option
  ('nil nil)
  ('t t)
  (_ (funcall foo-option)))

or something.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

RE: [External] : Re: Always-true predicate?

[Drew Adams]

> > But my main gripe is about options whose values can only be
> > functions, and nothing else.  No one will convince me that
> > Emacs developers cannot come up with meaningful values that
> > aren't functions for some option.
> 
> Yeah, that's true.  Having nil/t values is often handy.
> I guess the only reason for not adding those is laziness.

I generally agree with where I think you're both
heading (converging).

I'll add this to what Eli said about there being
a difference between having an option whose only
possible values are functions and one that allows
a function value but also allows some other values
(with which I agree):

The typical case for a function-only option is for
the default value to be a named function.  Eli's
point is that if you want to change the option
value then you need to provide a function name or
a lambda form.  Error prone (for lambda) and can
require some Elisp knowledge (for lambda).

But it's also possible for more than one named
function to be predefined and mentioned in the
doc string.  In that case, picking one of _those_
names is not very different from the defcustom
providing a `choice' that includes values that
correspond to those names (as well as a catch-all
arbitrary function choice).

Re: Always-true predicate?

[Stefan Monnier]

>> And then we have this annoyance from "C-h v" as well:
>>
>>   read-extended-command-predicate is a variable defined in ‘simple.el’.
>>   Its value is
>>   #f(compiled-function
>>   (s b)
>>   #<bytecode 0x5a5068802147c83>)
>>
>> That's not very useful display for a user option.
>
> That's what prompted my query about adding something like `always'.
> (Although I've been missing the predicate for years.)

I love functions, and am in no small part to blame for the use of
functions like `ignore` as default value of variables (more often
`defvar` than `defcustom`, but still), but indeed giving name to those
functions is important: it's not just that `always` saves a few bytes
over `(lambda (&rest _) t)` in the `.el` file (and then again in the
`.elc` and in RAM), but also that `C-h v` gives more readable output
(and if that value ever finds its way elsewhere, you can easily jump to
its definition).

> I think using function values in user options is fine -- the Emacs
> developers can never get cover all behavioural permutations that people
> would like to see, so allowing them to supply their own code is helpful.

I fully agree.  But Eli is right that there's a tension and we should be
careful not to use too often (and we should work at trying to make sure
you don't need to know those functions when working with those vars,
which is already taken care of in `customize-variables` but not in
`set-variable`).


        Stefan

Re: Always-true predicate?

[Lars Ingebrigtsen]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

> I love functions, and am in no small part to blame for the use of
> functions like `ignore` as default value of variables (more often
> `defvar` than `defcustom`, but still), but indeed giving name to those
> functions is important: it's not just that `always` saves a few bytes
> over `(lambda (&rest _) t)` in the `.el` file (and then again in the
> `.elc` and in RAM), but also that `C-h v` gives more readable output
> (and if that value ever finds its way elsewhere, you can easily jump to
> its definition).

So we have some people for it, and some against it. If I read Eli
correctly, he was not strictly speaking against it, but more worried
that its presence would lead to more pure-predicate user options in
general.  I agree that those should be avoided, but `always' is still a
handy, obvious value that should be available in the users' repertoire
when constructing their own predicates (like with `ignore').

So I've now added it to Emacs 28.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: Always-true predicate?

[Lars Ingebrigtsen]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> So I've now added it to Emacs 28.

(But I did not make it interactive.  `ignore' is interactive, so making
`always' also be interactive seems tempting, just from a symmetry point
of view, but...)

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: Always-true predicate?

[Stefan Monnier]

>> So I've now added it to Emacs 28.
> (But I did not make it interactive.  `ignore' is interactive, so making
> `always' also be interactive seems tempting, just from a symmetry point
> of view, but...)

`ignore` is interactive because it's handy for key-bindings where you
want a given key sequence to be silently thrown away (as opposed to
using nil which leaves other maps to decide what to do, and `undefined`
which prevents other maps from giving it a meaning).
It might even have been the original motivation for the `ignore` function.

I don't see such a use for `always`, OTOH.  So better leave it
non-interactive.


        Stefan

Re: Always-true predicate?

[Lars Ingebrigtsen]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

> `ignore` is interactive because it's handy for key-bindings where you
> want a given key sequence to be silently thrown away (as opposed to
> using nil which leaves other maps to decide what to do, and `undefined`
> which prevents other maps from giving it a meaning).
> It might even have been the original motivation for the `ignore` function.

Right.  It popped up a few minutes ago for me in `eww-mode-map' (see
latest message in the "Current mode command discovery" thread)...

I wonder whether we should have a different convenient way to do this,
because keys that silently do nothing doesn't seem ideal?

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: Always-true predicate?

[Stefan Monnier]

> I wonder whether we should have a different convenient way to do this,
> because keys that silently do nothing doesn't seem ideal?

Maybe a good `grep` would tell us all the cases where it's useful, but
the ones I'm aware of are when we bind `down-mouse-N` to ignore so as to
hide the global binding and let the subsequent `mouse-N` do the actual
job (or vice versa).


        Stefan

Re: Always-true predicate?

[Lars Ingebrigtsen]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

> Maybe a good `grep` would tell us all the cases where it's useful, but
> the ones I'm aware of are when we bind `down-mouse-N` to ignore so as to
> hide the global binding and let the subsequent `mouse-N` do the actual
> job (or vice versa).

Ah, right.  That sounds like a good usage of ignore.  I'm not sure about
these:

./lisp/vc/vc-bzr.el1013:    (define-key map [mouse-2] 'ignore)
./lisp/wdired.el172:    (define-key map "\C-m"     'ignore)
./lisp/wdired.el173:    (define-key map "\C-j"     'ignore)
./lisp/wdired.el174:    (define-key map "\C-o"     'ignore)
./lisp/mpc.el1121:    (define-key map [header-line follow-link] 'ignore)
./lisp/mpc.el1122:    (define-key map [mode-line follow-link] 'ignore)
./lisp/ido.el1632:	 (define-key map "\C-x\C-d" 'ignore))


-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: Always-true predicate?

[Stefan Monnier]

> ./lisp/wdired.el172:    (define-key map "\C-m"     'ignore)
> ./lisp/wdired.el173:    (define-key map "\C-j"     'ignore)
> ./lisp/wdired.el174:    (define-key map "\C-o"     'ignore)

Don't know about these.  Maybe `undefined` would be more appropriate?

> ./lisp/mpc.el1121:    (define-key map [header-line follow-link] 'ignore)
> ./lisp/mpc.el1122:    (define-key map [mode-line follow-link] 'ignore)

`follow-link` bindings contain functions/predicates, rather than
commands, IIRC, so this looks sane.

> ./lisp/ido.el1632:	 (define-key map "\C-x\C-d" 'ignore))

No idea about this one either.


        Stefan

Re: Always-true predicate?

[Robert Pluim]

>>>>> On Sat, 20 Feb 2021 10:21:47 -0500, Stefan Monnier <monnier@iro.umontreal.ca> said:

    >> ./lisp/wdired.el172:    (define-key map "\C-m"     'ignore)
    >> ./lisp/wdired.el173:    (define-key map "\C-j"     'ignore)
    >> ./lisp/wdired.el174:    (define-key map "\C-o"     'ignore)

    Stefan> Don't know about these.  Maybe `undefined` would be more appropriate?

That would signal an error if the user pressed them, no? Maybe you can
ask Stefan-from-2005:

commit a8f8c39013d510311c8bdcab9a943e23526372ae
Author: Stefan Monnier <monnier@iro.umontreal.ca>
Date:   Mon Apr 11 19:01:31 2005 +0000

    Doc fixes.
    (wdired-confirm-overwrite): Rename from wdired-is-ok-overwrite.
    (wdired-use-dired-vertical-movement): Rename from
    wdired-always-move-to-filename-beginning.
    (wdired-mode-map): Use `ignore' instead of `wdired-newline'.
    (wdired-change-to-wdired-mode): Change mode name.
    (wdired-newline): Delete.

diff --git a/lisp/wdired.el b/lisp/wdired.el
--- a/lisp/wdired.el
+++ b/lisp/wdired.el
@@ -236,3 +181,3 @@
-    (define-key map "\C-m"     'wdired-newline)
-    (define-key map "\C-j"     'wdired-newline)
-    (define-key map "\C-o"     'wdired-newline)
+    (define-key map "\C-m"     'ignore)
+    (define-key map "\C-j"     'ignore)
+    (define-key map "\C-o"     'ignore)

Re: Always-true predicate?

[Lars Ingebrigtsen]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> ./lisp/wdired.el172:    (define-key map "\C-m"     'ignore)
>> ./lisp/wdired.el173:    (define-key map "\C-j"     'ignore)
>> ./lisp/wdired.el174:    (define-key map "\C-o"     'ignore)
>
> Don't know about these.  Maybe `undefined` would be more appropriate?

They were introduced by this patch from somebody I've never heard of
before:

commit a8f8c39013d510311c8bdcab9a943e23526372ae
Author:     Stefan Monnier <monnier@iro.umontreal.ca>
AuthorDate: Mon Apr 11 19:01:31 2005 +0000

-    (define-key map "\C-m"     'wdired-newline)
-    (define-key map "\C-j"     'wdired-newline)
-    (define-key map "\C-o"     'wdired-newline)
+    (define-key map "\C-m"     'ignore)
+    (define-key map "\C-j"     'ignore)
+    (define-key map "\C-o"     'ignore)
...
-(defun wdired-newline ()
-  "Do nothing."
-  (interactive))

But I think `undefined' is more correct here, so I've now changed it.

>> ./lisp/ido.el1632:	 (define-key map "\C-x\C-d" 'ignore))
>
> No idea about this one either.

Me neither.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: Always-true predicate?

[Stefan Kangas]

Eli Zaretskii <eliz@gnu.org> writes:

>> Could you elaborate on how it makes it harder to customize?
>
> Isn't it clear that typing a function at set-variable's prompt is much
> less convenient than typing an atom, like a symbol, a string, or a
> number?  For starters, it is much more typing.  And then it's easy to
> make a mistake, which will require you to start over again.

Oh, sorry I misunderstood you.  I thought we only talked about
"customizing" in reference to `customize'.

> Customization is about _changing_ the defaults, not about leaving them
> unchanged.  Typing a function's name, let alone a lambda-expression,
> in the Custom form is no fun.  So having a user option whose value
> _must_ be a function is a PITA.

Yes, that's true.

Re: Always-true predicate?

[Eli Zaretskii]

> From: Stefan Kangas <stefankangas@gmail.com>
> Date: Fri, 19 Feb 2021 09:09:25 -0600
> Cc: rpluim@gmail.com, larsi@gnus.org, rms@gnu.org, emacs-devel@gnu.org
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> Could you elaborate on how it makes it harder to customize?
> >
> > Isn't it clear that typing a function at set-variable's prompt is much
> > less convenient than typing an atom, like a symbol, a string, or a
> > number?  For starters, it is much more typing.  And then it's easy to
> > make a mistake, which will require you to start over again.
> 
> Oh, sorry I misunderstood you.  I thought we only talked about
> "customizing" in reference to `customize'.

I almost never use "M-x customize" for variables, as set-variable is
so much easier and faster.  I expect many veteran users do the same.

RE: [External] : Re: Always-true predicate?

[Drew Adams]

> I almost never use "M-x customize" for variables, as set-variable is
> so much easier and faster.  I expect many veteran users do the same.

`M-x customize-set-variable' is better, as
`set-variable' doesn't know/care about :set etc.
___

https://lists.gnu.org/archive/html/emacs-devel/2017-11/msg00685.html

https://lists.gnu.org/archive/html/emacs-devel/2017-12/msg00048.html

Re: [External] : Re: Always-true predicate?

[Eli Zaretskii]

> From: Drew Adams <drew.adams@oracle.com>
> CC: "rpluim@gmail.com" <rpluim@gmail.com>,
>         "emacs-devel@gnu.org"
> 	<emacs-devel@gnu.org>,
>         "larsi@gnus.org" <larsi@gnus.org>, "rms@gnu.org"
> 	<rms@gnu.org>
> Date: Fri, 19 Feb 2021 18:17:53 +0000
> 
> > I almost never use "M-x customize" for variables, as set-variable is
> > so much easier and faster.  I expect many veteran users do the same.
> 
> `M-x customize-set-variable' is better, as
> `set-variable' doesn't know/care about :set etc.

Most options don't have a setter, so "better" is nowhere near the
truth.

Re: Always-true predicate?

[chad]

[-- Attachment #1: Type: text/plain, Size: 2257 bytes --]

On Fri, Feb 19, 2021 at 1:10 AM Eli Zaretskii <eliz@gnu.org> wrote:

> I must diverge somewhat here, and express my uneasiness, to say the
> least, with the recent-ish fashion of making too many user options
> have function values.  It makes "M-x set-variable" much less
> convenient than it should be, and it makes customizing such options
> harder for users who aren't proficient in Lisp.  We should limit such
> option values to the absolute minimum, IMO.  I'd very much prefer to
> have simple atomic values (symbols, numbers, or strings) that are then
> interpreted by the relevant commands to run the necessary code or call
> out to necessary subroutines to do the job.  I feel that some of us
> think that putting functions with the necessary code directly in the
> option's value is somehow "cleaner" or "more elegant".  I disagree.
>

I suspect that I ran into an instance of this recently, where the helpful
package (an extension that offers expanded help functions, basically) had
trouble in it's helpful-callable function with facemenu-face-menu. I
tracked the problem down to a bad interaction in helpful with this code in
facemenu.el:

(defvar facemenu-face-menu
>   [...])
> (defalias 'facemenu-face-menu facemenu-face-menu)


The problem that I get is:

Debugger entered--Lisp error: (wrong-type-argument sequencep t)
>   mapconcat(identity (t) " ")
>   s-join(" " (t))
>   helpful--signature(facemenu-face-menu)
>   helpful-update()
>   helpful-callable(facemenu-face-menu)
>   funcall-interactively(helpful-callable facemenu-face-menu)
>   call-interactively(helpful-callable nil nil)
>   command-execute(helpful-callable)


I'm not familiar with the (defalias 'foo foo) idiom, so maybe it should be
expected to work, and it's just a bug in helpful. (I reported it to the
package maintainers already, with a note that I'd mention it here.) There
are a few other instances of in emacs that I found with a quick search, and
they also cause similar trouble for helpful.

Is this an example of an accidental functional value, as I originally
expected, or am I barking up the wrong tree and instead just looking at a
parsing bug? (My lisp is largely self taught and started with Scheme, so
these parts of elisp are murky to me.)

Thanks,
~Chad

[-- Attachment #2: Type: text/html, Size: 3149 bytes --]

Re: Always-true predicate?

[Eli Zaretskii]

> From: chad <yandros@gmail.com>
> Date: Sun, 21 Feb 2021 21:02:43 -0800
> Cc: Robert Pluim <rpluim@gmail.com>, Lars Ingebrigtsen <larsi@gnus.org>, Richard Stallman <rms@gnu.org>, 
> 	EMACS development team <emacs-devel@gnu.org>
> 
> I suspect that I ran into an instance of this recently, where the helpful package (an extension that offers
> expanded help functions, basically) had trouble in it's helpful-callable function with facemenu-face-menu. I
> tracked the problem down to a bad interaction in helpful with this code in facemenu.el:
> 
>  (defvar facemenu-face-menu
>    [...])
>  (defalias 'facemenu-face-menu facemenu-face-menu)
> 
> The problem that I get is:
> 
>  Debugger entered--Lisp error: (wrong-type-argument sequencep t)
>    mapconcat(identity (t) " ")
>    s-join(" " (t))
>    helpful--signature(facemenu-face-menu)
>    helpful-update()
>    helpful-callable(facemenu-face-menu)
>    funcall-interactively(helpful-callable facemenu-face-menu)
>    call-interactively(helpful-callable nil nil)
>    command-execute(helpful-callable)
> 
> I'm not familiar with the (defalias 'foo foo) idiom, so maybe it should be expected to work, and it's just a bug
> in helpful. (I reported it to the package maintainers already, with a note that I'd mention it here.) There are a
> few other instances of in emacs that I found with a quick search, and they also cause similar trouble for
> helpful.
> 
> Is this an example of an accidental functional value, as I originally expected, or am I barking up the wrong
> tree and instead just looking at a parsing bug? (My lisp is largely self taught and started with Scheme, so
> these parts of elisp are murky to me.)

I think it's a bug in helpful: facemenu-face-menu is a keymap, so
maybe helpful isn't ready for that.

Re: Always-true predicate?

[chad]

[-- Attachment #1: Type: text/plain, Size: 2955 bytes --]

On Mon, Feb 22, 2021 at 7:21 AM Eli Zaretskii <eliz@gnu.org> wrote:

> > From: chad <yandros@gmail.com>
> > Date: Sun, 21 Feb 2021 21:02:43 -0800
> > Cc: Robert Pluim <rpluim@gmail.com>, Lars Ingebrigtsen <larsi@gnus.org>,
> Richard Stallman <rms@gnu.org>,
> >       EMACS development team <emacs-devel@gnu.org>
> >
> > I suspect that I ran into an instance of this recently, where the
> helpful package (an extension that offers
> > expanded help functions, basically) had trouble in it's helpful-callable
> function with facemenu-face-menu. I
> > tracked the problem down to a bad interaction in helpful with this code
> in facemenu.el:
> >
> >  (defvar facemenu-face-menu
> >    [...])
> >  (defalias 'facemenu-face-menu facemenu-face-menu)
> >
> > The problem that I get is:
> >
> >  Debugger entered--Lisp error: (wrong-type-argument sequencep t)
> >    mapconcat(identity (t) " ")
> >    s-join(" " (t))
> >    helpful--signature(facemenu-face-menu)
> >    helpful-update()
> >    helpful-callable(facemenu-face-menu)
> >    funcall-interactively(helpful-callable facemenu-face-menu)
> >    call-interactively(helpful-callable nil nil)
> >    command-execute(helpful-callable)
> >
> > I'm not familiar with the (defalias 'foo foo) idiom, so maybe it should
> be expected to work, and it's just a bug
> > in helpful. (I reported it to the package maintainers already, with a
> note that I'd mention it here.) There are a
> > few other instances of in emacs that I found with a quick search, and
> they also cause similar trouble for
> > helpful.
> >
> > Is this an example of an accidental functional value, as I originally
> expected, or am I barking up the wrong
> > tree and instead just looking at a parsing bug? (My lisp is largely self
> taught and started with Scheme, so
> > these parts of elisp are murky to me.)
>
> I think it's a bug in helpful: facemenu-face-menu is a keymap, so
> maybe helpful isn't ready for that.
>

Good point; I didn't (but should have) say: the issue, I think, is that the
use of defalias makes helpful-callable think that facemenu-face-menu is a
"viable callable", when it isn't. This doesn't mean that it's not a bug in
helpful, of course; I'm just trying to understand if the bug is that
helpful should be able to tell that facemenu-face-menu isn't "callable".
Here's the start of helpful-callable, fwiw:

(defun helpful-callable (symbol)
>   "Show help for function, macro or special form named SYMBOL.
>


See also `helpful-macro', `helpful-function' and `helpful-command'."
>   (interactive
>    (list (helpful--read-symbol
>           "Callable: "
>           (helpful--callable-at-point)
>           #'fboundp)))


helpful--read-symbol seems to be a simple porcelain around completing-read
with, in this case, #'fboundp as the predicate. That said, I'm not sure if
this is just a bug in helpful being confused by the idiom with defalias,
via the function-value usage you mentioned upthread.

Thanks,
~Chad

[-- Attachment #2: Type: text/html, Size: 4461 bytes --]

Re: Always-true predicate?

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

You asked

                                           what's wrong with
  > #'pretend-to-pay-attention?

That is the wrong question, the wrong way to think about a proposed
feature.  It presupposes a policy of adding every possible feature,
unless there is "something wrong with it".  That leads to more and
more bloat.

Every feature, even a trivial one, implies more complexity -- not just
in code, which is the least burdensome, but in documentation, and in
what users need to know.  The size of the Emacs Lisp Reference Manual
is a problem we can measure.

To keep bloat in check, we must insist that any new feature be
justified by benefit.

I am sure there will be occasions to use this proposed function.  Will
they be frequent enough to make it worth while?  My judgment says they
won't be.

It is possible to make an estimate based on more knowledge.
The files lisp/c*.el add up to around 20,000 lines.  Since they are
unrelated in purpose and history, they would make a good sample.  How
about looking through those files for places where using
always-return-t would make the code cleaner?

If you find quite a few in that sample, that would start to support
adding this feature.  However, there would also be the question of
_how much_ cleaner the code would be in each place.


In regard to user options whose values are functions,
I think it is good to allow nil and t as values.
That would be cleaner than setting the option to `ignore'
or always-return-t.

-- 
Dr Richard Stallman
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: Always-true predicate?

[Eli Zaretskii]

> From: Richard Stallman <rms@gnu.org>
> Date: Sun, 21 Feb 2021 01:12:04 -0500
> Cc: larsi@gnus.org, emacs-devel@gnu.org
> 
> In regard to user options whose values are functions,
> I think it is good to allow nil and t as values.
> That would be cleaner than setting the option to `ignore'
> or always-return-t.

In addition, any other atoms -- symbols, numbers, strings -- are
easier to type and easier for users to customize in their init files.