5 ms·

There is no reason to build a second Common Lisp. Those ideas are all fairly well represented, and you only need something new if you're diverging to different

There is no reason to build a second Common Lisp. Those ideas are all fairly well represented, and you only need something new if you're diverging to different ideas: shen or haskell for types and values, julia for method dispatch, or pony for safe concurrency.

masukomi 9y ago
so, there's nothing to improve in CL? My experience seems to be almost diametrically opposed to yours. CL seems a fossil from 20+ ago that hasn't incorporated any of the Computer Science learnings and advancements that have been made since its standardization.
- bykovich 9y ago
  Can you elaborate?
  - lispm 9y ago
    Monads?
    - jerf 9y ago
      http://marijnhaverbeke.nl/monad.html http://marijnhaverbeke.nl/monad.html Getting monads into Lisp in a useful way would require the introduction of features that would certainly make it a different language. You may consider this a feature but you'd be arguing with a lot of people who consider it a bug. (I mean that sentence very seriously; no sarcasm, no joke, it is an accurate description of the situation, nor am I implying I would find the idea horrifying... it would simply be a quite significant change to the core type system.)
    - bykovich 9y ago
      Are monads an /advance/, or are they just a language feature that might be nice in some cases, pointless or harmful in others -- like any other feature?
      - dreamcompiler 9y ago
        Some monads like the maybe monad would be a dramatic improvement over just defaulting everything to nil everywhere. Likewise error monads would nicely complement the existing CL error mechanism. You can get some monad behavior in CL now. Bind is fairly easy to write in CL but unit is messy. And CL's lack of automatic currying doesn't help.
- lispm 9y ago
  > hasn't incorporated any of the Computer Science learnings and advancements somehow I fear that this is a good thing
- oconnore 9y ago
  I'm confused how you got to this interpretation after I listed a bunch of cool languages that (I think) have made many improvements to CL based on CS research. There is only so far you can go with an "everything is mutable -- but you can do anything you want with syntax" model. Common Lisp 2.0 is not Common Lisp, it's lessons learned from Common Lisp plus new ideas rolled into something completely different. Just as an example, Julia's take on CLOS is far more powerful, it preserves compile time macros, and takes SBCL to the cleaners on any benchmark you can find.
lispm 9y ago
But there is need for an update of the Common Lisp standard. There are lots of improvements needed without creating a new language. There are different implementations for various extensions and one needs to standardize them, instead of providing a portable wrapper library. Stuff like Unicode strings/characters/files/streams really needs to be defined on a language level. Typical things to fix: * basic threading * Unicode characters and strings * less undefined behavior * environments * extensible loops * CLOS conditions and streams * extensible sequences * security (fixing reader eval, ...) and more... http://www.cliki.net/Proposed%20ANSI%20Revisions%20and%20Clarifications http://www.cliki.net/Proposed%20ANSI%20Revisions%20and%20Cla... http://www.cliki.net/Proposed%20Extensions%20To%20ANSI http://www.cliki.net/Proposed%20Extensions%20To%20ANSI

masukomi 9y ago

so, there's nothing to improve in CL? My experience seems to be almost diametrically opposed to yours. CL seems a fossil from 20+ ago that hasn't incorporated any of the Computer Science learnings and advancements that have been made since its standardization.

bykovich 9y ago
Can you elaborate?
- lispm 9y ago
  Monads?
  - jerf 9y ago
    http://marijnhaverbeke.nl/monad.html http://marijnhaverbeke.nl/monad.html Getting monads into Lisp in a useful way would require the introduction of features that would certainly make it a different language. You may consider this a feature but you'd be arguing with a lot of people who consider it a bug. (I mean that sentence very seriously; no sarcasm, no joke, it is an accurate description of the situation, nor am I implying I would find the idea horrifying... it would simply be a quite significant change to the core type system.)
  - bykovich 9y ago
    Are monads an /advance/, or are they just a language feature that might be nice in some cases, pointless or harmful in others -- like any other feature?
    - dreamcompiler 9y ago
      Some monads like the maybe monad would be a dramatic improvement over just defaulting everything to nil everywhere. Likewise error monads would nicely complement the existing CL error mechanism. You can get some monad behavior in CL now. Bind is fairly easy to write in CL but unit is messy. And CL's lack of automatic currying doesn't help.
lispm 9y ago
> hasn't incorporated any of the Computer Science learnings and advancements somehow I fear that this is a good thing
oconnore 9y ago
I'm confused how you got to this interpretation after I listed a bunch of cool languages that (I think) have made many improvements to CL based on CS research. There is only so far you can go with an "everything is mutable -- but you can do anything you want with syntax" model. Common Lisp 2.0 is not Common Lisp, it's lessons learned from Common Lisp plus new ideas rolled into something completely different. Just as an example, Julia's take on CLOS is far more powerful, it preserves compile time macros, and takes SBCL to the cleaners on any benchmark you can find.

lispm 9y ago

But there is need for an update of the Common Lisp standard. There are lots of improvements needed without creating a new language. There are different implementations for various extensions and one needs to standardize them, instead of providing a portable wrapper library. Stuff like Unicode strings/characters/files/streams really needs to be defined on a language level. Typical things to fix: * basic threading * Unicode characters and strings * less undefined behavior * environments * extensible loops * CLOS conditions and streams * extensible sequences * security (fixing reader eval, ...) and more... http://www.cliki.net/Proposed%20ANSI%20Revisions%20and%20Clarifications http://www.cliki.net/Proposed%20ANSI%20Revisions%20and%20Cla... http://www.cliki.net/Proposed%20Extensions%20To%20ANSI http://www.cliki.net/Proposed%20Extensions%20To%20ANSI