Why Lisp Not Have a Generic Copy-List Function?
Dear lispers,
LOL.
There's is a essay by Kent Pitman, about why lisps don't have a generic function to copy lists, and the complexities of meaning of equality. This essay is often cited by lispers in comp.lang.lisp, about every few months in the past 9 years. The current URL is here:
[The Best of Intentions: EQUAL Rights — and Wrongs — in Lisp By Kent M Pitman. At http://www.nhplace.com/kent/PS/EQUAL.html , accessed on 2014-03-10 ]
I became aware of this essay in early 2000s. Kent himself mentions it when he sees fit. I actually never red it. I just knew that it's something lispers quote frequently like a gospel. In the back of my mind, i tend to think it is something particular to lisp, and thus is stupid, because many oft-debated lisp issues (e.g. single vs multi semantic space), never happens in a lisp-like language Mathematica which i'm a expert, nor does it happen in any dynamic langs i have become a expert of since 2000. (For example, Perl, Python, PHP, JavaScript.).
Today, out of boredom, i went and took a look. (it has been just cited again, by a old-time lisper Rob Warnock) I thought: let's see what would happen, and perhaps it would cause me to write some damning refutation about it.
This is when i LOL'd.
The paper, basically indicates a fundamental problem of lisp i have tried to tell lispers for long. Namely: The cons prevents lisp from developing into a coherent, consistent, libraries of functions that deal with tree data. Secondly, the problem is caused by Lisp's “internal” representation of things so-called “object”.
It is not a wonder, why these problems don't occur in other dynamic languages, in particular PHP, Mathematica. (it does occur to some degree in Perl and Python, since they also rely on “references” voodoo.)
These 2 issues i have discussed in depth in the past. See:
Here's a short quote from the first essay:
Lisp at core is based on functional programing on lists. This is comparatively a powerful paradigm. However, for historical reasons, lisp's list is based on the hardware concept of “cons” cell. From a mathematical point of view, what this means is that lisp's lists is limited to a max of 2 elements. If you want a longer list, you must nest it and interpret it in a special way. (i.e. effectively creating a mini-protocol of nesting lists, known as proper lists.) The cons fundamentally crippled the development of list processing.
Many lispers do not understand it, in fact actively accuse me of no understanding. (this is in the context of the rowdy comp.lang.lisp.) Most of this reaction is rather just being defensive. (i presume lispers in real life would receive it better.)
Kent's essay, may be viewed with 2 reactions. One of them, typically taken by lispers, is this:
(1) Typical programers are ignorant of lisp. They should learn lisp before “attacking” (and see the light!).
However, it can be viewed in another way:
(2) Lisp is a old lang, one of the first lang, with first running version in the 1960s. Many later development in computer language theory, and practices, isn't caught up in lisp for many social reasons that is naturally understandable, in particular after about 1990 when lisp ceased to be used in the industry. Many lisp's ways, thus is quaint, incompatible with today's language views and practices, and sometimes, if not often, not the best.