If you want a longer list, you must nest it and interpret it in a special way. From a mathematical point of view, what this means is that lisp's lists is limited to a max of 2 elements. However, for historical reasons, lisp's list is based on the hardware concept of “cons” cell. This is comparatively a powerful paradigm. Lisp at core is based on functional programing on lists. Here's a short quote from the first essay: These 2 issues i have discussed in depth in the past. (it does occur to some degree in Perl and Python, since they also rely on “references” voodoo.) It is not a wonder, why these problems don't occur in other dynamic languages, in particular PHP, Mathematica. Secondly, the problem is caused by Lisp's “internal” representation of things so-called “object”. Namely: The cons prevents lisp from developing into a coherent, consistent, libraries of functions that deal with tree data. The paper, basically indicates a fundamental problem of lisp i have tried to tell lispers for long. (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. Today, out of boredom, i went and took a look. (For example, Perl, Python, PHP, JavaScript.). (for example: 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. 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 I just knew that it's something lispers quote frequently like a gospel. Kent himself mentions it when he sees fit. I became aware of this essay in early 2000s. This essay is often cited by lispers in, about every few months in the past 9 years. 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.
0 kommentar(er)
