>     Sometimes that's the goal. Differentiating things is only good if the
>     difference is meaningful to the programmer. If it's meaningless, then
>     it's confusing that there's a difference.
>
> If there is a difference but it doesn't look meaningful, it may also be
> a sign that one hasn't fully grasped the concept behind.
>
> For example, to many programmers the difference between symbols and
> identifiers may not be meaningful. Say, because they come from a
> language without hygienic macros.

I would argue that the language has too many concepts to grasp :) It's a
sign of genius to obtain the same result with fewer concepts.

The use of value equality, instead of reference identity, in functional
languages is a good example of this. Reference identity is hard for
newbies to understand, and causes many bugs even for experienced
programmers. Much better if we can avoid thinking about the whole issue.

Computer science is weird because due to its formal nature, design and
research are historically so deeply intertwined. It's easy to forget
that the goal of design is simply to make something that is good to use.
Scheme's logical consistency usually makes it better to use, and is a
good heuristic for designing programming languages, but the rule doesn't
apply in every case.

That's why I'm not a Haskell fan. Adding things to the type system seems
a source of pride rather than embarrassment for them. It has already
exceeded its complexity budget, and they don't have anything to remove.

> Once you have understood the difference, you have understood the concept
> of hygienic macros.

IMHO hygienic macros are good _in spite of_ the distinction between
symbols and identifiers, not because of it :) If it were possible to
make a useful hygienic macro system without worrying about the
distinction, it would be an improvement.

The hallmark of a great designer is these "magic tricks" where they can
remove a concept that everyone else thought was necessary.

> In Scheme, you could transparently add an "undefined" value as well.
> Just add to the specification that "(if #f #f)" and procedures that are
> solely called for side effects shall return "undefined" and not some
> unspecified value. It may not make much sense from a logical point of
> view, but it may make some sense for the REPL, which can choose not
> print the "undefined" value.
> So, if you interpret "undefined" as "nothing", there is a rationale why
> it is different to null in JavaScript.  But without any such
> interpretation, it is meaningless.

There probably is a logical definition of the difference, and I have
probably read about it, but it doesn't stick to memory. Several Scheme
implementations have a "void" value. Also, implementations with real
multiple values can return zero values. Many functional languages have
"bottom" and "unit"...

> That '() and #f really mean different things is proven by the existence
> of many list processing procedures where it is natural to distinguish
> between the empty list result or a false result.

It's true that the distinction is useful in many places in Scheme. But
the lack of distinction is also useful in many places in CL...