GNU bug report logs -
#73853
Should and-let* become a synonym for when-let*?
Previous Next
To reply to this bug, email your comments to 73853 AT debbugs.gnu.org.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
monnier <at> iro.umontreal.ca, bug-gnu-emacs <at> gnu.org:
bug#73853; Package
emacs.
(Thu, 17 Oct 2024 16:31:02 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Stefan Monnier <monnier <at> iro.umontreal.ca>:
New bug report received and forwarded. Copy sent to
monnier <at> iro.umontreal.ca, bug-gnu-emacs <at> gnu.org.
(Thu, 17 Oct 2024 16:31:02 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
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
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#73853; Package
emacs.
(Thu, 17 Oct 2024 16:41:02 GMT)
Full text and
rfc822 format available.
Message #8 received at 73853 <at> debbugs.gnu.org (full text, mbox):
> [ 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? ;-))
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#73853; Package
emacs.
(Fri, 18 Oct 2024 02:12:01 GMT)
Full text and
rfc822 format available.
Message #11 received at submit <at> debbugs.gnu.org (full text, mbox):
Stefan Monnier via "Bug reports for GNU Emacs, the Swiss army knife of
text editors" <bug-gnu-emacs <at> 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.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#73853; Package
emacs.
(Fri, 18 Oct 2024 02:12:02 GMT)
Full text and
rfc822 format available.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#73853; Package
emacs.
(Fri, 18 Oct 2024 23:44:01 GMT)
Full text and
rfc822 format available.
Message #17 received at 73853 <at> debbugs.gnu.org (full text, mbox):
>> 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
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#73853; Package
emacs.
(Sat, 19 Oct 2024 03:39:02 GMT)
Full text and
rfc822 format available.
Message #20 received at 73853 <at> debbugs.gnu.org (full text, mbox):
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
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#73853; Package
emacs.
(Sat, 19 Oct 2024 03:51:02 GMT)
Full text and
rfc822 format available.
Message #23 received at 73853 <at> debbugs.gnu.org (full text, mbox):
Stefan Monnier <monnier <at> 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.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#73853; Package
emacs.
(Sun, 20 Oct 2024 12:26:02 GMT)
Full text and
rfc822 format available.
Message #26 received at 73853 <at> debbugs.gnu.org (full text, mbox):
Sean Whitton <spwhitton <at> 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.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#73853; Package
emacs.
(Mon, 21 Oct 2024 07:09:01 GMT)
Full text and
rfc822 format available.
Message #29 received at submit <at> debbugs.gnu.org (full text, mbox):
On Fri, 18 Oct 2024 at 19:42, Stefan Monnier via "Bug reports for GNU Emacs, the Swiss army knife of text editors" wrote:
>>> [ 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?
Wait... The point of make-obsolete is to generate warning so people
migrate their code, right? So why not warn on the weird
(single-variable binding) use of the non-star version, to eventually
remove that syntax as well as the star variants?
I always type `if-let' because it looks cleaner and saves one indentation
column (which are purely cosmetic reasons), but also I think it would be
weird to have a something* when there's no accompanying something.
>>> 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.
Sure, I guess nobody wants that, but this idea is getting closer to a
`thread-while' macro (variation of `thread-as') which I still maintain
would be really handy (much more so than the existing ones, which are
limited by the inconsistency of the argument ordering in Elisp).
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#73853; Package
emacs.
(Mon, 21 Oct 2024 07:10:01 GMT)
Full text and
rfc822 format available.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#73853; Package
emacs.
(Mon, 21 Oct 2024 08:58:01 GMT)
Full text and
rfc822 format available.
Message #35 received at 73853 <at> debbugs.gnu.org (full text, mbox):
Augusto Stoffel <arstoffel <at> gmail.com> writes:
> I always type `if-let' because it looks cleaner and saves one indentation
> column (which are purely cosmetic reasons), but also I think it would be
> weird to have a something* when there's no accompanying something.
Good point, we should decide which names to use. Personally i prefer
the names ending with star, because bindings are not parallel as in
`let'. But we also already spoke about this. Dunno which names are
more popular, it's a matter of taste.
Michael.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#73853; Package
emacs.
(Mon, 21 Oct 2024 09:00:01 GMT)
Full text and
rfc822 format available.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#73853; Package
emacs.
(Mon, 21 Oct 2024 12:10:02 GMT)
Full text and
rfc822 format available.
Message #41 received at 73853 <at> debbugs.gnu.org (full text, mbox):
Hello,
On Mon 21 Oct 2024 at 10:57am +02, Michael Heerdegen via "Bug reports for GNU Emacs, the Swiss army knife of text editors" wrote:
> Augusto Stoffel <arstoffel <at> gmail.com> writes:
>
>> I always type `if-let' because it looks cleaner and saves one indentation
>> column (which are purely cosmetic reasons), but also I think it would be
>> weird to have a something* when there's no accompanying something.
>
> Good point, we should decide which names to use. Personally i prefer
> the names ending with star, because bindings are not parallel as in
> `let'. But we also already spoke about this. Dunno which names are
> more popular, it's a matter of taste.
I prefer if-let* for this reason too. Also:
- it informs a reader that there is no way they are going to see the
unusual single binding syntax.
- Common Lisp's ubiquitous Alexandria library of basic utilities has an
if-let which has the unusual single binding syntax. In fact, that is
probably where our if-let came from. So if we are moving away from
that, it makes sense to use a different name for the thing we
invented -- if-let*.
--
Sean Whitton
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#73853; Package
emacs.
(Tue, 22 Oct 2024 14:49:02 GMT)
Full text and
rfc822 format available.
Message #44 received at 73853 <at> debbugs.gnu.org (full text, mbox):
retitle 73853 Should and-let* become a synonym for when-let*?
thanks
Hello,
On Sun 20 Oct 2024 at 05:24am -07, Stefan Kangas wrote:
> Sean Whitton <spwhitton <at> 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.
I've found the old discussion on this:
- https://debbugs.gnu.org/cgi/bugreport.cgi?bug=60758#58
- https://lists.gnu.org/archive/html/emacs-devel/2018-03/msg00052.html
- https://lists.gnu.org/archive/html/emacs-devel/2018-03/msg00219.html
Based on my reading of this thread and those old discussions, I conclude
- it is fine to mark when-let and if-let as obsolete for Emacs 31, and
generally there's more of a consensus, and several good reasons, to do
that instead of removing if-let* and when-let*
- I'd like to go ahead and install a patch marking when-let and if-let
as obsolete, unless Michael is keen to be the one to do it as the
initiator of the previous effort
- enough people want to keep and-let*, but possibly some aspects of its
syntax should be removed
- I'm retitling the bug to reflect that.
--
Sean Whitton
Changed bug title to 'Should and-let* become a synonym for when-let*?' from '31.0.50; and-let* is useless'
Request was from
Sean Whitton <spwhitton <at> spwhitton.name>
to
control <at> debbugs.gnu.org.
(Tue, 22 Oct 2024 14:49:02 GMT)
Full text and
rfc822 format available.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#73853; Package
emacs.
(Tue, 22 Oct 2024 15:25:02 GMT)
Full text and
rfc822 format available.
Message #49 received at 73853 <at> debbugs.gnu.org (full text, mbox):
Sean Whitton <spwhitton <at> spwhitton.name> writes:
> retitle 73853 Should and-let* become a synonym for when-let*?
> thanks
Thanks for the fine summary.
> - I'd like to go ahead and install a patch marking when-let and if-let
> as obsolete, unless Michael is keen to be the one to do it as the
> initiator of the previous effort
He is not, feel free to go ahead when there are no objections from
others.
Michael.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#73853; Package
emacs.
(Wed, 23 Oct 2024 14:08:02 GMT)
Full text and
rfc822 format available.
Message #52 received at 73853 <at> debbugs.gnu.org (full text, mbox):
Michael Heerdegen <michael_heerdegen <at> web.de> writes:
> Sean Whitton <spwhitton <at> spwhitton.name> writes:
>
>> - I'd like to go ahead and install a patch marking when-let and if-let
>> as obsolete, unless Michael is keen to be the one to do it as the
>> initiator of the previous effort
>
> He is not, feel free to go ahead when there are no objections from
> others.
Sounds good, and thanks in advance.
Please also fix any new obsoletion warnings in our code.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#73853; Package
emacs.
(Thu, 24 Oct 2024 08:53:02 GMT)
Full text and
rfc822 format available.
Message #55 received at 73853 <at> debbugs.gnu.org (full text, mbox):
Hello,
On Wed 23 Oct 2024 at 07:05am -07, Stefan Kangas wrote:
> Michael Heerdegen <michael_heerdegen <at> web.de> writes:
>
>> Sean Whitton <spwhitton <at> spwhitton.name> writes:
>>
>>> - I'd like to go ahead and install a patch marking when-let and if-let
>>> as obsolete, unless Michael is keen to be the one to do it as the
>>> initiator of the previous effort
>>
>> He is not, feel free to go ahead when there are no objections from
>> others.
>
> Sounds good, and thanks in advance.
>
> Please also fix any new obsoletion warnings in our code.
Done. I will go ahead and update org-mode.git but I have not updated
any externally maintained code in emacs.git. I know that sometimes
changes get backported from emacs.git to external repos by maintainers,
but it doesn't seem ideal to make a large slew of changes they have to
backport. Let me know if you don't think that's right.
--
Sean Whitton
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#73853; Package
emacs.
(Fri, 25 Oct 2024 12:11:02 GMT)
Full text and
rfc822 format available.
Message #58 received at 73853 <at> debbugs.gnu.org (full text, mbox):
Hello,
On Thu 24 Oct 2024 at 04:51pm +08, Sean Whitton wrote:
> Done. I will go ahead and update org-mode.git but I have not updated
> any externally maintained code in emacs.git. I know that sometimes
> changes get backported from emacs.git to external repos by maintainers,
> but it doesn't seem ideal to make a large slew of changes they have to
> backport. Let me know if you don't think that's right.
Just to follow up here.
- Michael reports he is handling TRAMP in tramp.git and will import here
at an appropriate time.
- I've sent in a GitHub PR for Transient and requested a release, and an
eventual import to emacs.git.
- I've written to Ihor about Org-mode, and as I say, I committed a patch
to their trunk branch.
There are also some uses in the modus themes but we don't compile those,
so, it can be left to upstream to fix when they notice it.
So, in short, all remaining byte compiler warnings in emacs.git related
to this change are tracked somewhere and will get fixed soon.
--
Sean Whitton
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#73853; Package
emacs.
(Sat, 26 Oct 2024 19:28:02 GMT)
Full text and
rfc822 format available.
Message #61 received at 73853 <at> debbugs.gnu.org (full text, mbox):
On 10/22/2024 8:24 AM, Michael Heerdegen via Bug reports for GNU Emacs,
the Swiss army knife of text editors wrote:
> Sean Whitton <spwhitton <at> spwhitton.name> writes:
>
>> retitle 73853 Should and-let* become a synonym for when-let*?
>> thanks
>
> Thanks for the fine summary.
>
>> - I'd like to go ahead and install a patch marking when-let and if-let
>> as obsolete, unless Michael is keen to be the one to do it as the
>> initiator of the previous effort
>
> He is not, feel free to go ahead when there are no objections from
> others.
I missed this before this change merged, but I think I'd have preferred
to keep 'if-let' and 'when-let' around, and only to obsolete their
backward-compatible forms, with the goal of removing that
backward-compatibility one day. Then we'd eventually result in 'if-let'
and 'when-let' (with their preferred semantics) being the only forms around.
It's a minor thing, but I generally read a "*" suffix on a
function/macro name to mean "this function is an extension or
modification of the non-* form". But if there's no (non-obsolete)
non-star form then that breaks down.
On the other hand, the way bindings work in 'if-let*' and 'when-let*'
are closer to 'let*' than 'let'. I think that's a false friend though,
since they're only similar, not actually the same (of course the
semantics couldn't be exactly the same or there'd be no reason for
'if-let*' and 'when-let*' to exist).
Maybe I'm the odd one out here and everyone else prefers to keep
'if-let*' for the long term, in which case I won't dig my heels in on
this issue.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#73853; Package
emacs.
(Sun, 27 Oct 2024 07:11:01 GMT)
Full text and
rfc822 format available.
Message #64 received at 73853 <at> debbugs.gnu.org (full text, mbox):
Jim Porter <jporterbugs <at> gmail.com> writes:
> On the other hand, the way bindings work in 'if-let*' and 'when-let*'
> are closer to 'let*' than 'let'. I think that's a false friend though,
> since they're only similar, not actually the same (of course the
> semantics couldn't be exactly the same or there'd be no reason for
> 'if-let*' and 'when-let*' to exist).
FWIW, this is the argument that convinced me that the `*`-versions are
better: bindings are more like in `let` than in `let*`. To my mind,
that makes the `*`-naming more self-documenting and clear.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#73853; Package
emacs.
(Sun, 27 Oct 2024 09:16:01 GMT)
Full text and
rfc822 format available.
Message #67 received at 73853 <at> debbugs.gnu.org (full text, mbox):
Stefan Kangas <stefankangas <at> gmail.com> writes:
> Jim Porter <jporterbugs <at> gmail.com> writes:
>
> > On the other hand, the way bindings work in 'if-let*' and 'when-let*'
> > are closer to 'let*' than 'let'. I think that's a false friend though,
> > since they're only similar, not actually the same (of course the
> > semantics couldn't be exactly the same or there'd be no reason for
> > 'if-let*' and 'when-let*' to exist).
>
> FWIW, this is the argument that convinced me that the `*`-versions are
> better: bindings are more like in `let` than in `let*`. To my mind,
> that makes the `*`-naming more self-documenting and clear.
In the meantime I found out that I am not as decided as I thought:
I am actually using both versions in my own code. Valid arguments for
either name exist - and it even depends on the case:
In this case I prefer the name without star:
#+begin_src emacs-lisp
(if-let ((a (does-an-a-exist?-then-return-it)))
(use a)
(do-something-else))
#+end_src
Here I prefer the name with star:
#+begin_src emacs-lisp
(and-let* ((a (an-a-exists))
(b (b-depending-on-a-also-exists)))
(test-using a b))
#+end_src
Thinking the first example further we could introduce parallel versions
and name them `if-let', `when-let' and `and-let'. They would be really
analogue to `let' with respect to binding list semantics - compared to
the non-parallel counterparts `if-let*' that are what we have now.
ATM this idea looks appealing to me as a final goal.
Michael.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#73853; Package
emacs.
(Sun, 27 Oct 2024 10:14:02 GMT)
Full text and
rfc822 format available.
Message #70 received at 73853 <at> debbugs.gnu.org (full text, mbox):
Michael Heerdegen via "Bug reports for GNU Emacs, the Swiss army knife
of text editors" <bug-gnu-emacs <at> gnu.org> writes:
Hi Michael,
> Thinking the first example further we could introduce parallel versions
> and name them `if-let', `when-let' and `and-let'. They would be really
> analogue to `let' with respect to binding list semantics - compared to
> the non-parallel counterparts `if-let*' that are what we have now.
Please no more incompatibilities with older Emacsen except when
absolutely necessary. It's already hard enough for packages developed
outside the Emacs repo.
> Michael.
Best regards, Michael.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#73853; Package
emacs.
(Sun, 27 Oct 2024 10:17:01 GMT)
Full text and
rfc822 format available.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#73853; Package
emacs.
(Sun, 27 Oct 2024 11:25:02 GMT)
Full text and
rfc822 format available.
Message #76 received at submit <at> debbugs.gnu.org (full text, mbox):
Michael Albinus <michael.albinus <at> gmx.de> writes:
> Please no more incompatibilities with older Emacsen except when
> absolutely necessary. It's already hard enough for packages developed
> outside the Emacs repo.
My suggestion is not more incompatible than the current approach.
And reintroducing names that we had declared obsolete in a second step
is even backwards compatible then.
Let's please not get impatient, let's try to find the one solution that
we want to keep this time. Else we only postpone the problem into the
future, and this is not ideal for packages outside of Emacs either -
it's worse, in the long run.
Michael.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#73853; Package
emacs.
(Sun, 27 Oct 2024 11:25:02 GMT)
Full text and
rfc822 format available.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#73853; Package
emacs.
(Sun, 27 Oct 2024 11:34:01 GMT)
Full text and
rfc822 format available.
Message #82 received at 73853 <at> debbugs.gnu.org (full text, mbox):
Hello,
On Sun 27 Oct 2024 at 12:24pm +01, Michael Heerdegen wrote:
> Michael Albinus <michael.albinus <at> gmx.de> writes:
>
>> Please no more incompatibilities with older Emacsen except when
>> absolutely necessary. It's already hard enough for packages developed
>> outside the Emacs repo.
>
> My suggestion is not more incompatible than the current approach.
I think it is, unfortunately, because it requires people to do more
reading and thinking when updating their code.
I find your idea interesting, but also not useful enough for the
complexity that it entails -- both transition complexity, and inherent
complexity.
--
Sean Whitton
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#73853; Package
emacs.
(Sun, 27 Oct 2024 11:46:02 GMT)
Full text and
rfc822 format available.
Message #85 received at submit <at> debbugs.gnu.org (full text, mbox):
Michael Heerdegen <michael_heerdegen <at> web.de> writes:
Hi Michael,
> Let's please not get impatient,
I'm not impatient, other people are. Blaming (for example) Tramp for the
compilation warnings in master.
> Michael.
Best regards, Michael.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#73853; Package
emacs.
(Sun, 27 Oct 2024 11:51:02 GMT)
Full text and
rfc822 format available.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#73853; Package
emacs.
(Sun, 27 Oct 2024 12:29:01 GMT)
Full text and
rfc822 format available.
Message #91 received at submit <at> debbugs.gnu.org (full text, mbox):
Michael Albinus <michael.albinus <at> gmx.de> writes:
> I'm not impatient, other people are. Blaming (for example) Tramp for
> the compilation warnings in master.
If you are not impatient: please explain why you are sure that this will
not pop up in, say 18 months, again. Or why it is better to handle this
corner issue in 7 steps spread over an quarter of a century.
Sorry for the sarcasm, but I miss the weighing up in what you say. Only
pointing to annoyances counts but doesn't convince me that one solution
is better than the other.
Michael.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#73853; Package
emacs.
(Sun, 27 Oct 2024 12:29:02 GMT)
Full text and
rfc822 format available.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#73853; Package
emacs.
(Sun, 27 Oct 2024 13:12:02 GMT)
Full text and
rfc822 format available.
Message #97 received at 73853 <at> debbugs.gnu.org (full text, mbox):
Hello,
On Sun 27 Oct 2024 at 01:28pm +01, Michael Heerdegen wrote:
> Michael Albinus <michael.albinus <at> gmx.de> writes:
>
>> I'm not impatient, other people are. Blaming (for example) Tramp for
>> the compilation warnings in master.
>
> If you are not impatient: please explain why you are sure that this will
> not pop up in, say 18 months, again. Or why it is better to handle this
> corner issue in 7 steps spread over an quarter of a century.
>
> Sorry for the sarcasm, but I miss the weighing up in what you say. Only
> pointing to annoyances counts but doesn't convince me that one solution
> is better than the other.
I don't think this is going to come up again -- or, at least, if someone
brings it up, it will not require us to take any action, except possibly
documentation improvements.
I admire your desire to Do It Right, but the Right Thing does not exist
in a vacuum -- in particular, it is constrained by what was done before.
The right thing here is not to try to reuse these names, because of the
particular way in which they were used before.
--
Sean Whitton
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#73853; Package
emacs.
(Sun, 27 Oct 2024 13:24:01 GMT)
Full text and
rfc822 format available.
Message #100 received at submit <at> debbugs.gnu.org (full text, mbox):
Michael Heerdegen <michael_heerdegen <at> web.de> writes:
Hi Michael.
>> I'm not impatient, other people are. Blaming (for example) Tramp for
>> the compilation warnings in master.
>
> If you are not impatient: please explain why you are sure that this will
> not pop up in, say 18 months, again. Or why it is better to handle this
> corner issue in 7 steps spread over an quarter of a century.
I don't know whether this happens. But I buy the reasoning, that if-let*
and when-let* are closed to let*, given the semantics.
> Sorry for the sarcasm, but I miss the weighing up in what you say. Only
> pointing to annoyances counts but doesn't convince me that one solution
> is better than the other.
But you're too late. The whole codebase has been changed already, and
this is much more but an annpyance. I don't see a glaring reason to
revert this.
> Michael.
Best regards, Michael.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#73853; Package
emacs.
(Sun, 27 Oct 2024 13:24:02 GMT)
Full text and
rfc822 format available.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#73853; Package
emacs.
(Sun, 27 Oct 2024 14:43:01 GMT)
Full text and
rfc822 format available.
Message #106 received at 73853 <at> debbugs.gnu.org (full text, mbox):
> Thinking the first example further we could introduce parallel versions
> and name them `if-let', `when-let' and `and-let'. They would be really
> analogue to `let' with respect to binding list semantics - compared to
> the non-parallel counterparts `if-let*' that are what we have now.
>
> ATM this idea looks appealing to me as a final goal.
The only natural semantics for something like when-let is the
"sequential" bindings of `let*`. The `let` and `letrec` semantics are
"unnatural" here, so we should have only the `let*` semantics.
The implementation of a `when-let` that has a binding semantics like
that of `let` rather than `let*` would have to macroexpand
(when-let ((a (fooa))
(b (foob))
...)
(bar))
to something like:
(when-let* ((t1 (fooa))
(t2 (foob))
...)
(let ((a t1)
(b t2)
...)
(bar)))
So coders who "simplify" `when-let*` to `when-let` when the * version is
not needed, would in reality just pessimize their code.
I'll let you guess where I stand w.r.t to naming of `when-let` vs
`when-let*`, based on the fact that I originally implemented `dlet` with
the semantics of `let*`. 🙂
Stefan
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#73853; Package
emacs.
(Sun, 27 Oct 2024 20:01:02 GMT)
Full text and
rfc822 format available.
Message #109 received at 73853 <at> debbugs.gnu.org (full text, mbox):
> (if-let ((a (does-an-a-exist?-then-return-it)))
> (use a)
> (do-something-else))
Is that the same as this?
(let ((a (does-an-a-exist?-then-return-it)))
(if a (use a) (do-something-else)))
> (and-let* ((a (an-a-exists))
> (b (b-depending-on-a-also-exists)))
> (test-using a b))
Is that the same as this?
(let* ((a (an-a-exists))
(b (b-depending-on-a-also-exists)))
(and a b (test-using a b)))
or this?
(let* ((a (an-a-exists))
(b (and a (b-depending-on-a-also-exists))))
(and b (test-using a b)))
or something else?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#73853; Package
emacs.
(Mon, 28 Oct 2024 02:16:02 GMT)
Full text and
rfc822 format available.
Message #112 received at submit <at> debbugs.gnu.org (full text, mbox):
Michael Heerdegen <bug-gnu-emacs <at> gnu.org> writes:
> Sean Whitton <spwhitton <at> spwhitton.name> writes:
>
>> retitle 73853 Should and-let* become a synonym for when-let*?
>> thanks
>
> Thanks for the fine summary.
>
>> - I'd like to go ahead and install a patch marking when-let and if-let
>> as obsolete, unless Michael is keen to be the one to do it as the
>> initiator of the previous effort
>
> He is not, feel free to go ahead when there are no objections from
> others.
I don't know if it's changed since, but in my Emacs 29.1
elisp manual, only the non-starred versions are documented.
--
Howard
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#73853; Package
emacs.
(Mon, 28 Oct 2024 03:21:02 GMT)
Full text and
rfc822 format available.
Message #115 received at 73853 <at> debbugs.gnu.org (full text, mbox):
Hello,
On Sun 27 Oct 2024 at 10:15pm -04, Howard Melman wrote:
> Michael Heerdegen <bug-gnu-emacs <at> gnu.org> writes:
>
>> Sean Whitton <spwhitton <at> spwhitton.name> writes:
>>
>>> retitle 73853 Should and-let* become a synonym for when-let*?
>>> thanks
>>
>> Thanks for the fine summary.
>>
>>> - I'd like to go ahead and install a patch marking when-let and if-let
>>> as obsolete, unless Michael is keen to be the one to do it as the
>>> initiator of the previous effort
>>
>> He is not, feel free to go ahead when there are no objections from
>> others.
>
> I don't know if it's changed since, but in my Emacs 29.1
> elisp manual, only the non-starred versions are documented.
Yes, this is fixed for Emacs 30.
--
Sean Whitton
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#73853; Package
emacs.
(Mon, 28 Oct 2024 09:40:01 GMT)
Full text and
rfc822 format available.
Message #118 received at submit <at> debbugs.gnu.org (full text, mbox):
Michael Albinus <michael.albinus <at> gmx.de> writes:
> But you're too late. The whole codebase has been changed already, and
> this is much more but an annpyance. I don't see a glaring reason to
> revert this.
This has never been my intention, Michael.
Michael.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#73853; Package
emacs.
(Mon, 28 Oct 2024 09:40:02 GMT)
Full text and
rfc822 format available.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#73853; Package
emacs.
(Mon, 28 Oct 2024 13:59:02 GMT)
Full text and
rfc822 format available.
Message #124 received at 73853 <at> debbugs.gnu.org (full text, mbox):
Stefan Monnier <monnier <at> iro.umontreal.ca> writes:
> The only natural semantics for something like when-let is the
> "sequential" bindings of `let*`. The `let` and `letrec` semantics are
> "unnatural" here, so we should have only the `let*` semantics.
I do not see an if-let where condition testing return values are
referenced in THEN, but conditions are independent and exchangeable, as
necessarily unnatural. Even when the implementation:
> [...] to something like:
>
> (when-let* ((t1 (fooa))
> (t2 (foob))
> ...)
> (let ((a t1)
> (b t2)
> ...)
> (bar)))
would not be as straightforward as for `if-let*'.
> So coders who "simplify" `when-let*` to `when-let` when the * version is
> not needed, would in reality just pessimize their code.
The other side is readability, like for `let' vs. `let*'. In my
experience condition not too seldom are independent from each other. I
would be able to make that explicit for the human reader.
But if all of you guys don't like the idea then ...ok, so it be.
> I'll let you guess where I stand w.r.t to naming of `when-let` vs
> `when-let*`, based on the fact that I originally implemented `dlet` with
> the semantics of `let*`. 🙂
Your timing of mentioning such things still has an epsilon of room for
improvement.
Michael.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#73853; Package
emacs.
(Mon, 28 Oct 2024 14:33:02 GMT)
Full text and
rfc822 format available.
Message #127 received at 73853 <at> debbugs.gnu.org (full text, mbox):
>> I'll let you guess where I stand w.r.t to naming of `when-let` vs
>> `when-let*`, based on the fact that I originally implemented `dlet` with
>> the semantics of `let*`. 🙂
>
> Your timing of mentioning such things still has an epsilon of room for
> improvement.
FWIW, in my ideal world, `let` would have the semantics of the current
`let*`, and for those few cases where we do want the "parallel"
semantics, we'd have a special `let-parallel` or something.
But this is not really an option at this point.
For that same reason, while I'd prefer the `when-let` name with the
`when-let*` semantics, I think this won't fly. Just as happened with
`dlet` it would be changed in due time either by adding a `*` or by
changing the semantics.
Stefan
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#73853; Package
emacs.
(Tue, 29 Oct 2024 15:23:02 GMT)
Full text and
rfc822 format available.
Message #130 received at 73853 <at> debbugs.gnu.org (full text, mbox):
Hello all,
It is very disappointing that you have chosen to deprecate if-let and
when-let in such a rushed manner. The same was done and reverted in
2018, and many of the same actors are involved this time around.
I am surprised that you would make the same unforced error again.
Reading through this and past conversations it is clear that there is no
consensus what the ultimate goal is. But as far as I can tell, few, if
any, are fully satisfied with the current (30.0.*) situation. There
also seems to be agreement that unfortunate mistakes were made in the
past, which limits our options now.
This could have been prevented if more people (including non-debbugs and
non-emacs-devel regulars) were given a chance to think about the problem
and time to articulate their concerns and proposals, before facts were
created. Or even if the people who did take part in past conversations
had spend more time actually talking things through.
The same could have been done every time the dissatisfying state of the
foo-let forms was brought up again, but instead new facts were rushed at
every turn.
Without stopping this destructive pattern, you won't be able to fix this
mess.
My short-term proposal is this:
- Revert the depredations and remove the news entry.
Even if you later decide to go through with the deprecation after
all, the "damage" done by doing, reverting and redoing a few lines is
minimal. (Even so, maybe discuss it for a few days before reverting.)
This would have the benefit of not needlessly alienating those package
authors who currently use foo-let and would like to keep doing so, if
the ultimate decision is to not go through with the deprecation after
all.
- Do NOT revert the changes from using foo-let to using foo-let* in
Emacs itself.
You might end up deciding to go through with the deprecation after
all, in which case it would be unfortunate to switch thousands of
lines back and forth.
- Re-read past conversations.
Think about what *your* ideal solutions would be (think big here).
Think about what your best *feasible* solutions would be. Think about
what compromises you would be willing to make. Think about what
compromises you would *not* willing to make, and articulate why.
Think about what others have said, and what compromises they would
have to make to satisfy your position and those of others. Try to
understand where they are coming from. You do not have to *agree*
with their motivations, to appreciate how severe the concessions are,
they would have to make to *them*, to agree to your idea of the
best feasible solution and your idea of an acceptable compromise.
Think in particular about whether achieving your goal/compromise,
would require them to roll over and admit defeat. Consider whether
sticking to the current (30.0.*) status quo, might after all be the
best *compromise* we could possibly reach.
- Do not have this conversation just among yourselves. Any change
you make here is going to affect *many* packages and their authors and
users. Actively involve the affected community. Reach out on several
channels, and give people time to think about the problem and share
their thoughts. I am talking months here, not weeks or even days.
- In addition to thinking about the state you want to reach eventually,
also think about the transition process. Should it be done in several
steps, and if so, what would the consequences for package authors be?
Could it be done in a way that does not force package authors to
change their code multiple times? Could a variable similar in spirit
to lexical-binding be a viable option?
- If you think that this proposal is over the top, try to consider it
from the perspective of the maintainers of external packages. Take
the history of this whole saga into account. Realize that there are
people who have been burned by this before and who will be upset if
being forced to change their packages again, maybe in a way they see
as a step backward. Even if you decide that those who disagree with
you are simply wrong and/or lack good taste, consider whether it is
worth alienating people over this.
To help kick start an informed decision finding process I have searched
the Emacsmirror (a superset of GNU ELPA + NonGNU ELPA + MELPA) for these
forms:
| grep pattern | hits |
|---------------------+------|
| "(if-let\( \|$\)" | 1853 |
| "(if-let\*" | 422 |
| "(when-let\( \|$\)" | 4260 |
| "(when-let\*" | 1162 |
| "(and-let\*" | 288 |
Best regards,
Jonas
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#73853; Package
emacs.
(Tue, 29 Oct 2024 16:37:02 GMT)
Full text and
rfc822 format available.
Message #133 received at 73853 <at> debbugs.gnu.org (full text, mbox):
FWIW, +1.
___
I don't understand why language-design discussions,
even major ones sometimes, are carried out in
debbugs and not always in emacs-devel <at> gnu.org.
I can understand that some real BUG discussion can
diverge or expand to a design discussion, but even
then I'd think that that design discussion should
be gently moved to emacs-devel.
Some such discussions could even benefit from a
mention in other places, such as help-gnu-emacs,
so more users could tune in to the discussion in
emacs-devel if they're interested.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#73853; Package
emacs.
(Wed, 30 Oct 2024 00:51:02 GMT)
Full text and
rfc822 format available.
Message #136 received at 73853 <at> debbugs.gnu.org (full text, mbox):
Hello,
I think that you are overstating the level of disagreement. A lot of
the discussions we have been having have been academic. We all agree
that the legacy single binding syntax should be removed (I noticed that
you didn't use that syntax anywhere in transient.el, when I updated it).
The only question then is how exactly to deprecate that syntax. There
is not complete agreement on the method of deprecation. But there never
was going to be: it was a case where a head maintainer just had to make
a choice about it, as Stefan did.
Those who disagree are often tempted to say that there should have been
more discussion. But it is reasonable to think about whether it is
likely that further discussion would yield additional truth. I think it
was clear to us here that, in this case, it would not.
And indeed, instead of pointing out some critical point that you think
we missed concerning this deprecation, in your message you instead wrote
about highly abstract issues in design.
The specific reason this change had to be backed out before has been
addressed, in the interim. It was the time to do this.
--
Sean Whitton
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#73853; Package
emacs.
(Wed, 30 Oct 2024 09:43:02 GMT)
Full text and
rfc822 format available.
Message #139 received at 73853 <at> debbugs.gnu.org (full text, mbox):
Sean Whitton <spwhitton <at> spwhitton.name> writes:
> Hello,
Hi Sean,
> - Michael reports he is handling TRAMP in tramp.git and will import here
> at an appropriate time.
Done.
Best regards, Michael.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#73853; Package
emacs.
(Wed, 30 Oct 2024 12:56:02 GMT)
Full text and
rfc822 format available.
Message #142 received at 73853 <at> debbugs.gnu.org (full text, mbox):
On Tue, Oct 29, 2024 at 10:21 AM Jonas Bernoulli <jonas <at> bernoul.li> wrote:
>
> It is very disappointing that you have chosen to deprecate if-let and
> when-let in such a rushed manner. The same was done and reverted in
>
> - Revert the depredations and remove the news entry.
>
+1
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#73853; Package
emacs.
(Wed, 30 Oct 2024 23:12:02 GMT)
Full text and
rfc822 format available.
Message #145 received at 73853 <at> debbugs.gnu.org (full text, mbox):
Jonas Bernoulli <jonas <at> bernoul.li> writes:
> It is very disappointing that you have chosen to deprecate if-let and
> when-let in such a rushed manner. The same was done and reverted in
> 2018, and many of the same actors are involved this time around.
> I am surprised that you would make the same unforced error again.
>
> Reading through this and past conversations it is clear that there is no
> consensus what the ultimate goal is. But as far as I can tell, few, if
> any, are fully satisfied with the current (30.0.*) situation. There
> also seems to be agreement that unfortunate mistakes were made in the
> past, which limits our options now.
The goal is:
- To not have two macros doing the same thing, i.e. the pairs
`when-let`/`when-let*` and `if-let`/`if-let*`.
- To deprecate the single binding version of `when-let`.
> This could have been prevented if more people (including non-debbugs and
> non-emacs-devel regulars) were given a chance to think about the problem
> and time to articulate their concerns and proposals, before facts were
> created. Or even if the people who did take part in past conversations
> had spend more time actually talking things through.
I can agree that the timeline might have been on the shorter end here.
That said, I wasn't aware of any large controversy surrounding this.
If I was, I might have suggested that we give this more time.
> The same could have been done every time the dissatisfying state of the
> foo-let forms was brought up again, but instead new facts were rushed at
> every turn.
>
> Without stopping this destructive pattern, you won't be able to fix this
> mess.
I don't know what this is in reference to, sorry. I feel like I'm
missing some background. Could you perhaps help fill me in?
I searched the archives, but failed to find anything relevant.
> My short-term proposal is this:
Hmm, the points you raise are interesting but procedural in character.
Besides your concern that people might be unhappy with the decision,
a point that is fully taken, perhaps it would help if we could focus
on technical points instead.
Your proposal seems to be that we should rethink the decision to mark
`when-let`/`if-let` as obsolete. Is that correct?
If yes, perhaps you could explain this in more detail? What problem do
you see with marking them as obsolete?
Do you have a suggestion for what we should do instead?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#73853; Package
emacs.
(Fri, 01 Nov 2024 14:10:02 GMT)
Full text and
rfc822 format available.
Message #148 received at 73853 <at> debbugs.gnu.org (full text, mbox):
Hello Stefan,
Thanks for you reply!
I intend to reply soon but I am stressed out right now and have to take
it slow to avoid burning out. I currently feel like a volcano went off
and there are fires all over the place that I have to put out.
There's this issue, which due to its urgency makes everything else that
is going on even more stressful. Many more issues than normal have been
opened in my own repository over the last few days, about two dozen,
including some bugs that should be addressed quickly. I also have no
choice but to skip the montly release day, which since its introduction
a few months ago has helps me release stress. And on top of all that,
I have just been asked to intervene (and/or provide an outside
perspective) in a bullying case.
I was going to prioritize the foo-let issue over everything else, and
was just about to reply to your message, when I saw the mail about the
bullying, which I have decided to prioritize instead.
> Do you have a suggestion for what we should do instead?
In my next response I will concentrate on that. I.e., I'll do one of
the things I earlier suggested we all do, think about what *my* (your)
ideal solution would look like.
Jonas
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#73853; Package
emacs.
(Fri, 01 Nov 2024 16:35:02 GMT)
Full text and
rfc822 format available.
Message #151 received at 73853 <at> debbugs.gnu.org (full text, mbox):
Jonas Bernoulli <jonas <at> bernoul.li> writes:
> I intend to reply soon but I am stressed out right now and have to take
> it slow to avoid burning out. I currently feel like a volcano went off
> and there are fires all over the place that I have to put out.
>
> There's this issue, which due to its urgency makes everything else that
> is going on even more stressful. Many more issues than normal have been
> opened in my own repository over the last few days, about two dozen,
> including some bugs that should be addressed quickly. I also have no
> choice but to skip the montly release day, which since its introduction
> a few months ago has helps me release stress. And on top of all that,
> I have just been asked to intervene (and/or provide an outside
> perspective) in a bullying case.
>
> I was going to prioritize the foo-let issue over everything else, and
> was just about to reply to your message, when I saw the mail about the
> bullying, which I have decided to prioritize instead.
I'm sorry to hear that things have been stressful.
FWIW, I don't see a huge rush here. Emacs 31 is still far away, and
while some package authors are meticulously tracking master, an effort
that is of course greatly appreciated, the overwhelming majority don't.
So this won't affect the lions share of Emacs Lisp users any time soon.
That is to say, please take your time. The last thing we want is for
you or anyone else to burn out.
Severity set to 'wishlist' from 'normal'
Request was from
Stefan Kangas <stefankangas <at> gmail.com>
to
control <at> debbugs.gnu.org.
(Sun, 03 Nov 2024 05:55:02 GMT)
Full text and
rfc822 format available.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#73853; Package
emacs.
(Fri, 22 Nov 2024 19:47:02 GMT)
Full text and
rfc822 format available.
Message #156 received at 73853 <at> debbugs.gnu.org (full text, mbox):
>>>> - I'd like to go ahead and install a patch marking when-let and if-let
>>>> as obsolete, unless Michael is keen to be the one to do it as the
>>>> initiator of the previous effort
[...]
> Done.
Beside the use of `make-obsolete` instead of putting the `obsolete`
inside `declare`, I see a more serious problem with this patch.
E.g.
(defun my-foo () (when-let ((x (point))) (goto-char x)))
gives 2 warnings rather than one:
In my-foo:
foo.el:3:19: Warning: ‘when-let’ is an obsolete macro (as of 31.1); use
‘when-let*’ or ‘and-let*’ instead.
foo.el:3:2: Warning: ‘if-let’ is an obsolete macro (as of 31.1); use ‘if-let*’
instead.
- Stefan
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#73853; Package
emacs.
(Sat, 23 Nov 2024 14:36:01 GMT)
Full text and
rfc822 format available.
Message #159 received at 73853 <at> debbugs.gnu.org (full text, mbox):
Hello,
On Fri 22 Nov 2024 at 02:46pm -05, Stefan Monnier via "Bug reports for GNU Emacs, the Swiss army knife of text editors" wrote:
>>>>> - I'd like to go ahead and install a patch marking when-let and if-let
>>>>> as obsolete, unless Michael is keen to be the one to do it as the
>>>>> initiator of the previous effort
> [...]
>> Done.
>
> Beside the use of `make-obsolete` instead of putting the `obsolete`
> inside `declare`,
I didn't know about this distinction. Can you let me know why it would
be better to use a declaration?
> I see a more serious problem with this patch. E.g.
>
> (defun my-foo () (when-let ((x (point))) (goto-char x)))
>
> gives 2 warnings rather than one:
I think this is just inherent to the fact that these macros depend on
each other, though it would be nice to fix if we can.
--
Sean Whitton
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#73853; Package
emacs.
(Sat, 23 Nov 2024 16:16:01 GMT)
Full text and
rfc822 format available.
Message #162 received at 73853 <at> debbugs.gnu.org (full text, mbox):
Sean Whitton <spwhitton <at> spwhitton.name> writes:
> On Fri 22 Nov 2024 at 02:46pm -05, Stefan Monnier via "Bug reports for GNU Emacs, the Swiss army knife of text editors" wrote:
>
>> Beside the use of `make-obsolete` instead of putting the `obsolete`
>> inside `declare`,
>
> I didn't know about this distinction. Can you let me know why it would
> be better to use a declaration?
AFAIK, while they are technically the same, using a declaration is
cleaner. We prefer it for that reason.
>> I see a more serious problem with this patch. E.g.
>>
>> (defun my-foo () (when-let ((x (point))) (goto-char x)))
>>
>> gives 2 warnings rather than one:
>
> I think this is just inherent to the fact that these macros depend on
> each other, though it would be nice to fix if we can.
I think `with-suppressed-warnings` should work here.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#73853; Package
emacs.
(Sun, 24 Nov 2024 00:46:02 GMT)
Full text and
rfc822 format available.
Message #165 received at 73853 <at> debbugs.gnu.org (full text, mbox):
Hello,
On Sat 23 Nov 2024 at 11:14am -05, Stefan Kangas wrote:
> Sean Whitton <spwhitton <at> spwhitton.name> writes:
>
>> I think this is just inherent to the fact that these macros depend on
>> each other, though it would be nice to fix if we can.
>
> I think `with-suppressed-warnings` should work here.
At least for bytecompiled files, it seems. Installed, thanks both.
--
Sean Whitton
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#73853; Package
emacs.
(Fri, 17 Jan 2025 15:41:02 GMT)
Full text and
rfc822 format available.
Message #168 received at 73853 <at> debbugs.gnu.org (full text, mbox):
> remains quite philosophical. And replacing calls of `and-let*' with
> equivalent calls of `when-let*' doesn't make code easier to read, IMO.
Of course it can make it easier to read since the reader doesn't need to
know yet another construct and the subtle difference with its
almost twin.
> Right. The Lisp convention of using `when' for pure control flow and
> `and' for returning values is a good aid to readability.
AFAIK this convention is followed only by some coders, so it doesn't
help readability because you can't rely on it.
> If we don't have and-let*, then we can't use this convention in the case
> that we also want to bind variables.
Then again, we don't have such a "value returning vs not" duplication
and associated convention for `let`, `progn`, `lambda`,
`unwind-protect`, `catch`, `condition-case, ...
The fact we have all three of if/when/and is not a good justification
for `and-let*`.
Stefan
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#73853; Package
emacs.
(Sat, 18 Jan 2025 00:26:01 GMT)
Full text and
rfc822 format available.
Message #171 received at 73853 <at> debbugs.gnu.org (full text, mbox):
Stefan Monnier <monnier <at> iro.umontreal.ca> writes:
> > Right. The Lisp convention of using `when' for pure control flow and
> > `and' for returning values is a good aid to readability.
>
> AFAIK this convention is followed only by some coders, so it doesn't
> help readability because you can't rely on it.
This is a weak argument of its own. You can't rely on any convention
being honored in the code. That doesn't mean that it's a bad convention.
> > If we don't have and-let*, then we can't use this convention in the case
> > that we also want to bind variables.
>
> Then again, we don't have such a "value returning vs not" duplication
> and associated convention for `let`, `progn`, `lambda`,
> `unwind-protect`, `catch`, `condition-case, ...
>
> The fact we have all three of if/when/and is not a good justification
> for `and-let*`.
if/when/let are a bit different than the constructs in your list because
the values in conditionals have different semantics when interpreted as
a conditional than as an value or object. This is part of the reason.
I can't imagine that changing (if (and-let ...) ...) to
(if (when-let ...) ...) is something that makes the language more
attractive, even when we get rid of the similar twin thing, or how you
called it.
So my opinion is still that we have to decide between two similarly
not-so-nice choices, and which one is preferred is more a matter of
taste, so the hassle of changing it is not worth it.
Michael.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#73853; Package
emacs.
(Sat, 18 Jan 2025 02:32:01 GMT)
Full text and
rfc822 format available.
Message #174 received at 73853 <at> debbugs.gnu.org (full text, mbox):
Michael Heerdegen [2025-01-18 01:26:44] wrote:
> Stefan Monnier <monnier <at> iro.umontreal.ca> writes:
>> > Right. The Lisp convention of using `when' for pure control flow and
>> > `and' for returning values is a good aid to readability.
>> AFAIK this convention is followed only by some coders, so it doesn't
>> help readability because you can't rely on it.
> This is a weak argument of its own. You can't rely on any convention
> being honored in the code. That doesn't mean that it's a bad convention.
My argument is not that it's a bad convention. Instead I'm arguing
that the supposed benefit of this convention doesn't really apply because
it's not obeyed widely enough.
>> Then again, we don't have such a "value returning vs not" duplication
>> and associated convention for `let`, `progn`, `lambda`,
>> `unwind-protect`, `catch`, `condition-case, ...
>>
>> The fact we have all three of if/when/and is not a good justification
>> for `and-let*`.
>
> if/when/let are a bit different than the constructs in your list because
> the values in conditionals have different semantics when interpreted as
> a conditional than as an value or object. This is part of the reason.
I don't see the "different semantics" you're alluding to, I'm afraid.
Can you explain what you mean?
> I can't imagine that changing (if (and-let ...) ...) to (if (when-let
> ...) ...)
[ FWIW, in all of Emacs and (Non)GNU ELPA, I could find
only one "(if (and-let* ...) ...)", the one in `help.el` ]
> is something that makes the language more attractive,
It wouldn't change anything to the readability of the code, AFAICT.
In both cases the preceding `if` makes it immediately clear that we're
interested in the final return value but only in whether it's nil
or not.
Stefan
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#73853; Package
emacs.
(Sat, 18 Jan 2025 12:05:02 GMT)
Full text and
rfc822 format available.
Message #177 received at 73853 <at> debbugs.gnu.org (full text, mbox):
Hello,
On Fri 17 Jan 2025 at 10:39am -05, Stefan Monnier via "Bug reports for GNU Emacs, the Swiss army knife of text editors" wrote:
>> Right. The Lisp convention of using `when' for pure control flow and
>> `and' for returning values is a good aid to readability.
>
> AFAIK this convention is followed only by some coders, so it doesn't
> help readability because you can't rely on it.
But it might be specified by an ELPA project's coding style guide, or
you might know that an Emacs subsystem maintainer always uses it and
asks for it in patch reviews.
As it's a readability aid, it doesn't have to be used absolutely
everywhere to be useful.
>> If we don't have and-let*, then we can't use this convention in the case
>> that we also want to bind variables.
>
> Then again, we don't have such a "value returning vs not" duplication
> and associated convention for `let`, `progn`, `lambda`,
> `unwind-protect`, `catch`, `condition-case, ...
>
> The fact we have all three of if/when/and is not a good justification
> for `and-let*`.
I think you are letting the perfect be the enemy of the good, in your
thinking, here.
--
Sean Whitton
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#73853; Package
emacs.
(Sat, 18 Jan 2025 14:16:02 GMT)
Full text and
rfc822 format available.
Message #180 received at 73853 <at> debbugs.gnu.org (full text, mbox):
> As it's a readability aid, it doesn't have to be used absolutely
> everywhere to be useful.
For if/when/and there are *other* reasons to have those three
(e.g. a 4-way `and` becomes much more indented&ugly when replaced by
ifs/whens), so since we have them and since they overlap in many cases,
it can make sense for people to try and convey the intention of
their code by choosing one over the other when they can be
used interchangeably.
But this extra intention information was never the reason to have all three.
For `and-let` vs `when-let` there is no other reason to have both: every
`and-let*` can be replaced by a `when-let*` with virtually no difference
(and in practice all `and-let*` I ever found could similarly be replaced by
an `if-let*`), other than this act of conveying an intention.
> I think you are letting the perfect be the enemy of the good, in your
> thinking, here.
No, I'm trying to argue that `and-let*` is useful only because it
exists, whereas I think we should limit ourselves to things which exist
because they're useful.
If we had an alias of `let` called, say, `do` that behaved exactly the
same, people would likely be tempted to use it to convey the idea that
it doesn't return a value. And then if I were to point out it's useless
I'd apparently see the exact same resistance I'm getting now.
Stefan
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#73853; Package
emacs.
(Sun, 19 Jan 2025 01:41:02 GMT)
Full text and
rfc822 format available.
Message #183 received at 73853 <at> debbugs.gnu.org (full text, mbox):
Stefan Monnier <monnier <at> iro.umontreal.ca> writes:
> My argument is not that it's a bad convention. Instead I'm arguing
> that the supposed benefit of this convention doesn't really apply because
> it's not obeyed widely enough.
Lots of conventions are not obeyed widely. If you (I mean Stefan M.) do
care about them you use to change the occurrences.
One goal when designing the language is that its constructs suggest a
good style. Sometimes people need to be reminded, as you know, think of
quoted lambdas, `point-min' etc. So I am still not convinced by this
argument, and I think in a similar other case it would not convince you as
well.
> >> Then again, we don't have such a "value returning vs not" duplication
> >> and associated convention for `let`, `progn`, `lambda`,
> >> `unwind-protect`, `catch`, `condition-case, ...
> >>
> >> The fact we have all three of if/when/and is not a good justification
> >> for `and-let*`.
> >
> > if/when/let are a bit different than the constructs in your list because
> > the values in conditionals have different semantics when interpreted as
> > a conditional than as an value or object. This is part of the reason.
>
> I don't see the "different semantics" you're alluding to, I'm afraid.
> Can you explain what you mean?
The constructs you mentioned evaluate a sequence of expressions or
create bindings etc. `if-let' and `when-let' are conditionals, the
first argument is a condition, interpreted as boolean. Second,
`and-let' is something that _returns_ a "condition value", a boolean.
Therefore, the return value is also always significant.
OTOH, `when-let' executes expressions when some condition(s) are met.
The return value is not significant most of the time, but in particular
not when the condition was not met. To rely on the implicit `nil'
return value of `when-let' to use it in a condition is not good style
IMHO. Like relying on the nil return value of `while'. You can do it
and "it's clear" but I hate it. Ok?
> It wouldn't change anything to the readability of the code, AFAICT.
> In both cases the preceding `if` makes it immediately clear that we're
> interested in the final return value but only in whether it's nil
> or not.
Well, it does for me. "It's obvious" or "its clear" is the way to less
readable code. You replace a syntax where it is clear that the result
is a boolean with one where the meaning is context dependent. Exactly
this is one of the things that worsen readability: the meaning of an
expression is not clear per se but becomes only clear by looking at the
outer context.
So, if `and-let' would be removed I would replace it with either
(if-let (TESTS...) BOOL-EXP nil) or
(let (VARS) (and (setq VAR1 TEST1) ...)).
If this is so much better for users like you I don't know. It's
surely still worse for me.
There is a third option btw: remove `when-let' instead of `and-let'.
Since `when-let' is mostly `if-let' with a only a tiny difference that
doesn't let you do anything new...people not really obey using `when'
when there is no "else"...it's so similar to `and-let'... most of your
arguments are transferable 1:1.
Michael.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#73853; Package
emacs.
(Sun, 19 Jan 2025 03:32:02 GMT)
Full text and
rfc822 format available.
Message #186 received at 73853 <at> debbugs.gnu.org (full text, mbox):
> OTOH, `when-let' executes expressions when some condition(s) are met.
> The return value is not significant most of the time, but in particular
> not when the condition was not met.
[ I can't think if a situation where the return value would be
significant when the condition is true but not when it's not.
Either the context uses the return value or it doesn't, AFAIK.
It's rather unusual for the context to use it in a way that depends
on the condition (it would require the context to make a similar and
thus somewhat redundant test). ]
> To rely on the implicit `nil' return value of `when-let' to use it in
> a condition is not good style IMHO. Like relying on the nil return
> value of `while'. You can do it and "it's clear" but I hate it. Ok?
That goes back to my earlier question: what makes `and/when/if-let` so
different from `ignore-errors` and so many other constructs.
> So, if `and-let' would be removed I would replace it with either
> (if-let (TESTS...) BOOL-EXP nil) or
> (let (VARS) (and (setq VAR1 TEST1) ...)).
Fine by me.
> If this is so much better for users like you I don't know.
> It's surely still worse for me.
Then write it with `when-let` and get used to the idea that it returns
a value, because... well, it does and code out there relies on it (a
small random sampling suggests that around 15% of the existing uses in
Emacs do).
> There is a third option btw: remove `when-let' instead of `and-let'.
`grep` suggests that will not be popular.
At least in Emacs + (Non)GNU ELPA, we're talking 233 vs 3093.
> Since `when-let' is mostly `if-let' with a only a tiny difference that
> doesn't let you do anything new...people not really obey using `when'
> when there is no "else"...it's so similar to `and-let'... most of your
> arguments are transferable 1:1.
I don't have a strong preference either way.
I just know that they're redundant and would rather see one of the two disappear.
If none of them can't be removed, I'd actually prefer them to be actual
aliases of each other, so at least ELisp non-specialists don't need to
learn the subtle differences between the two.
Stefan
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#73853; Package
emacs.
(Sun, 19 Jan 2025 04:45:02 GMT)
Full text and
rfc822 format available.
Message #189 received at 73853 <at> debbugs.gnu.org (full text, mbox):
Stefan Monnier <monnier <at> iro.umontreal.ca> writes:
> Then write it with `when-let` and get used to the idea that it returns
> a value, because... well, it does and code out there relies on it (a
> small random sampling suggests that around 15% of the existing uses in
> Emacs do).
But Stefan, if we replace calls of `and-let' with `when-let', I would
not only have to get used to the idea "that it returns a value", but I
also would have to remember what happens when `when-let' is used as a
condition (e.g. in an `if') with an empty body. I would always ask:
which of the semantics did we choose again...? This is not better than
what you currently dislike. I would then have to remember and consult
the doc instead of you. It seems a bit that you assume that I can
remember things with much less effort than you.
I mean, there is only one "subtle difference" between `and-let' and
`when-let' - the handling of an empty body - right? Isn't it absolutely
"clear" what an empty body means in both cases?
> > There is a third option btw: remove `when-let' instead of `and-let'.
> `grep` suggests that will not be popular.
> At least in Emacs + (Non)GNU ELPA, we're talking 233 vs 3093.
That may be and is expected. But with `and-let*' semantics we could
keep 233+3093 but with `when-let*' semantics we would probably only keep
3093 or replace some of the 233 with something which is harder to read.
The real question is: which of the semantics is more popular when you
have no choice. A completely different question that you bring up when
you want to remove one.
Michael.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#73853; Package
emacs.
(Sun, 19 Jan 2025 05:08:02 GMT)
Full text and
rfc822 format available.
Message #192 received at 73853 <at> debbugs.gnu.org (full text, mbox):
Stefan Monnier <monnier <at> iro.umontreal.ca> writes:
> That goes back to my earlier question: what makes `and/when/if-let` so
> different from `ignore-errors` and so many other constructs.
What makes `pcase's let/app/pred/guard different from and/when/if-let?
There is likewise lots of redundancy, and the subtle differences are
hard to grasp and remember for a lot of people. Would you remove the
two least used ones?
I also still remember your reaction when I had used a let pattern to do
destructuring with combined testing and you meant that it was not
designed for it and would be weird. Because you associated a semantic
with it that was not necessarily implied for me.
So isn't your personal taste in this case here relevant too, for what
you want to do?
Michael.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#73853; Package
emacs.
(Wed, 22 Jan 2025 00:09:02 GMT)
Full text and
rfc822 format available.
Message #195 received at 73853 <at> debbugs.gnu.org (full text, mbox):
>> Then write it with `when-let` and get used to the idea that it returns
>> a value, because... well, it does and code out there relies on it (a
>> small random sampling suggests that around 15% of the existing uses in
>> Emacs do).
> But Stefan, if we replace calls of `and-let' with `when-let', I would
> not only have to get used to the idea "that it returns a value", but I
> also would have to remember what happens when `when-let' is used as a
> condition (e.g. in an `if') with an empty body.
Of course, the same happens as happens in any other position. This is
a general rule in pretty much all programming languages: the evaluation
is performed in the same way regardless on the context where that
expression is used.
> I would always ask: which of the semantics did we choose again...?
That's easy to fix: disallow or strongly discourage empty bodies.
We already do that in various places and it would be very natural to do
that in `when-let*` as well.
Currently in Emacs itself, `grep` finds 681 uses of `when-let(*)` and
only one of them has an empty body (and I'd argue it's an error: the
last "binding" is `((push finext extlist-new))` which macro expands to
something silly; not sure if the bytecompiler manages to unsillify the
code).
The score is a bit less one-sided for `and-let*` where I count 25 empty
bodies among 140 uses (the vast majority of them in ERC and Tramp).
Also, it's easier to remember the answer if you have to remember it only
for `when-let*` rather than having to remember it for both `and-let*` and
`when-let*`.
Incidentally, `and-let*` is member of a rather small club of forms where
en empty body is not treated as a body that returns nil. I was able
to remember only 3 other forms that have this property (one of which is
never used, AFAICT). I don't think forms should wear this property as
a badge of honor.
> This is not better than what you currently dislike. I would then have
> to remember and consult the doc instead of you. It seems a bit that
> you assume that I can remember things with much less effort than you.
The rule is easy: an empty body returns nil.
It applies to *almost* all ELisp forms that include a "body"
(i.e. a list of forms).
> I mean, there is only one "subtle difference" between `and-let' and
> `when-let' - the handling of an empty body - right? Isn't it absolutely
> "clear" what an empty body means in both cases?
[ Given the fact that in almost all other cases an empty body returns nil,
I wouldn't say it's "absolutely clear" for `and-let*`, no. ]
Michael Heerdegen [2025-01-19 06:08:37] wrote:
> What makes `pcase's let/app/pred/guard different from and/when/if-let?
The differences between let/app/pred/guard and comparable to the
differences between if/when/and/unless/cond: you can fairly easily get
each one from (some of) the others, but it's not mere renaming, so
there's a tradeoff because of code size/verbosity (and also ease of
optimization, tho to a minor degree).
In the case of `and-let*`, it seems the tradeoff is not code size nor
verbosity, but only a reluctance by some developers to rely on
`when(-let)`s return value, even tho it's documented/reliable.
So maybe instead of converting `and-let*` to `when-let*` we should
recommend converting them to `if-let*`, where I don't think anyone has
ever expressed an expectation that `if(-let)` doesn't return a value or
that it's unclear what value it would return if the (else) body is empty.
[ A quick search suggests there are very few uses (I could find only
4 in Emacs) of `and-let*` with a body containing more than one
form. ]
> There is likewise lots of redundancy, and the subtle differences are
> hard to grasp and remember for a lot of people. Would you remove the
> two least used ones?
I've been tempted to do that, but they're used often enough and the
rewrite is sufficiently more verbose that I've kept them so far.
> So isn't your personal taste in this case here relevant too, for what
> you want to do?
Definitely. I did not intend to imply otherwise.
Stefan
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#73853; Package
emacs.
(Thu, 23 Jan 2025 02:00:03 GMT)
Full text and
rfc822 format available.
Message #198 received at 73853 <at> debbugs.gnu.org (full text, mbox):
Stefan Monnier <monnier <at> iro.umontreal.ca> writes:
> > I would always ask: which of the semantics did we choose again...?
>
> That's easy to fix: disallow or strongly discourage empty bodies.
> We already do that in various places and it would be very natural to do
> that in `when-let*` as well.
> Currently in Emacs itself, `grep` finds 681 uses of `when-let(*)` and
> only one of them has an empty body (and I'd argue it's an error: the
> last "binding" is `((push finext extlist-new))` which macro expands to
> something silly; not sure if the bytecompiler manages to unsillify the
> code).
> The score is a bit less one-sided for `and-let*` where I count 25 empty
> bodies among 140 uses (the vast majority of them in ERC and Tramp).
This is my personal perspective but: `and-let*' doesn't have a body!
It's final condition naturally doesn't need to be bound and thus can be
put at the final position after the bindings.
> Also, it's easier to remember the answer if you have to remember it only
> for `when-let*` rather than having to remember it for both `and-let*` and
> `when-let*`.
I never had a problem to remember any of the semantics of those macros.
They are natural.
> Incidentally, `and-let*` is member of a rather small club of forms where
> en empty body is not treated as a body that returns nil. I was able
> to remember only 3 other forms that have this property (one of which is
> never used, AFAICT). I don't think forms should wear this property as
> a badge of honor.
Yes, because it should not be seen as body, in my opinion. I would
remove the &rest and make it an optional final statement.
> In the case of `and-let*`, it seems the tradeoff is not code size nor
> verbosity, but only a reluctance by some developers to rely on
> `when(-let)`s return value, even tho it's documented/reliable.
Please not without context: it's so because of the name and the
semantics a `when' statement usually suggests. If this was Prolog I
would see it differently.
> So maybe instead of converting `and-let*` to `when-let*` we should
> recommend converting them to `if-let*`, where I don't think anyone has
> ever expressed an expectation that `if(-let)` doesn't return a value or
> that it's unclear what value it would return if the (else) body is
> empty.
Well, I did think about it. If `if' or `if-let*' is used as a condition
I would always specify THEN and (one) ELSE. But yes, definitely better
than `when-let'.
> > So isn't your personal taste in this case here relevant too, for what
> > you want to do?
>
> Definitely. I did not intend to imply otherwise.
Ok. But why do you think that your taste is the better one, then? Or
shared by more people?
Michael.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#73853; Package
emacs.
(Fri, 24 Jan 2025 12:06:02 GMT)
Full text and
rfc822 format available.
Message #201 received at 73853 <at> debbugs.gnu.org (full text, mbox):
Hello Stefan,
On Sat 18 Jan 2025 at 10:30pm -05, Stefan Monnier wrote:
> I don't have a strong preference either way.
> I just know that they're redundant and would rather see one of the two disappear.
>
> If none of them can't be removed, I'd actually prefer them to be actual
> aliases of each other, so at least ELisp non-specialists don't need to
> learn the subtle differences between the two.
I think you've been talking somewhat as though we were designing a new
language. But what we're actually considering is changes to macros that
exist, and that have been present instable releases that people rely on.
We should have a bias towards retaining functionality that has been in
releases of Emacs, just as much for macros as for, e.g., key bindings.
Therefore, contrary to what you say, the fact that functionality exists
in existing stable releases does thereby render that functionality more
useful.
If we removed one of them we would be removing the ability to express
one's intention in accordance with the and/when convention about return
values vs. side effects. So we shouldn't remove them.
As for the question of making them aliases, I don't share your concerns
about empty bodies being especially bad. So I think I would be more in
support of making when-let* a synonym for and-let* than the other way
around. But I'm not convinced that any change is required.
--
Sean Whitton
This bug report was last modified 140 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.