RE: What does "lacks a prefix" mean?

[Drew Adams]

> > Actually I see no harm using let* all the time.

Harm?  Why would *harm* be the only useful or the most useful
criterion?

There's no harm in writing Lisp with no whitespace at all,
except for that needed to distinguish tokens such as symbols
and numbers.

And in fact I once had a colleague (an expert Lisper, BTW) who
wrote Lisp that way, always - no newline chars, no indentation,
no spaces or tabs at all, except what was needed by the
interpreter or byte-compiler to disambiguate the code.

No one else wanted to read, let alone modify his code, but hey,
no "harm" done, right?

He wrote his code at lightning speed, hardly looking at it.
And his code was *good* code - for the applications and the
machine.  It just wasn't very good for humans (other than
himself, arguably, and I'm not sure he didn't shoot himself
in the foot sometimes).

> This is a frequent subject of style arguments.
> 
> As far as the computer is concerned, there should be no problem
> with using let* all the time. But to human readers, it makes a
> difference.

Indeed, that is the point.  (Though I don't entirely agree with
your description of the difference it makes to human readers,
quoted next.)

> Some of us view the * as being a red flag, warning the reader that
> something unusual is being done. We'll then expend more mental
> energy looking for the dependencies. let is the "normal" method,
> let* is "special".

I would say this about using `let' vs `let*' wrt what they
indicate to human readers: `let' indicates that the bindings
are independent; `let*' signals that they might be dependent.

I don't see a red flag from `let*', but yes, it does make me
pay attention and look for dependencies.  That "might be" is
where I agree with Barry: `let*' makes you look for whether each
binding after the first might in fact be dependent on a previous
one from the same `let*'.

It's a huge load off one's mind knowing that the bindings of
a `let' are independent.  Similarly, it is a great help to know,
from `let*', to look for how the bindings are actually related.

The problem with using `let*' all the time ("harm", actually)
is the problem of affixing the same **WARNING** label to
absolutely everything - it loses all power to draw attention to
anything. If everwhere might involve binding dependencies then
you have no signal to watch for them.  You need to always be on
the alert - or never.

I start with `let', and I change to `let*' only when the logic
dictates it, i.e., when I introduce a dependent binding.  That
way I know that if I see `let*' there is a dependency.

Does writing this way, privileging `let' when possible, mean
more work for the writer?  Of course.  When things change in
the code logic, it can happen that you need to change whether
you are using one or the other, or you might even need to add
another `let' or `let*' - or you might be able and want to
remove one.

But saving the writer some maintenance burden is not my priority.
Saving the reader some interpretation burden is more important.
Why?  Because the reader, even when s?he is the same human as
the writer, is reading something inherently foreign - s?he is
coming at the code from a distance, and is a priori less
familiar with it.

Even for the same person, time and change of context can provide
enough distance that it is no longer immediately clear what is
going on or why things were written as they are.

(And yes, I even update the code even when it is not absolutely
necessary: if there is no longer any dependency then I change a
`let*' back to `let'.  IOW, I try to keep the code telling me
what I want to know about the actual dependencies.)

To me, the discovery that, hey, I can write everything using
just `let*' and never bother with `let', and following up that
discovery with the practice of just using `let*', is the sign
of a novice - someone who hasn't yet learned that you don't just
write code once and for all.  Even "throwaway" code can have
a longer life than you might expect.  It's about the code long
term; it's not about you just now.

In sum, to me the problem with such an approach is *not*
that it is lazy.  The problem is in fact that it is *not lazy
enough*.

Such an approach shows misguided, short-sighted laziness.
True, enlightened laziness takes the longer view: minimize
effort and strain (whether manual or mental) over time and
across multiple maintainers and other readers.

YMMV.