Include a split-sequence library

svetlyak40wt commented 4 years ago

It is used by many libraries and some other utility libraries copy the functions from split-sequence.

digikar99 commented 4 years ago

EDIT:

Thread conclusion: split-sequence will be added, but owing to its small size, it'd share the page with other smallish libraries not-yet-known-to-me.
quickdocs provides a nice way to determine community consensus of (at least utility) libraries.
a tangential discussion of "batteries included" common lisp image

I haven't used it, but often find cl-ppcre:split and str:split sufficient. Are there any benefits to split-sequence?

I also noted that there are just three functions in there, so not worth a separate page either, unless you are referring to other unexported functions.

digikar99 commented 4 years ago

What might be worth mentioning rather is Common Lisp Utilities - or cl-utilities.

svetlyak40wt commented 4 years ago

I haven't used it, but often find cl-ppcre:split and str:split sufficient. Are there any benefits to split-sequence?

str and cl-ppcre work with strings, but split-sequence is able to work with strings, lists and vectors.

Also, I found yesterday that split-sequence functions were copied to a number of CL libraries. For example into the cl-utilities. However, split-sequence is maintained by https://github.com/sharplispers and evolve in time.

digikar99 commented 4 years ago

work with strings, lists and vectors.

Oh, right, had forgotten about the non-string sequences. A brief performance testing suggests, on SBCL 2.0.4, cl-utilities version is faster for strings and vectors and split-sequence for lists.

split-sequence is also said to have support for extended-sequences. cl-utilities v1.2.4 seems to be from 2006 (probably doesn't matter, other than the extended-sequence), and is quite redundant with alexandria.

Is there any consensus in the community about the usage of these two?

EDIT: Statistics from Feb 2018 suggest that split-sequence is highly used than cl-utilities.) Also, quickutil.

phoe commented 4 years ago

split-sequence has a large number of transitive dependencies since it's an ollllld library; it is, AFAIR, in the top 10 or so of all Quicklisp systems. It's also very simple - it is e.g. impossible to split "abcdAAefghAAijkl" by a two-character delimiter "AA" using only split-sequence.
cl-ppcre is a regex library that has splitting sequences only as one of its functionalities.
str is a more general-purpose string manipulation library that could just as easily be a vector manipulation library - see https://github.com/vindarel/cl-str/issues/49.

digikar99 commented 4 years ago

Okay, will include split-sequence, but not on a separate page on its own due to its smallish size - would, include other utility libraries as well. (Any suggestions?)

On a tangent: is there a "batteries-included" common lisp image somewhere?

svetlyak40wt commented 4 years ago

What do you mean saing "a "batteries-included" common lisp image"?

phoe commented 4 years ago

I don't think there is. I plan on creating one someday, but that is a far-fetched goal.

defunkydrummer commented 4 years ago

I don't think there is. I plan on creating one someday, but that is a far-fetched goal.

I was thinking of exactly the same idea a few days ago.

defunkydrummer commented 4 years ago

Is there any consensus in the community about the usage of these two?

Objective answer:

http://quickdocs.org/split-sequence/

Used by 109 libs on the ecosystem.

phoe commented 4 years ago

I was thinking of exactly the same idea a few days ago.

Perfect. Let us collaborate when my book is complete.

svetlyak40wt commented 4 years ago

What kind of "image" are you talking about guys?

Why do somebody need a "batteries included" where there are plenty of libraries in Quicklisp?

phoe commented 4 years ago

I was thinking of not really an "image" but more like a "distribution".

You say there are plenty of libraries but I say there are no sane defaults; whereas languages like Haskell or Rust have rather huge standard libraries, Common Lisp has no standard library other than the standard itself. It instead relies on a diaspora of libraries which are not named like std.string, std.gc, std.threads, std.sockets, std.mop, std.gray-streams but instead have fancy and counterintuitive names like alexandria, split-sequence, trivial-garbage, bordeaux-threads, iolib, closer-mop, trivial-gray-streams and so on. IMO that's a problem for Common Lisp in the contemporary times.

That's getting off-topic though - should we perhaps move that discussion elsewhere?

digikar99 commented 4 years ago

arrows is another small utility library I love. Though, only five projects use it. Though, does anyone know why nesting -<> needs a full code-walker rather than just a tree traversal?

phoe commented 4 years ago

Could be worthy to make a separate issue for an arrow lib.

vindarel commented 4 years ago

is there a "batteries-included" common lisp image somewhere? I plan on creating one someday, but that is a far-fetched goal.

same here.

I started a horrible something, not worth sharing. I like its name though :)

phoe commented 4 years ago

What is its name?

vindarel commented 4 years ago

tadadam

CIEL Is an Extended Lisp

"ciel" means sky in french, and CIEL is supposed to help you "import antigravity" as the XKCD strip etc. There's room for a catch phrase :p

digikar99 commented 4 years ago

My expectations from such an image is merely the inclusion of alexandria, iterate, split-sequence, may be, some parts of uiop (and may be arrows, and perhaps, a few more) in a single package. So, that development is as simple as (defpackage :foo (:use :extended-cl)).

phoe commented 4 years ago

I am thinking of something wider than that. Something that contains stuff like common-lisp.mop, common-lisp.sockets, common-lisp.threads, common-lisp.garbage, common-lisp.streams, common-lisp.os, and so on - utilities that are an integral part of the modern development but are abstracted away by portability libraries everywhere.

But then again, that's just my musing for the time being.

digikar99 commented 4 years ago

a few more

Yup, can agree with those as well. But, not hunchentoot, cl-who, lparallel and them.

phoe commented 4 years ago

Python has a simple http server bundled in its standard library, but a) we do not need to follow python's lead here, b) hunchentoot is far from simple. Same with cl-who that is a html generation library, and same with lparallel that directly builds a more advanced threadpooling concept on threads as OS primitives.

All of the above is my opinion, obviously, but I don't think these would belong in a hypothetical default standard library.

svetlyak40wt commented 4 years ago

I think it should be a package inferred system with some short name like lib.

This way, when my project depends on some parts of this system, only these parts will be loaded by ASDF.

For example, lib.asd:

(defsystem "lib"
   :class :package-inferred-system)

File str.lisp:

(uiop:define-package lib/str
    (:reexport #:str))

File http.lisp:

(uiop:define-package lib/http
    (:use #:dexador)
    (:export #:get #:post))

and so on.

This way, if my project X want to use only lib/str, then dexador will not be loaded as the dependency.

In some cases, it might define a compiler macro to make a better name or to add documentation to symbols.

phoe commented 4 years ago

This idea sounds very similar to Quickutil.

svetlyak40wt commented 4 years ago

Maybe, but with my approach, you don't need any client other than Quicklisp and ASDF.

digikar99 commented 4 years ago

Added.

cl-library-docs / common-lisp-libraries

Include a split-sequence library #1