| Pascal Costanza 2008-01-29, 4:56 am |
| Blake McBride wrote:
>
> In conclusion, Scheme has, IMO, many important shortcomings. I
> understand that I don't set the standards and these are just basically
> my opinions. Although I believe these shortcomings are relatively
> easy to fix, the real problem is the political element. No matter
> what you think there is always someone out there who thinks the
> opposite. The net result is that language development ends up
> unnecessarily slow.
>
> Common Lisp, again IMO, did a lot of the right things. The one big
> technical error (IMO) was the LISPn thing. I know a bunch of you guys
> want to jump on me about this with all kinds of technical BS trying to
> rationalize your view. The truth of the matter is that the highest
> and most respected experts on Common Lisp are utterly unclear about
> the issue. So how does that make you an expert? You are more of a
> fan club than a technical expert (again read the articles from the
> authors of Common Lisp). The real truth is that the number one reason
> Common Lisp is LISPn rather than LISP1 is historical and for purposes
> of backward compatibility (all of which is hardly applicable anymore).
> It isn't technically better. The experts were able to point out
> trade-offs with either design. They even stated that LISP1 encouraged
> more elegant programming style.
An excellent series of postings, you hit the nails on their heads. ;)
Except for the Lisp-1 vs. Lisp-2 issue. ;)
You say that Scheme macro systems are too complicated. However, there is
an important technical aspect there related to the Lisp-1 vs. Lisp-n
issue: If you go for a Common Lisp-style macro system, a Lisp-1 makes
macro programming more unreliable than a Lisp-n. Since a Lisp-1 squeezes
all names into a single namespace, the likeliness for having accidental
nameclashes is much higher. Lisp-n simply provides more 'air to
breathe', so to speak.
That's why I personally prefer Lisp-n over Lisp-1. In fact, I often have
accidental nameclashes in Scheme completely independent of whether I
define macros or not. In Common Lisp, this almost never happens to me,
including in macros.
There is also an aesthetic point: The car position in a form _is_
treated differently than the cdr positions, in all Lisp dialects. The
car position defines the meaning of a form, while the cdr positions
don't. This is true both for Lisp-1 and Lisp-n. Now, when alongside
'plain' macros you add symbol macros / identifier macros, they become
easier to integrate into a Lisp-n than into a Lisp-1. Lisp-1 'pretends'
that all positions are the same for variable lookup, but the macro
system suddenly has to make the distinction between car and cdr
positions (and there is no way around it!). In a Lisp-n, the distinction
is already there from the start, so there is nothing unnatural about
adding symbol macros / identifier macros. It's actually quite easy and
straightforward.
Note: My preference for Lisp-n is a subjective one. There are some
technical arguments in favor of Lisp-n, and some against Lisp-n. But the
same is true for Lisp-1, there are both arguments in favor and against
Lisp-1. It's fine if you prefer Lisp-1 over Lisp-n, but it would be good
to acknowledge that this is also a subjective choice.
Pascal
--
1st European Lisp Symposium (ELS'08)
http://prog.vub.ac.be/~pcostanza/els08/
My website: http://p-cos.net
Common Lisp Document Repository: http://cdr.eurolisp.org
Closer to MOP & ContextL: http://common-lisp.net/project/closer/
|