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
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.
> 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
It's not that bad, there are other languages which have this problem - you can see exactly the same situation in JS-land, for example. It would be much worse if not for quicklisp. I think quicklisp and asdf are among the best package distribution tools: I feel it's better than pip and gem and similar to npm. Installing a library is literally a single line in your code. There's the problem with finding the package you need and it's harder than with JS and npm, but doable.
BTW: what do you do to learn CL? I'm using StumpWM as my window manager and I think it's one of the best ways of learning CL. With SLIME, then, you get almost Lisp-only environment, especially if you use Emacs for your other editing too. I wrote a couple of blog posts[1] about StumpWM and posted my config on GitHub[2].
If you already know another programming language, you can try PCL[1]; it's a decent introduction. If you get stuck on something feel free to ask on IRC (#lisp on freenode).
There is a library called alexandria[2] that covers a lot of obvious missing-features from the standard library (e.g. emptyp to test for an empty sequence).
Lastly the hyperspec[3] is actually quite useful as a library reference.
The best thing I've done is watch a video on making a reddit clone in Lisp. I couldn't get the libraries to work, but I plan on using other libraries to do the same thing either tomorrow or the next day. It's made me realize that I really need to start walking through other people's code.
https://vimeo.com/138249727
Google's LISP koans which is ~30 exercises where you complete the code and make the tests pass. Covers everything from mapcar to multi-threading.
https://github.com/google/lisp-koans
I'm currently on Ch. 9/32 of Peter Seigel's "Practical Common Lisp". I find the book to be a much better resource after already being familiar with the topics covered. It does a great job of going into the nuances and gotchas of the language, but because is so much more text than code, it's hard for me to appreciate all of those little details if I'm still trying to grasp the fundamentals of the topic.
http://www.gigamonkeys.com/book/
I write all the code I see with a pencil and paper (including all of those koans). I read a block of code and then try to rewrite it from memory.
Currently using vim. Haven't gotten around yet to using a live environment.
Future resources:
Paul Graham's "Roots of Lisp"
Paul Graham's "On Lisp"
Build a Lisp compiler
SICP
Paradigms of Artificial Intelligence Programming
Upgrade my editor
Yeah, there's a lot I want to go through. It's gonna take me a few months just to go through all of the resources I have bookmarked so far. And I haven't even started looking for code that I want to read. End goal is to master Lisp.
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.
The problem with the name 'remove-if-not' is that it's both more fundamental and much more common in actual use than 'remove-if', yet its name is both longer to type and conceptually more complex.
Selecting a subcollection of elements that satisfy a predicate is a natural primitive. My favorite name for it is 'filter'; that's what I've called it in FSet [0]. I haven't defined 'filter-not'; usually the predicate is an explicit lambda expression, in which case adding the negation is straightforward, and even when a lambda is not needed, it's easy enough to write something like '(filter (complement #'integerp) ...)'.
Anyway, even though I prefer 'filter', I could live with 'keep-if'. And by the argument I just gave, we wouldn't really need 'remove-if' anymore. The problem is 'delete-if'/'delete-if-not'; what do we do with them? I guess I would rename 'delete-if-not' to 'nkeep-if' (by analogy with 'nreverse' and 'nsubstitute') and discard 'delete-if'.
I completely disagree. Remove-if-not is explicit. You know exactly what it does just by reading it. Your suggestion of filter could either mean use this filter to only grab the the things I want or use this filter to filter out the things I don't want. Complaining about the complexity of a name like "remove-if-not" makes absolutely no sense to me. Anyone can read that name and know exactly what it does. You only know what filter means because of your familiarity with it and not because of any inherit simplicity in its name.
And don't forget to check out cl-interpol. Besides being a perfect companion to cl-ppcre, its great in itself if you like things like string interpolation.
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.)
> 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.
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]
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.
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.
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.
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?
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.
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.
Readit News
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
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.
It's not that bad, there are other languages which have this problem - you can see exactly the same situation in JS-land, for example. It would be much worse if not for quicklisp. I think quicklisp and asdf are among the best package distribution tools: I feel it's better than pip and gem and similar to npm. Installing a library is literally a single line in your code. There's the problem with finding the package you need and it's harder than with JS and npm, but doable.
BTW: what do you do to learn CL? I'm using StumpWM as my window manager and I think it's one of the best ways of learning CL. With SLIME, then, you get almost Lisp-only environment, especially if you use Emacs for your other editing too. I wrote a couple of blog posts[1] about StumpWM and posted my config on GitHub[2].
[1] https://klibert.pl/posts/stumpwm.html https://klibert.pl/output/stumpwm-better-modeline.html
[2] https://github.com/piotrklibert/stumpwm-config/
There is a library called alexandria[2] that covers a lot of obvious missing-features from the standard library (e.g. emptyp to test for an empty sequence).
Lastly the hyperspec[3] is actually quite useful as a library reference.
1: http://gigamonkeys.com/book/
2: https://common-lisp.net/project/alexandria/draft/alexandria....
3: http://www.lispworks.com/documentation/HyperSpec/Front/Conte...
The best thing I've done is watch a video on making a reddit clone in Lisp. I couldn't get the libraries to work, but I plan on using other libraries to do the same thing either tomorrow or the next day. It's made me realize that I really need to start walking through other people's code. https://vimeo.com/138249727
Google's LISP koans which is ~30 exercises where you complete the code and make the tests pass. Covers everything from mapcar to multi-threading. https://github.com/google/lisp-koans
I'm currently on Ch. 9/32 of Peter Seigel's "Practical Common Lisp". I find the book to be a much better resource after already being familiar with the topics covered. It does a great job of going into the nuances and gotchas of the language, but because is so much more text than code, it's hard for me to appreciate all of those little details if I'm still trying to grasp the fundamentals of the topic. http://www.gigamonkeys.com/book/
I write all the code I see with a pencil and paper (including all of those koans). I read a block of code and then try to rewrite it from memory.
Currently using vim. Haven't gotten around yet to using a live environment.
Yeah, there's a lot I want to go through. It's gonna take me a few months just to go through all of the resources I have bookmarked so far. And I haven't even started looking for code that I want to read. End goal is to master Lisp.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.
Selecting a subcollection of elements that satisfy a predicate is a natural primitive. My favorite name for it is 'filter'; that's what I've called it in FSet [0]. I haven't defined 'filter-not'; usually the predicate is an explicit lambda expression, in which case adding the negation is straightforward, and even when a lambda is not needed, it's easy enough to write something like '(filter (complement #'integerp) ...)'.
Anyway, even though I prefer 'filter', I could live with 'keep-if'. And by the argument I just gave, we wouldn't really need 'remove-if' anymore. The problem is 'delete-if'/'delete-if-not'; what do we do with them? I guess I would rename 'delete-if-not' to 'nkeep-if' (by analogy with 'nreverse' and 'nsubstitute') and discard 'delete-if'.
[0] http://ergy.com/FSet.html
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.)
'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.
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/msg00...
TBH, if I found those things annoying enough to seek out this library, I would probably just use Clojure or some other language.
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.
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.
http://www.lispworks.com/documentation/HyperSpec/Body/f_docu...
You can statically analyze source code to pull them out, or ask the Lisp image for them, etc. Is there something missing?I would like to see more structure: expected arguments, return type, etc.
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?