* bug#73853: 31.0.50; and-let* is useless
@ 2024-10-17 16:27 Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-10-17 16:40 ` Drew Adams via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-10-18 2:11 ` Michael Heerdegen via Bug reports for GNU Emacs, the Swiss army knife of text editors
0 siblings, 2 replies; 7+ messages in thread
From: Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2024-10-17 16:27 UTC (permalink / raw)
To: 73853; +Cc: monnier
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
^ permalink raw reply [flat|nested] 7+ messages in thread
* bug#73853: 31.0.50; and-let* is useless
2024-10-17 16:27 bug#73853: 31.0.50; and-let* is useless Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
@ 2024-10-17 16:40 ` Drew Adams via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-10-18 2:11 ` Michael Heerdegen via Bug reports for GNU Emacs, the Swiss army knife of text editors
1 sibling, 0 replies; 7+ messages in thread
From: Drew Adams via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2024-10-17 16:40 UTC (permalink / raw)
To: Stefan Monnier, 73853@debbugs.gnu.org
> [ 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? ;-))
^ permalink raw reply [flat|nested] 7+ messages in thread
* bug#73853: 31.0.50; and-let* is useless
2024-10-17 16:27 bug#73853: 31.0.50; and-let* is useless Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-10-17 16:40 ` Drew Adams via Bug reports for GNU Emacs, the Swiss army knife of text editors
@ 2024-10-18 2:11 ` Michael Heerdegen via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-10-18 23:42 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-10-19 3:38 ` Sean Whitton
1 sibling, 2 replies; 7+ messages in thread
From: Michael Heerdegen via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2024-10-18 2:11 UTC (permalink / raw)
To: 73853; +Cc: monnier
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.
^ permalink raw reply [flat|nested] 7+ messages in thread
* bug#73853: 31.0.50; and-let* is useless
2024-10-18 2:11 ` Michael Heerdegen via Bug reports for GNU Emacs, the Swiss army knife of text editors
@ 2024-10-18 23:42 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-10-19 3:50 ` Michael Heerdegen via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-10-19 3:38 ` Sean Whitton
1 sibling, 1 reply; 7+ messages in thread
From: Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2024-10-18 23:42 UTC (permalink / raw)
To: Michael Heerdegen; +Cc: 73853
>> 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
^ permalink raw reply [flat|nested] 7+ messages in thread
* bug#73853: 31.0.50; and-let* is useless
2024-10-18 2:11 ` Michael Heerdegen via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-10-18 23:42 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
@ 2024-10-19 3:38 ` Sean Whitton
2024-10-20 12:24 ` Stefan Kangas
1 sibling, 1 reply; 7+ messages in thread
From: Sean Whitton @ 2024-10-19 3:38 UTC (permalink / raw)
To: 73853; +Cc: Michael Heerdegen, monnier
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
^ permalink raw reply [flat|nested] 7+ messages in thread
* bug#73853: 31.0.50; and-let* is useless
2024-10-18 23:42 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
@ 2024-10-19 3:50 ` Michael Heerdegen via Bug reports for GNU Emacs, the Swiss army knife of text editors
0 siblings, 0 replies; 7+ messages in thread
From: Michael Heerdegen via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2024-10-19 3:50 UTC (permalink / raw)
To: Stefan Monnier; +Cc: 73853
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.
^ permalink raw reply [flat|nested] 7+ messages in thread
* bug#73853: 31.0.50; and-let* is useless
2024-10-19 3:38 ` Sean Whitton
@ 2024-10-20 12:24 ` Stefan Kangas
0 siblings, 0 replies; 7+ messages in thread
From: Stefan Kangas @ 2024-10-20 12:24 UTC (permalink / raw)
To: Sean Whitton, 73853; +Cc: Michael Heerdegen, monnier
Sean Whitton <spwhitton@spwhitton.name> writes:
> I would like us to move forward with removing the non-star ones.
I also agree that removing them would make sense.
^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2024-10-20 12:24 UTC | newest]
Thread overview: 7+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2024-10-17 16:27 bug#73853: 31.0.50; and-let* is useless Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-10-17 16:40 ` Drew Adams via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-10-18 2:11 ` Michael Heerdegen via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-10-18 23:42 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-10-19 3:50 ` Michael Heerdegen via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-10-19 3:38 ` Sean Whitton
2024-10-20 12:24 ` Stefan Kangas
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).