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

[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

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

[Stefan Kangas]

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.

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

[Augusto Stoffel]

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

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

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

Augusto Stoffel <arstoffel@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.

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

[Sean Whitton]

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

bug#73853: 31.0.50; Should and-let* become a synonym for when-let*?

[Sean Whitton]

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

bug#73853: 31.0.50; Should and-let* become a synonym for when-let*?

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

Sean Whitton <spwhitton@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.

bug#73853: 31.0.50; Should and-let* become a synonym for when-let*?

[Stefan Kangas]

Michael Heerdegen <michael_heerdegen@web.de> writes:

> Sean Whitton <spwhitton@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.

bug#73853: 31.0.50; Should and-let* become a synonym for when-let*?

[Sean Whitton]

Hello,

On Wed 23 Oct 2024 at 07:05am -07, Stefan Kangas wrote:

> Michael Heerdegen <michael_heerdegen@web.de> writes:
>
>> Sean Whitton <spwhitton@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

bug#73853: 31.0.50; Should and-let* become a synonym for when-let*?

[Sean Whitton]

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

bug#73853: 31.0.50; Should and-let* become a synonym for when-let*?

[Jim Porter]

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

bug#73853: 31.0.50; Should and-let* become a synonym for when-let*?

[Stefan Kangas]

Jim Porter <jporterbugs@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.

bug#73853: 31.0.50; Should and-let* become a synonym for when-let*?

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

Stefan Kangas <stefankangas@gmail.com> writes:

> Jim Porter <jporterbugs@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.

bug#73853: 31.0.50; Should and-let* become a synonym for when-let*?

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

Michael Heerdegen via "Bug reports for GNU Emacs, the Swiss army knife
of text editors" <bug-gnu-emacs@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.

bug#73853: 31.0.50; Should and-let* become a synonym for when-let*?

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

Michael Albinus <michael.albinus@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.

bug#73853: 31.0.50; Should and-let* become a synonym for when-let*?

[Sean Whitton]

Hello,

On Sun 27 Oct 2024 at 12:24pm +01, Michael Heerdegen wrote:

> Michael Albinus <michael.albinus@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

bug#73853: 31.0.50; Should and-let* become a synonym for when-let*?

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

Michael Heerdegen <michael_heerdegen@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.

bug#73853: 31.0.50; Should and-let* become a synonym for when-let*?

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

Michael Albinus <michael.albinus@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.

bug#73853: 31.0.50; Should and-let* become a synonym for when-let*?

[Sean Whitton]

Hello,

On Sun 27 Oct 2024 at 01:28pm +01, Michael Heerdegen wrote:

> Michael Albinus <michael.albinus@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

bug#73853: 31.0.50; Should and-let* become a synonym for when-let*?

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

Michael Heerdegen <michael_heerdegen@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.

bug#73853: 31.0.50; Should and-let* become a synonym for when-let*?

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

> 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

bug#73853: 31.0.50; Should and-let* become a synonym for when-let*?

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

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

bug#73853: 31.0.50; Should and-let* become a synonym for when-let*?

[Howard Melman]

Michael Heerdegen <bug-gnu-emacs@gnu.org> writes:

> Sean Whitton <spwhitton@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

bug#73853: 31.0.50; Should and-let* become a synonym for when-let*?

[Sean Whitton]

Hello,

On Sun 27 Oct 2024 at 10:15pm -04, Howard Melman wrote:

> Michael Heerdegen <bug-gnu-emacs@gnu.org> writes:
>
>> Sean Whitton <spwhitton@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

bug#73853: 31.0.50; Should and-let* become a synonym for when-let*?

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

Michael Albinus <michael.albinus@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.

bug#73853: 31.0.50; Should and-let* become a synonym for when-let*?

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

Stefan Monnier <monnier@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.

bug#73853: 31.0.50; Should and-let* become a synonym for when-let*?

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

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

bug#73853: 31.0.50; Should and-let* become a synonym for when-let*?

[Jonas Bernoulli]

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

bug#73853: 31.0.50; Should and-let* become a synonym for when-let*?

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

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

bug#73853: 31.0.50; Should and-let* become a synonym for when-let*?

[Sean Whitton]

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

bug#73853: 31.0.50; Should and-let* become a synonym for when-let*?

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

Sean Whitton <spwhitton@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.

bug#73853: 31.0.50; Should and-let* become a synonym for when-let*?

[Corwin Brust]

On Tue, Oct 29, 2024 at 10:21 AM Jonas Bernoulli <jonas@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

bug#73853: 31.0.50; Should and-let* become a synonym for when-let*?

[Stefan Kangas]

Jonas Bernoulli <jonas@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?

bug#73853: 31.0.50; Should and-let* become a synonym for when-let*?

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

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