7 ms·

CL21 – Common Lisp in the 21st Century

98 points by eruditely 11y ago

eruditely 11y ago
What on earth happened to this project? It looked really promising. Is it all left to racket now?
- brudgers 11y ago
  Common Lisp has a standard. The most recent major work on standards may be ISLisp. http://www.islisp.info/ http://www.islisp.info/ Creating a consensus language specificatoin is hard. It takes a community of people willing to work over a long period of time in very detailed ways. Throwing a proposal up on Github is unlikely to create a community and organization with the required commitments.
- jlarocco 11y ago
  For me personally, I'm already used to the ugly CL syntax that it's working around (hashes), already familiar and comfortable with the underlying libraries it's using (cl-ppcre, etc.), or don't find the features particularly useful (laziness, etc.). TBH, if I found those things annoying enough to seek out this library, I would probably just use Clojure or some other language.
  - ScottBurson 11y ago
    That's the problem with any CL cleanup project: it's mostly going to appeal to newcomers to CL, who don't already have a large code base in the language, full of their own macros that address at least a few of the same issues. Not that CL couldn't use cleaning up. But to really make the new dialect popular, you'd have to focus on attracting new users, which would require things like writing books, or at least updating some of the existing books (e.g. Peter Seibel's). In short, defining and implementing the new dialect is only the first step of a long slog.
    - OopsCriticality 11y ago
      Speaking of books, have you by chance read Weitz's new one? https://www.apress.com/9781484211779 https://www.apress.com/9781484211779
      - akkadmed 11y ago
        Worth it.
    - dwc 11y ago
      > mostly going to appeal to newcomers to CL ... you'd have to focus on attracting new users It's my observation that CL regularly attracts new users, who grumble a bit at first and then fall in love. Then they drift away to other langs, keeping an affection for sexps, macros, and the numerous elegant aspects of CL. But drift away they do. IMO, if CL could keep more of the people who learn it well enough to love it, then it would be thriving. I have some opinions on why people drift away and how that could be addressed but they're not especially well formed at this time.
      - ScottBurson 11y ago
        > I have some opinions on why people drift away and how that could be addressed but they're not especially well formed at this time. I would like to hear them nonetheless.
        dwc 11y ago
        I would rather not say until I've thought it out some more. A bag of mushy thoughts with a grain of truth in them would probably be provocative and wouldn't provide much utility for the CL community. Instead, here's one of the things that started me thinking about this... Some years back, Xach created the library manager Quicklisp, filling a huge hole in the lisp ecosystem. It's nice work and quickly became the defacto standard. Lots good to say about it and nothing bad, really. The thing that got me thinking was that this actually needed to be done at the time Xach did it. CL had been around a long time officially and even longer unofficially, and this really important piece of infrastructure had not been done. How could that be? "How could that be?" leads to more questions, and possible answers, and some loose ideas about moving forward. That's where I'm at, and I don't want to say more until I have something concrete and constructive. I wouldn't mind having a speculative conversation (that would help me greatly), but I think throwing out half baked ideas would do nothing more than the existing corpus of "why lisp isn't successful" blog posts, so I don't want to have that conversation somewhere like HN.
such_a_casual 11y ago
I am currently learning common lisp. The only thing I've really found lacking is support for basic string operations. I'm sure there is a solid library out there for things like replace(), but it seems silly for everyone to possibly be using separate libraries, or in-house implementations for standard string operations. It creates an unnecessary barrier to code readability. From what I've heard around the grape vine, this is a result of the ANSI standard being released prior to the popularization of these functions in other languages. If the CL specification is ever updated, I am sure that this problem will be solved. I am surprised this github project didn't acknowledge this. P.S. Changing the name of 'Remove-if-not' makes absolutely no sense to me. Remove-if and Remove-if-not make perfect sense together. Adding a whole new word to memorize "Keep" just makes code less readable. Especially since Keep isn't seen anywhere else in the language. Further-more the redundancy in the names 'remove-if' and 'remove-if-not' make you think about how these functions are actually the same, with only a small caveat. 'remove-if' and 'keep-if' make you think of these functions as different things, as different ideas, very unlispy. edit: just checked cl-ppcre's documentation and learned that split and replace are covered by that lib. Seeing as cl-ppcre seems to be used so widely, I take back what I said. Lisp is perfect once again.
- martinflack 11y ago
  It's all there with libraries, if you hunker down. I came from Perl so yes it's harder. Library-wise, CL-PPCRE and SPLIT-SEQUENCE are your friends, along with a bunch of the sequence operations in the ANSI spec, and finally, you should get comfortable doing some string stuff in LOOP going char by char or word by word.
  - such_a_casual 11y ago
    Thank you.
  - ralt 11y ago
    I like UIOP:SPLIT-STRING instead of SPLIT-SEQUENCE.
