Re: Always-true predicate?

[Stefan Monnier <monnier@iro.umontreal.ca>]

>> > 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