cl-strings, a much useful string manipulation library

[vindarel]

I wish I had discovered it earlier, dealing was strings was so frustrated that I wrote my own little library and even sent it to quicklisp. But there's cl-strings.

[PuercoPop]

The tone of thread may be a little harsh but the issues raised by Drewc are valid. Don't think we should recommend that library

https://www.reddit.com/r/lisp/comments/49qwlw/clstrings_my_first_open_source_project_ideas_to/d0ucfv0/?utm_content=permalink&utm_medium=front&utm_source=reddit&utm_name=lisp

[vindarel]

Thanks for the pointer !

Let's discuss the issues: basically, all his questions are about "what's wrong with the built-in way ?" and yes, the built-in way is a BIG issue. I totally agree with Anonyratti's answer:

Unfortunately, lots of the built in functions are inelegant, particularly with strings. It's not unreasonable for someone with a sense for elegance to want to build a more lucid system around them.

My pbs are, as a CL beginner and experienced python/js/elisp dev (elisp has s.el, which adresses kind of the same pbs and is very popular -indeed it was a relief):

• the built-ins are spread across many libraries. This appears very well on Drewc list: to manipulate strings, do I really have to hear about and use parse-number, the unusual format syntax, cl-ppcre, subseq, concatenate, coerce, the unusual loop construct ??? => frustrating and long to learn, when this simple task should be well accessible.
• the built-in is inelegant and too long: (format "~a{~a}" foo) (or something) instead of (join… ? (string-trim '(#\Space #\Newline #\Backspace #\Tab #\Linefeed #\Page #\Return #\Rubout) s)) instead of (trim …) ? (concatenate 'string …) when I do operate on strings ? (and concatenate can not insert a separator) (cl-ppcre:replace-all… which operates on regexps when I just want to replace some text ? Many answers (on SO, Drewc's…) say "you still can use a loop or sthg" but I-just-want-to-join-some-strings. (string-equal s1 s2 :end2 (min (length s1) (length s2)))) instead of a simple starts-with ?
• the built-in are not consistent, sometimes the string is the first argument, sometimes the last: frustrating to learn, more difficult to feed to pipes and arrows.

Those are the difficulties I encountered, while writing my first CL program. It was frustrating, without mentioning that the documentation out there is not great. I too wrote a little string manipulation library with my findings before moving on. (cl-str, before discovering cl-strings).

It's ok to me if there is some overlap with the built-ins that are ok, like string=, I think it's necessary to include them, just to have a complete library.

So I think there really is space for a library that makes things simpler, shorter, more consistent, easier to start, easier to discover.

[vindarel]

There are implementations issues though: https://github.com/diogoalexandrefranco/cl-strings/issues/2 The implementation isn't a model of CL style and the lib doesn't seem to be portable even if (fixed by a later commit) it has "100% test coverage and works at least on sbcl, ecl, ccl, abcl and clisp".

I'm ok to rewrite the suggestion with these warnings, saying "this fills a gap but there are some warnings" :)

[diogoalexandrefranco]

Glad this is useful @vindarel! Thanks for trying to give more visibility to cl-strings.

@PuercoPop I don't know the standards necessary for a lib to be recommended at LispLang, so I wouldn't argue that it should. But I would argue that Drewc's criticism is not that interesting: He is saying that he can do everything this lib does with other libraries and native functions - Well of course, that is precisely what I did, and is true of any library ever. The point of an utils library is to facilitate the user's job by providing a well tested, consistent API if he prefers to use one instead of implementing utilities himself. To each his own :)

Anyway, keep up the good work at LispLang!

[PuercoPop]

@PuercoPop I don't know the standards necessary for a lib to be recommended at LispLang

Certainly @eudoxia0 has editorial control, I'm just chipping in. Didn't expect it to devolve into a discussion.

@vindarel the problem is that Anonyratti's answer is they just states an opinion with no reasoning or observations behind. It is useless in a discussion. You may agree with it but it won't convince anyone. The use of the word 'elegant' is a Glittering generality. Something that Drew addresses (in a rather cryptic manner) but it is left unanswered. Notice how Similarly you add a lot of 'colourful' adjectives which contribute nothing to your argument.do nothing to advance your points. I could replace funky with resourceful 'always useful'. It wouldn't do anything to convince you.

• the built-ins are spread across many libraries.

That makes no sense. The built-ins are built-in. You don't have to load any library for them to be available. Now there is some functionality that is not provided by default in CL which is addressed by a 'common-core' of which Alexandria, split-sequence and parse-number form part of. Format and Loop are not unusual, they are part of the language and much like the rest of the language they may be a seem 'arcane' at times but are useful and play well with other parts of the language.

Loop is not really long to learn, the every day clauses are with := for :in, for :from, for := and for :across. Then :repeat, :while, :until and :do. and :collect and :finally. Also remembering that all the bindings clauses can use destructing lambda-lists. For format you are mostly covered with ~A, ~% and ~{~A~^~}. You can find out what each format directly does with M-x common-lisp-hyperspec-format.

the built-in is too long

True, we use tab-completion (with c-p-c) for that. destructuring-bind also suffers from this minor problem

"you still can use a loop or sthg" but I-just-want-to-join-some-strings

It seems to me that the problem is that you don't want to use loop for some reason not a problem with the ways to do so by CL.

the built-in are not consistent, sometimes the string is the first argument, sometimes the last: frustrating to learn, more difficult to feed to pipes and arrows.

Most people use eldoc so they don't have to remember stuff like that. Also due to the lack of syntax for function composition and partial application (something addressed by curry-compose-reader-macros) it not common to program with pipes and arrows but instead use let*. With let* you can name the intermediate results allowing one to convey meaning to them, helping readability but sacrificing terseness. Also it is common for the implementations of pipes to be incorrect. If I had to use a pipe macro I'd only consider using only ever to use arrow-macros. But mostly due to 'trust through proxy'

---

@diogoalexandrefranco

He is saying that he can do everything this lib does with [...] native functions [...] and is true of any library ever.

It is not true of all library and that is not their point. Their intention behind the questions is for you to really ask yourself. Not just a rhetorical device. If you come up with an answer it will allow you to describe what cl-strings does more accurately. Instead of a blanket statement like 'make it even easier to manipulate text'. If your library is geared towards CL programmers, that already know CL. So what is the motivation to learn a new API that does basically the same things that CL already does or are trivial to write? Can't see how that would seem like a good idea. Now I'm under the impression that you think that cl-strings API is qualitatively better that the built-in ways provided by CL, but you should be able to state why (i.e. Answer Drew's question, not evade it saying that is not a useful question).

Btw I don't want to discourage you. You wrote a library thought it could be useful to others and shared it. I'm glad you did and that you asked for feedback.

My 2c, Happy Hacking to both of you

[vindarel]

I added this on cliki.