- klibertp 11y ago
eudox 11y ago
As someone who writes CL for fun, I think all "let's get the core language (any language) API right this time" efforts are ultimately doomed to perdition and entropy. I'd rather have an API that's not quite perfect, but has had much thought and wisdom put into it, and is as stable as continents, than an API that's always iterating towards some unreachable Platonic idea of perfection. As an aside, the author has also created a -- likely more agreeable -- spin off library that's a simpler interface to cl-ppcre: https://github.com/fukamachi/re21 https://github.com/fukamachi/re21
mcculley 11y ago
I'm surprised all of the modern attempts at Lisp don't provide some kind of docstrings (i.e., JavaDoc-like documentation as a first class object available in the REPL). Why isn't that something that everyone expects in a modern language?
- codemac 11y ago
  Huh? Emacs, Guile, and the common lisp in this project have doc strings? What implementations are you referring to, and what features do you think they're missing?
  - mcculley 11y ago
    As I replied to martinflack, I was expecting to see it in the examples or source code. It wasn't obvious that it's inherited from the implementation language.
- martinflack 11y ago
  If I'm understanding your question correctly, that's been in there from ANSI CL. For example, when defining a function, after the lambda list, a string will be interpreted as a docstring and stored with the function definition. http://www.lispworks.com/documentation/HyperSpec/Body/f_docume.htm http://www.lispworks.com/documentation/HyperSpec/Body/f_docu... (defun test () "A test function" (+ 1 1)) => TEST (documentation 'test 'function) => "A test function" You can statically analyze source code to pull them out, or ask the Lisp image for them, etc. Is there something missing?
  - mcculley 11y ago
    Ah. I see. It wasn't obvious in either the examples or the source code. I would like to see more structure: expected arguments, return type, etc.
    - xenophonf 11y ago
      There are longstanding conventions for how to write those, same as with other languages or automatic document generation tools. Search for "lisp docstring style" or something to that effect. Here's a possibly non-authoritative example from the Emacs Lisp community: https://github.com/bbatsov/emacs-lisp-style-guide#docstrings https://github.com/bbatsov/emacs-lisp-style-guide#docstrings Edited to add: Documentation strings actually predate Common Lisp. They were available at least as early as Zetalisp (mid-1970s).
dschiptsov 11y ago
Currently there is an effort in GNU Emacs project to move a subset of Common Lisp in Emacs Lisp under the cl prefix, so one would say cl-let or cl-values, etc. It seems like a cool idea. If you disagree with some of CL's design or stylistic choices, which people familiar with Arc or Scheme would do, moving it out of the way is a good idea. BTW, a long ago in order or incorporate CL into Symbolics Zeta Lisp they used cl: prefix for some functions. Nothing is new under the Moon.)
- lispm 11y ago
  > BTW, a long ago in order or incorporate CL into Symbolics Zeta Lisp they used cl: prefix for some functions. Nothing is new under the Moon.) 'cl:' is no prefix in Zetalisp. Zetalisp uses packages (namespaces for symbols) just like Common Lisp, and 'cl' is the name of a package and ':' is the separator from package name and symbol name. A single colon shows that the symbol is exported - some part of an external interface. Thus cl:let is the 'let' exported from the 'cl' package. Emacs Lisp has no packages, no namespaces, no exports, imports, ... So 'cl-' is a part of the symbol name. It's just a prefix.
  - dschiptsov 11y ago
    Yeah, sorry. Having separate namespaces for packages is much better and prefixing is just naming conventions.
- PuercoPop 11y ago
  The reason there are adding the cl-prefix in cl-lib is that previously cl.el replaced elisp functions with the cl equivalent ones. lispm already covered that cl: is packages, not a prefix but I'd like to add one of the reasons elisp doesn't have any similar of namespaces is due RMS thiking "prefixes are better"[0] [0]: https://lists.gnu.org/archive/html/emacs-devel/2013-07/msg00794.html https://lists.gnu.org/archive/html/emacs-devel/2013-07/msg00...

