bug#73853: 31.0.50; and-let* is useless

bug#73853: 31.0.50; and-let* is useless

[Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Package: Emacs
Version: 31.0.50


According to its docstring, `and-let*` does:

    Bind variables according to VARLIST and conditionally evaluate BODY.
    Like `when-let*', except if BODY is empty and all the bindings
    are non-nil, then the result is the value of the last binding.

IOW the only time it's different from `when-let*` is when BODY is empty,
i.e. its only "feature" compares to `when-let*` is that

    (and-let* (..BINDINGS..
               (last (binding))))

is equivalent to

    (and-let* (..BINDINGS..)
      (binding))

Why would anyone write the first instead of the second, other than out
of masochism?  Can we kill/deprecate this?
[ I think we have too many (if|when|and)-let(*) for our own good: we
  should pick some winners and deprecate the other ones.   ]

I could see a use for something called `and-let(*)` but without a BODY,
for the purpose of remove a level of parens and indentation:

    (and-let*
      (x1 (foo1))
      (x2 (foo2)))

i.s.o

    (and-let*
        ((x1 (foo1))
         (x2 (foo2))))


- Stefan

bug#73853: 31.0.50; and-let* is useless

[Drew Adams via Bug reports for GNU Emacs, the Swiss army knife of text editors]

> [ I think we have too many (if|when|and)-let(*) for our own good: we
>   should pick some winners and deprecate the other ones.   ]

+1.

(Are there really any winners? ;-))

bug#73853: 31.0.50; and-let* is useless

[Michael Heerdegen via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Stefan Monnier via "Bug reports for GNU Emacs, the Swiss army knife of
text editors" <bug-gnu-emacs@gnu.org> writes:

> Can we kill/deprecate this?

`and-let*'s purpose is to express conditions, `when-let*'s is
conditional evaluation.  We have `and-let*' and `when-let*' for the same
reason we have `and' and `when'.  See prior discussions.

> [ I think we have too many (if|when|and)-let(*) for our own good: we
>   should pick some winners and deprecate the other ones.   ]

AFAIR the non-star versions exist for backward compatibility only - so I
would rather get rid of these.  Parallel existence of these non-star
vs. star versions should be a temporary state, it complicates the matter
for an epsilon gain.

> I could see a use for something called `and-let(*)` but without a BODY,
> for the purpose of remove a level of parens and indentation:
>
>     (and-let*
>       (x1 (foo1))
>       (x2 (foo2)))
>
> i.s.o
>
>     (and-let*
>         ((x1 (foo1))
>          (x2 (foo2))))

Ugh! - I could not imagine anything with more potential for confusion as
removing the paren around a list of bindings.  This would add one more
year-lasting round of discussing these constructs.  If you do this,
please call it `and-let*?@!' so than everybody is warned.


Michael.

bug#73853: 31.0.50; and-let* is useless

[Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors]

>> Can we kill/deprecate this?
> `and-let*'s purpose is to express conditions, `when-let*'s is
> conditional evaluation.  We have `and-let*' and `when-let*' for the same
> reason we have `and' and `when'.  See prior discussions.

But there isn't the same "historical" support that justifies having
both, and the syntax&semantics of `and-let*` is just weird:

- Why allow a BODY if the motivation is to mirror the normal `and`?
  If you want a BODY, use `when-let*`.
- What's the use of the final variable binding since (assuming you
  don't use BODY) that variable is never used:

     (and-let* ((a (fooa))
                (b (foob a))
                (i-m-useless (fooc a b))))

- There's a special syntax where the final binding can drop the variable
  name (because of the previous point), which makes for an odd syntax

     (and-let* ((a (fooa))
                (b (foob a))
                ((weird-call a b))))

So the use with BODY is redundant with `when-let*` and the use without
BODY is quirky (and still redundant with `when-let*`, of course).

>> [ I think we have too many (if|when|and)-let(*) for our own good: we
>>   should pick some winners and deprecate the other ones.   ]
> AFAIR the non-star versions exist for backward compatibility only - so I
> would rather get rid of these.  Parallel existence of these non-star
> vs. star versions should be a temporary state, it complicates the matter
> for an epsilon gain.

100% agreement.  Can we `make-obsolete` the non-star versions?

>> I could see a use for something called `and-let(*)` but without a BODY,
>> for the purpose of remove a level of parens and indentation:
>>
>>     (and-let*
>>       (x1 (foo1))
>>       (x2 (foo2)))
>>
>> i.s.o
>>
>>     (and-let*
>>         ((x1 (foo1))
>>          (x2 (foo2))))
>
> Ugh! - I could not imagine anything with more potential for confusion as
> removing the paren around a list of bindings.

FWIW, I agree, I don't like that either.


        Stefan

bug#73853: 31.0.50; and-let* is useless

[Michael Heerdegen via Bug reports for GNU Emacs, the Swiss army knife of text editors]

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

> But there isn't the same "historical" support that justifies having
> both, and the syntax&semantics of `and-let*` is just weird:
>
> - Why allow a BODY if the motivation is to mirror the normal `and`?
>   If you want a BODY, use `when-let*`.
> - What's the use of the final variable binding since (assuming you
>   don't use BODY) that variable is never used:
>
>      (and-let* ((a (fooa))
>                 (b (foob a))
>                 (i-m-useless (fooc a b))))

One could say BODY _is_ the final condition and therefore it has a
special syntax because it necessarily doesn't need a binding.  That way
I've my peace with that syntax.

Anyway, removing `and-let*' would be equally unsatisfying, and
obviously, at least one the two points will remain unless we change
the syntax radically - or remove `and-let*' :-(

> - There's a special syntax where the final binding can drop the variable
>   name (because of the previous point), which makes for an odd syntax
>
>      (and-let* ((a (fooa))
>                 (b (foob a))
>                 ((weird-call a b))))

That I feel too.  As an alternative we made the pseudo variable _ work
without compiler warnings.  But one gets used to the variable-less
syntax.  It's too handy...

> So the use with BODY is redundant with `when-let*` and the use without
> BODY is quirky (and still redundant with `when-let*`, of course).

I see your points, but don't consider them as such a big problem.
Anyway, without having something that is obviously better the discussion
remains quite philosophical.  And replacing calls of `and-let*' with
equivalent calls of `when-let*' doesn't make code easier to read, IMO.

> 100% agreement.  Can we `make-obsolete` the non-star versions?

I hope we can.


Michael.

bug#73853: 31.0.50; and-let* is useless

[Sean Whitton]

Hello,

On Fri 18 Oct 2024 at 04:11am +02, Michael Heerdegen via "Bug reports for GNU Emacs, the Swiss army knife of text editors" wrote:

> `and-let*'s purpose is to express conditions, `when-let*'s is
> conditional evaluation.  We have `and-let*' and `when-let*' for the
> same reason we have `and' and `when'.  See prior discussions.

Right.  The Lisp convention of using `when' for pure control flow and
`and' for returning values is a good aid to readability.

If we don't have and-let*, then we can't use this convention in the case
that we also want to bind variables.

So, I am very keen for and-let* to remain.

>> [ I think we have too many (if|when|and)-let(*) for our own good: we
>>   should pick some winners and deprecate the other ones.   ]
>
> AFAIR the non-star versions exist for backward compatibility only - so
> I would rather get rid of these.  Parallel existence of these non-star
> vs. star versions should be a temporary state, it complicates the
> matter for an epsilon gain.

Yes.  I would like us to move forward with removing the non-star ones.

I believe there was a previous attempt to deprecate them but it had to
be backed out.  But maybe now is the time to try again.

-- 
Sean Whitton