[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: if-let/if-let*/and-let/..
From: |
Mark Oteiza |
Subject: |
Re: if-let/if-let*/and-let/.. |
Date: |
Tue, 13 Feb 2018 14:31:26 -0500 |
User-agent: |
NeoMutt/20171215 |
On 13/02/18 at 07:23pm, Michael Heerdegen wrote:
> Stefan Monnier <address@hidden> writes:
>
> > >>> - why do we have and-let* ? According to its docstring the only
> > >>> case when it differs from when-let* is when body is nil, but in
> > >>> that case you're better off moving the last binding to the body
> > >>> (and use when-let*).
> > >>
> > >> The discussion about this was in bug#28254. The original and-let*
> > >> version was much more different from `when-let*', but AFAIR Noam
> > >> vetoed against this version, so they got more similar in the end.
> > >
> > > Is it worth keeping this "more similar" result at all?
>
> I think it is worth it, for the same reason we keep having `when' though
> we have `if' or `and': to make code better readable and its intention
> better understandable.
They ended up being so similar because we bestowed all the goodies from
and-let* onto the other two macros. I proposed code adding and-let* so
naturally I'm all about keeping it.
> > >> The original reason was that we decided that the names without "*" are
> > >> quite confusing and we wanted to get rid of them in the future.
> > >
> > > Is the benefit of slightly reducing confusion (I really find it hard to
> > > believe the confusion is serious, since the dependencies between the
> > > different steps would make it rather inconvenient to provide a real
> > > "parallel-let" semantics)
>
> In my case, my brain always told me that the * name is the canonical
> one, so I always got errors. I think nobody thinks through what you
> said when writing code.
The macros are based on let*, so why wouldn't their names reflect it? (I
see the below reasoning about original vs alternate)
I forget from the discussion of when these were introduced, but I think
the other language's when-let from which the single binding special case
was assimilated ONLY allowed a single binding, and so wouldn't have
needed let* anyways.
> > > worth the burden of those compatibility/obsolescence issues (I'd
> > > also mention the confusing aspect of having an extra * for a
> > > construct that doesn't exist without a *, even though traditionally
> > > the * is used to mark an "alternative" definition, as in list*,
> > > mapcar*, ...).
>
> I think when using `when-let' etc. more people have the analogy to `let'
> in mind than mapcar* vs. mapcar, but I see your point: the obsolescence
> issue is very unpleasant.
>
> > > Another question is why aren't when-let and when-let* aliases of
> > > each other? Currently we have 5 variants (2 of which are
> > > deprecated) each with very slightly different semantics.
>
> That makes no sense, indeed. Would keeping both names as aliases be ok
> to you?
If we are ok with breaking code that depends on the special case (SYMBOL
VALUEFORM) semantics that the original if-let and when-let had, that is:
(when-let (a 1) a)
then we could just make them aliases--they are separate from the
{if,when}-let* simply to avoid breaking code.
- if-let/if-let*/and-let/.., Stefan Monnier, 2018/02/11
- Message not available
- Message not available
- Re: if-let/if-let*/and-let/..,
Mark Oteiza <=
- Re: if-let/if-let*/and-let/.., Stefan Monnier, 2018/02/13
- Re: if-let/if-let*/and-let/.., Mark Oteiza, 2018/02/13
- Re: if-let/if-let*/and-let/.., Michael Heerdegen, 2018/02/14
- Re: if-let/if-let*/and-let/.., Stefan Monnier, 2018/02/14
- Re: if-let/if-let*/and-let/.., Michael Heerdegen, 2018/02/20
- Re: if-let/if-let*/and-let/.., Michael Heerdegen, 2018/02/21
- Re: if-let/if-let*/and-let/.., Stefan Monnier, 2018/02/22
- Re: if-let/if-let*/and-let/.., Michael Heerdegen, 2018/02/22
- Re: if-let/if-let*/and-let/.., Michael Heerdegen, 2018/02/13
- Re: if-let/if-let*/and-let/.., Eric Abrahamsen, 2018/02/13