98 points by eruditely 11y ago

eruditely 11y ago

What on earth happened to this project? It looked really promising. Is it all left to racket now?

brudgers 11y ago
Common Lisp has a standard. The most recent major work on standards may be ISLisp. http://www.islisp.info/ http://www.islisp.info/ Creating a consensus language specificatoin is hard. It takes a community of people willing to work over a long period of time in very detailed ways. Throwing a proposal up on Github is unlikely to create a community and organization with the required commitments.
jlarocco 11y ago
For me personally, I'm already used to the ugly CL syntax that it's working around (hashes), already familiar and comfortable with the underlying libraries it's using (cl-ppcre, etc.), or don't find the features particularly useful (laziness, etc.). TBH, if I found those things annoying enough to seek out this library, I would probably just use Clojure or some other language.
- ScottBurson 11y ago
  That's the problem with any CL cleanup project: it's mostly going to appeal to newcomers to CL, who don't already have a large code base in the language, full of their own macros that address at least a few of the same issues. Not that CL couldn't use cleaning up. But to really make the new dialect popular, you'd have to focus on attracting new users, which would require things like writing books, or at least updating some of the existing books (e.g. Peter Seibel's). In short, defining and implementing the new dialect is only the first step of a long slog.
  - OopsCriticality 11y ago
    Speaking of books, have you by chance read Weitz's new one? https://www.apress.com/9781484211779 https://www.apress.com/9781484211779
    - akkadmed 11y ago
      Worth it.
  - dwc 11y ago
    > mostly going to appeal to newcomers to CL ... you'd have to focus on attracting new users It's my observation that CL regularly attracts new users, who grumble a bit at first and then fall in love. Then they drift away to other langs, keeping an affection for sexps, macros, and the numerous elegant aspects of CL. But drift away they do. IMO, if CL could keep more of the people who learn it well enough to love it, then it would be thriving. I have some opinions on why people drift away and how that could be addressed but they're not especially well formed at this time.
    - ScottBurson 11y ago
      > I have some opinions on why people drift away and how that could be addressed but they're not especially well formed at this time. I would like to hear them nonetheless.
      - dwc 11y ago
        I would rather not say until I've thought it out some more. A bag of mushy thoughts with a grain of truth in them would probably be provocative and wouldn't provide much utility for the CL community. Instead, here's one of the things that started me thinking about this... Some years back, Xach created the library manager Quicklisp, filling a huge hole in the lisp ecosystem. It's nice work and quickly became the defacto standard. Lots good to say about it and nothing bad, really. The thing that got me thinking was that this actually needed to be done at the time Xach did it. CL had been around a long time officially and even longer unofficially, and this really important piece of infrastructure had not been done. How could that be? "How could that be?" leads to more questions, and possible answers, and some loose ideas about moving forward. That's where I'm at, and I don't want to say more until I have something concrete and constructive. I wouldn't mind having a speculative conversation (that would help me greatly), but I think throwing out half baked ideas would do nothing more than the existing corpus of "why lisp isn't successful" blog posts, so I don't want to have that conversation somewhere like HN.

such_a_casual 11y ago

I am currently learning common lisp. The only thing I've really found lacking is support for basic string operations. I'm sure there is a solid library out there for things like replace(), but it seems silly for everyone to possibly be using separate libraries, or in-house implementations for standard string operations. It creates an unnecessary barrier to code readability. From what I've heard around the grape vine, this is a result of the ANSI standard being released prior to the popularization of these functions in other languages. If the CL specification is ever updated, I am sure that this problem will be solved. I am surprised this github project didn't acknowledge this. P.S. Changing the name of 'Remove-if-not' makes absolutely no sense to me. Remove-if and Remove-if-not make perfect sense together. Adding a whole new word to memorize "Keep" just makes code less readable. Especially since Keep isn't seen anywhere else in the language. Further-more the redundancy in the names 'remove-if' and 'remove-if-not' make you think about how these functions are actually the same, with only a small caveat. 'remove-if' and 'keep-if' make you think of these functions as different things, as different ideas, very unlispy. edit: just checked cl-ppcre's documentation and learned that split and replace are covered by that lib. Seeing as cl-ppcre seems to be used so widely, I take back what I said. Lisp is perfect once again.

