Re: if-let/if-let*/and-let/..

[Mark Oteiza]

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.