4 ms·

Every other Lisp happens to have TCO, so if you try to port other Lisp programs to Clojure you generally get stack overflows.

hkolek 13y ago
But afaik TCO is only a requirement for Scheme implementations, not for e.g. Common Lisp (i.e. you don't need to implement TCO to satisfy the Common Lisp standard). I don't see how the lack of TCO prevents it from being a valid Lisp dialect.
- cgag 13y ago
  Do you need to implement the common lisp standard to be "a lisp"? What is a lisp?
  - hkolek 13y ago
    Exactly my point. I was just using CL as example because I think it would be hard to argue that it is not a Lisp yet the standard doesn't guarantee TCO. > What is a lisp? It's a very good question. I think PG sums it up quite nicely in "Revenge of the Nerds" [1]. Although, now that I'm thinking about it, I'm not quite sure there's any point in classifying something as a Lisp or not... [1] http://www.paulgraham.com/icad.html http://www.paulgraham.com/icad.html
gsg 13y ago
Emacs lisp doesn't guarantee TCO (and in practice does not perform it at all), and yet few people claim that it is not a dialect of lisp.
dschiptsov 13y ago
Without TCO you have stack overflows, and without proper numeric tower you have integer overflows. Roughly speaking, one of the aspect of why it isn't Lisp is underlying Java stuff.
- hkolek 13y ago
  I think we have already established that TCO is not necessary to be a Lisp (CL, Emacs Lisp). While it's true that Clojure doesn't have a proper numeric tower it does have bignum support and arbitrary precision math operators which will not overflow. But either way, imo this is not a defining feature of a Lisp dialect.
  - dschiptsov 13y ago
    In fact, all non-toy Lisp implementation provide TCO - http://0branch.com/notes/tco-cl.html http://0branch.com/notes/tco-cl.html because, it seems, it's a natural feature of a Lisp system (Scheme just requires it). Again, Lisp could be defined as a limited set of conventions/features. As long as some other features, such as CLOS added there is no problem, but if some features are broken, then it is not Lisp anymore. It is just doesn't walk like a duck. Let's say that Clojure was developed with a "put everything useful together" or Ruby-approach, if you wish, which is very popular for scripting languages, while development of Scheme and other Lisp dialects was founded on "put only what is absolutely essential, and done right". The first approach "stuff anything in" you could see almost everywhere. The second approach "research first, and do the best" is unpopular for the obvious reasons and could be rarely seen only in masterpieces, such as Gambit-C, nginx, old-school marvels such as Informix. So, in my opinion, Clojure is much closer to Ruby than to Lisp (let's not be deceived by parentheses) - it is a scripting language (to quickly put everything together with variety of clever special syntax and fancy data-structures without much thinking about implementation details). This is, of course, most productive approach to coding - this is why people love scripting languages so much.
    - knome 13y ago
      Your manner of dismissing LISPs without TCO allows you is something of a No True Scotsman argument, enabling you to proclaim counter examples toys by merit of their being counter examples. Yes, most lisps have it. I don't think anyone denies emacs-lisp or AutoLISP were Lisps due to their lacking it. Your suggestion of "let's say ..." is based in what appears to be complete lack of familiarity with all of the languages involved. Providing useful libraries doesn't preclude having done things right. Supplying a bare minimum of libraries does not preclude having made them miserable. There are plenty of awkward moments in using Common Lisp libraries that have made this plain to me. Your suggestion that "research first, and do the best" is unpopular for "obvious reasons" is just hand-waving. The "obvious reasons" that are left unstated here are that "research first and do the best" languages general suck, hard. They suck because they sit in toy environments for years while the "release early and iterate" languages flourish under constant adaptation to real world usage. Both will have warts. The latter will be worth using. Suggesting that "Clojure is closer to Ruby that Lisp" is just silly. What lisp? Scheme and Common Lisp, both definitely Lisps, are easily as different from each other as Clojure is from either. Ruby's insane class monkey patching is closer to the type of advice you find in Common Lisp than the immutable datatypes and carefully conceived concurrency primitives found in Clojure. Common Lisps many different name classes are a horror found in few modern languages. There's nothing in Clojure's "clever special syntax" that many developers did not toy with using reader macros and other abominations. Your suggestion that the olders lisps data structures, usually cobbled together with a pattern of lists and a prayer, are somehow more thought through than Clojures is both ignorance and meanness combined. Yes, Common Lisp had many builtin and library added datatypes. No, it didn't stop alists and structure built from underlying alists from being its fondest love. As for classifying Ruby and Clojure as "scripting" languages, please define "scripting" language. It's a meaningless term for nearly anything other than `bash`.

hkolek 13y ago

But afaik TCO is only a requirement for Scheme implementations, not for e.g. Common Lisp (i.e. you don't need to implement TCO to satisfy the Common Lisp standard). I don't see how the lack of TCO prevents it from being a valid Lisp dialect.

cgag 13y ago
Do you need to implement the common lisp standard to be "a lisp"? What is a lisp?
- hkolek 13y ago
  Exactly my point. I was just using CL as example because I think it would be hard to argue that it is not a Lisp yet the standard doesn't guarantee TCO. > What is a lisp? It's a very good question. I think PG sums it up quite nicely in "Revenge of the Nerds" [1]. Although, now that I'm thinking about it, I'm not quite sure there's any point in classifying something as a Lisp or not... [1] http://www.paulgraham.com/icad.html http://www.paulgraham.com/icad.html

gsg 13y ago

Emacs lisp doesn't guarantee TCO (and in practice does not perform it at all), and yet few people claim that it is not a dialect of lisp.

dschiptsov 13y ago

Without TCO you have stack overflows, and without proper numeric tower you have integer overflows. Roughly speaking, one of the aspect of why it isn't Lisp is underlying Java stuff.

hkolek 13y ago
I think we have already established that TCO is not necessary to be a Lisp (CL, Emacs Lisp). While it's true that Clojure doesn't have a proper numeric tower it does have bignum support and arbitrary precision math operators which will not overflow. But either way, imo this is not a defining feature of a Lisp dialect.
- dschiptsov 13y ago
  In fact, all non-toy Lisp implementation provide TCO - http://0branch.com/notes/tco-cl.html http://0branch.com/notes/tco-cl.html because, it seems, it's a natural feature of a Lisp system (Scheme just requires it). Again, Lisp could be defined as a limited set of conventions/features. As long as some other features, such as CLOS added there is no problem, but if some features are broken, then it is not Lisp anymore. It is just doesn't walk like a duck. Let's say that Clojure was developed with a "put everything useful together" or Ruby-approach, if you wish, which is very popular for scripting languages, while development of Scheme and other Lisp dialects was founded on "put only what is absolutely essential, and done right". The first approach "stuff anything in" you could see almost everywhere. The second approach "research first, and do the best" is unpopular for the obvious reasons and could be rarely seen only in masterpieces, such as Gambit-C, nginx, old-school marvels such as Informix. So, in my opinion, Clojure is much closer to Ruby than to Lisp (let's not be deceived by parentheses) - it is a scripting language (to quickly put everything together with variety of clever special syntax and fancy data-structures without much thinking about implementation details). This is, of course, most productive approach to coding - this is why people love scripting languages so much.
  - knome 13y ago
    Your manner of dismissing LISPs without TCO allows you is something of a No True Scotsman argument, enabling you to proclaim counter examples toys by merit of their being counter examples. Yes, most lisps have it. I don't think anyone denies emacs-lisp or AutoLISP were Lisps due to their lacking it. Your suggestion of "let's say ..." is based in what appears to be complete lack of familiarity with all of the languages involved. Providing useful libraries doesn't preclude having done things right. Supplying a bare minimum of libraries does not preclude having made them miserable. There are plenty of awkward moments in using Common Lisp libraries that have made this plain to me. Your suggestion that "research first, and do the best" is unpopular for "obvious reasons" is just hand-waving. The "obvious reasons" that are left unstated here are that "research first and do the best" languages general suck, hard. They suck because they sit in toy environments for years while the "release early and iterate" languages flourish under constant adaptation to real world usage. Both will have warts. The latter will be worth using. Suggesting that "Clojure is closer to Ruby that Lisp" is just silly. What lisp? Scheme and Common Lisp, both definitely Lisps, are easily as different from each other as Clojure is from either. Ruby's insane class monkey patching is closer to the type of advice you find in Common Lisp than the immutable datatypes and carefully conceived concurrency primitives found in Clojure. Common Lisps many different name classes are a horror found in few modern languages. There's nothing in Clojure's "clever special syntax" that many developers did not toy with using reader macros and other abominations. Your suggestion that the olders lisps data structures, usually cobbled together with a pattern of lists and a prayer, are somehow more thought through than Clojures is both ignorance and meanness combined. Yes, Common Lisp had many builtin and library added datatypes. No, it didn't stop alists and structure built from underlying alists from being its fondest love. As for classifying Ruby and Clojure as "scripting" languages, please define "scripting" language. It's a meaningless term for nearly anything other than `bash`.