martinflack 11y ago
It's all there with libraries, if you hunker down. I came from Perl so yes it's harder. Library-wise, CL-PPCRE and SPLIT-SEQUENCE are your friends, along with a bunch of the sequence operations in the ANSI spec, and finally, you should get comfortable doing some string stuff in LOOP going char by char or word by word.
- such_a_casual 11y ago
  Thank you.
- ralt 11y ago
  I like UIOP:SPLIT-STRING instead of SPLIT-SEQUENCE.
klibertp 11y ago

eudox 11y ago

As someone who writes CL for fun, I think all "let's get the core language (any language) API right this time" efforts are ultimately doomed to perdition and entropy. I'd rather have an API that's not quite perfect, but has had much thought and wisdom put into it, and is as stable as continents, than an API that's always iterating towards some unreachable Platonic idea of perfection. As an aside, the author has also created a -- likely more agreeable -- spin off library that's a simpler interface to cl-ppcre: https://github.com/fukamachi/re21 https://github.com/fukamachi/re21

mcculley 11y ago

I'm surprised all of the modern attempts at Lisp don't provide some kind of docstrings (i.e., JavaDoc-like documentation as a first class object available in the REPL). Why isn't that something that everyone expects in a modern language?

codemac 11y ago
Huh? Emacs, Guile, and the common lisp in this project have doc strings? What implementations are you referring to, and what features do you think they're missing?
- mcculley 11y ago
  As I replied to martinflack, I was expecting to see it in the examples or source code. It wasn't obvious that it's inherited from the implementation language.
martinflack 11y ago
If I'm understanding your question correctly, that's been in there from ANSI CL. For example, when defining a function, after the lambda list, a string will be interpreted as a docstring and stored with the function definition. http://www.lispworks.com/documentation/HyperSpec/Body/f_docume.htm http://www.lispworks.com/documentation/HyperSpec/Body/f_docu... (defun test () "A test function" (+ 1 1)) => TEST (documentation 'test 'function) => "A test function" You can statically analyze source code to pull them out, or ask the Lisp image for them, etc. Is there something missing?
- mcculley 11y ago
  Ah. I see. It wasn't obvious in either the examples or the source code. I would like to see more structure: expected arguments, return type, etc.
  - xenophonf 11y ago
    There are longstanding conventions for how to write those, same as with other languages or automatic document generation tools. Search for "lisp docstring style" or something to that effect. Here's a possibly non-authoritative example from the Emacs Lisp community: https://github.com/bbatsov/emacs-lisp-style-guide#docstrings https://github.com/bbatsov/emacs-lisp-style-guide#docstrings Edited to add: Documentation strings actually predate Common Lisp. They were available at least as early as Zetalisp (mid-1970s).

dschiptsov 11y ago

Currently there is an effort in GNU Emacs project to move a subset of Common Lisp in Emacs Lisp under the cl prefix, so one would say cl-let or cl-values, etc. It seems like a cool idea. If you disagree with some of CL's design or stylistic choices, which people familiar with Arc or Scheme would do, moving it out of the way is a good idea. BTW, a long ago in order or incorporate CL into Symbolics Zeta Lisp they used cl: prefix for some functions. Nothing is new under the Moon.)

lispm 11y ago
> BTW, a long ago in order or incorporate CL into Symbolics Zeta Lisp they used cl: prefix for some functions. Nothing is new under the Moon.) 'cl:' is no prefix in Zetalisp. Zetalisp uses packages (namespaces for symbols) just like Common Lisp, and 'cl' is the name of a package and ':' is the separator from package name and symbol name. A single colon shows that the symbol is exported - some part of an external interface. Thus cl:let is the 'let' exported from the 'cl' package. Emacs Lisp has no packages, no namespaces, no exports, imports, ... So 'cl-' is a part of the symbol name. It's just a prefix.
- dschiptsov 11y ago
  Yeah, sorry. Having separate namespaces for packages is much better and prefixing is just naming conventions.
PuercoPop 11y ago
The reason there are adding the cl-prefix in cl-lib is that previously cl.el replaced elisp functions with the cl equivalent ones. lispm already covered that cl: is packages, not a prefix but I'd like to add one of the reasons elisp doesn't have any similar of namespaces is due RMS thiking "prefixes are better"[0] [0]: https://lists.gnu.org/archive/html/emacs-devel/2013-07/msg00794.html https://lists.gnu.org/archive/html/emacs-devel/2013-07/msg00...