3 ms·

looks cool! I hope new impl can remove the bad parts from std. CL

by jerry_ming 12y ago

brudgers 12y ago
What parts of Common Lisp are bad? Wouldn't removing them require revising the standard [ANSI INCITS 226-1994 (R2004)]?
- jlarocco 12y ago
  Most of the bad parts come from Lisp being so old and the standard being written at a time when nobody knew what was going to win out. Look at "make-pathname" [1], for example. It was made as general as possible as a compromise between all the different filesystem path representations used at the time. On modern systems, several of the parameters, like the host, device, and version don't really make sense any more, but they're still there for backwards compatibility. Another thing that bothers some people (not me) are function names like "car" and "cdr", which come from the assembly language instructions of the 1950s era computer where the first Lisp was implemented. I think most people use "first" and "rest" these days, but car, cdr, cadr, etc. are still used all over the place. Somewhat related, there's more inconsistent naming than in most languages. The destructive form of concatenate is nconc, but the destructive form of reverse is nreverse, etc.. Most built-in predicates end with "p", but some of the older ones don't. These days there's pretty solid consensus on how things should have been done, and how they should be done in the future, but we're still stuck with the old stuff. It's basically 60 years of backwards compatibility concessions. You're right, removing the bad parts of Common Lisp would technically require coming out with a new version of the standard, "Common Lisp 2015" or something, but I don't think anybody has proposed doing that. My guess is it's easier to just come out with a new Lisp dialect and hope people start using it, like Clojure has done, than the massive resource sink of coming up with a revised standard. [1] http://www.lispworks.com/documentation/HyperSpec/Body/f_mk_pn.htm#make-pathname http://www.lispworks.com/documentation/HyperSpec/Body/f_mk_p...
  - arethuza 12y ago
    I'm pretty sure you can use first and rest in Common Lisp if you don't like car and cdr http://en.wikibooks.org/wiki/Common_Lisp/Basic_topics/Lists http://en.wikibooks.org/wiki/Common_Lisp/Basic_topics/Lists
    - Blackthorn 12y ago
      As usual, problems come when reading someone else's code, not writing your own.
      - aidenn0 12y ago
        If you make a dialect without car/cdr the first thing about 30% of lisp hackers will do is write a macro to generate definitions for all of these: http://www.lispworks.com/documentation/HyperSpec/Body/f_car_c.htm http://www.lispworks.com/documentation/HyperSpec/Body/f_car_...
  - TeMPOraL 12y ago
    > Another thing that bothers some people (not me) are function names like "car" and "cdr", which come from the assembly language instructions of the 1950s era computer where the first Lisp was implemented. I think most people use "first" and "rest" these days, but car, cdr, cadr, etc. are still used all over the place. What I often see on the Internet is people complaining about car/cdr and suggesting to replace them with first/rest or equivalent. Most of the times those people don't understand why doing so is a bad idea. Cons cells can be (and are, all the time) used to build arbitrary data structures, not just lists. "first" and "rest" or "head" and "tail" make sense if you're dealing with a linked list (and notice, that Common Lisp does provide you such named functions), but they are not right names if your structure is a tree, or a graph (yes, you can build cyclical structures with cons cells). Sure, car/cdr terms are relicts of the old architecture, but I'm yet to see someone propose names that are agnostic to data structures constructed with cons cells. And, as some old Lisp hacker mentioned somewhere, car/cdr combinations like caaddr, etc. are easy to say over the phone ;).
    - 12y ago
- vlowther 12y ago
  That nil does double duty as boolean false and shorthand for '(). Scheme got it right with #f not being the same thing as '()
  - sedachv 12y ago
    I'm in the minority, but that's something that annoys me about Scheme. Lisp-style list processing code is more concise when nil is false. I also think array-processing or Haskell list style code is better than Lisp style list code, so IMO most Scheme code ends up with the worst of both worlds.

looks cool! I hope new impl can remove the bad parts from std. CL

brudgers 12y ago

What parts of Common Lisp are bad? Wouldn't removing them require revising the standard [ANSI INCITS 226-1994 (R2004)]?

jlarocco 12y ago
Most of the bad parts come from Lisp being so old and the standard being written at a time when nobody knew what was going to win out. Look at "make-pathname" [1], for example. It was made as general as possible as a compromise between all the different filesystem path representations used at the time. On modern systems, several of the parameters, like the host, device, and version don't really make sense any more, but they're still there for backwards compatibility. Another thing that bothers some people (not me) are function names like "car" and "cdr", which come from the assembly language instructions of the 1950s era computer where the first Lisp was implemented. I think most people use "first" and "rest" these days, but car, cdr, cadr, etc. are still used all over the place. Somewhat related, there's more inconsistent naming than in most languages. The destructive form of concatenate is nconc, but the destructive form of reverse is nreverse, etc.. Most built-in predicates end with "p", but some of the older ones don't. These days there's pretty solid consensus on how things should have been done, and how they should be done in the future, but we're still stuck with the old stuff. It's basically 60 years of backwards compatibility concessions. You're right, removing the bad parts of Common Lisp would technically require coming out with a new version of the standard, "Common Lisp 2015" or something, but I don't think anybody has proposed doing that. My guess is it's easier to just come out with a new Lisp dialect and hope people start using it, like Clojure has done, than the massive resource sink of coming up with a revised standard. [1] http://www.lispworks.com/documentation/HyperSpec/Body/f_mk_pn.htm#make-pathname http://www.lispworks.com/documentation/HyperSpec/Body/f_mk_p...
- arethuza 12y ago
  I'm pretty sure you can use first and rest in Common Lisp if you don't like car and cdr http://en.wikibooks.org/wiki/Common_Lisp/Basic_topics/Lists http://en.wikibooks.org/wiki/Common_Lisp/Basic_topics/Lists
  - Blackthorn 12y ago
    As usual, problems come when reading someone else's code, not writing your own.
    - aidenn0 12y ago
      If you make a dialect without car/cdr the first thing about 30% of lisp hackers will do is write a macro to generate definitions for all of these: http://www.lispworks.com/documentation/HyperSpec/Body/f_car_c.htm http://www.lispworks.com/documentation/HyperSpec/Body/f_car_...
- TeMPOraL 12y ago
  > Another thing that bothers some people (not me) are function names like "car" and "cdr", which come from the assembly language instructions of the 1950s era computer where the first Lisp was implemented. I think most people use "first" and "rest" these days, but car, cdr, cadr, etc. are still used all over the place. What I often see on the Internet is people complaining about car/cdr and suggesting to replace them with first/rest or equivalent. Most of the times those people don't understand why doing so is a bad idea. Cons cells can be (and are, all the time) used to build arbitrary data structures, not just lists. "first" and "rest" or "head" and "tail" make sense if you're dealing with a linked list (and notice, that Common Lisp does provide you such named functions), but they are not right names if your structure is a tree, or a graph (yes, you can build cyclical structures with cons cells). Sure, car/cdr terms are relicts of the old architecture, but I'm yet to see someone propose names that are agnostic to data structures constructed with cons cells. And, as some old Lisp hacker mentioned somewhere, car/cdr combinations like caaddr, etc. are easy to say over the phone ;).
  - 12y ago
vlowther 12y ago
That nil does double duty as boolean false and shorthand for '(). Scheme got it right with #f not being the same thing as '()
- sedachv 12y ago
  I'm in the minority, but that's something that annoys me about Scheme. Lisp-style list processing code is more concise when nil is false. I also think array-processing or Haskell list style code is better than Lisp style list code, so IMO most Scheme code ends up with the worst of both worlds.