sbcl VS cl-ppcre

Compare sbcl vs cl-ppcre and see what are their differences.

sbcl

Mirror of Steel Bank Common Lisp (SBCL)'s official repository (by sbcl)
Our great sponsors
  • SonarQube - Static code analysis for 29 languages.
  • Scout APM - Less time debugging, more time building
  • JetBrains - Developer Ecosystem Survey 2022
sbcl cl-ppcre
33 7
1,493 262
2.1% 1.5%
9.9 2.9
5 days ago 12 days ago
Common Lisp Common Lisp
GNU General Public License v3.0 or later BSD 2-clause "Simplified" License
The number of mentions indicates the total number of mentions that we've tracked plus the number of user suggested alternatives.
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.

sbcl

Posts with mentions or reviews of sbcl. We have used some of these posts to build our list of alternatives and similar projects. The last one was on 2022-06-17.

cl-ppcre

Posts with mentions or reviews of cl-ppcre. We have used some of these posts to build our list of alternatives and similar projects. The last one was on 2022-05-23.
  • The unreasonable effectiveness of f-strings and re.VERBOSE
    4 projects | news.ycombinator.com | 23 May 2022
    If the regular expression engine accepted tree structures instead of just strings, you could have first class definitions of fragments of regular expressions. Even better, you could define them as functions, so you could have parameterized fragments. So then you could just do something like http://edicl.github.io/cl-ppcre/#create-scanner2 without the bizarre definition syntax above.
    4 projects | news.ycombinator.com | 23 May 2022
    I must have a serious bug in my writing about this, because this was never about regex engines -- it's about literals and domain-specific sublanguages in general. Composing DSL programs by string concatenation is such a famous source of security bugs you see it in top-10 lists. I linked to the very similar example of a PEG parsing DSL.

    But any regex engine that can work with a parse tree shows the same principle, e.g. https://edicl.github.io/cl-ppcre/#create-scanner2

  • Adding Space to subst function
    1 project | reddit.com/r/lisp | 12 Apr 2022
    Take a look at - https://github.com/edicl/cl-ppcre
  • Common Lisp ASDF maintainer considers resignation
    1 project | reddit.com/r/lisp | 22 Jan 2022
    And here's what I believe represents the reality of the situation... Stas was indeed tired of ASDF's changes. Now the nature of what changes to make is a matter of judgement of course, but in this case (I'm thinking of SBCL's bug report request to update ASDF: https://bugs.launchpad.net/sbcl/+bug/1826074), it would be a different matter altogether if the discussion was centered on how best to make the new ASDF work with SBCL, but the thread reads to me like a man who had to put up with too much breakage for the upteenth time. Now, if (for the sake of argument :D) the change was of the necessary kind -- think hardware changes or security issues -- I can still see myself feeling wronged, it's human to do so. Because I don't trust ASDF anymore or I feel as if they (or other people at each step of the process) have not shared enough of the burden. But from the discussions I have read (https://github.com/edicl/cl-ppcre/pull/30) what the ASDF maintainers want to change does not seem unreasonable and they are willing to share the burden. But let us say it's truly a 50/50 deadlock. Well then Linus is right, show us the code, who dares wins. And Stas certainly has enough on his plate. But that's why we must cooperate. You don't have to be a diplomat to know the difference when two people want to work together and when one party wants out. And this setting makes more sense when you read (https://bugs.launchpad.net/sbcl/+bug/1823442) where Stas honestly states he wants nothing more to do with ASDF. I don't think it's unreasonable to surmise there's a bit more going on here than plainly technical issues.
  • Stas has alienated long-time ASDF maintainer Robert Goldman
    6 projects | reddit.com/r/Common_Lisp | 9 Jan 2022
    Could you just direct me to some existing discussions, in order to save time? I already read this one.
    6 projects | reddit.com/r/Common_Lisp | 9 Jan 2022
    That thread is not complete context; see also e.g. https://github.com/edicl/cl-ppcre/pull/30 and https://github.com/edicl/cl-fad/pull/24.
  • #"<your literal interpretation here>" (regular expression literals)
    2 projects | reddit.com/r/lisp | 4 Jul 2021
    I plan to use the regular expressions with a cl-ppcre wrapper, also emulating various clojure regular expression operations. Similar to re21, which doesn't quite support the operations in the way I'd like (or match the clojure operations), and whose regular expression literal syntax is "#//".

What are some alternatives?

When comparing sbcl and cl-ppcre you can also consider the following projects:

ccl - Clozure Common Lisp

abcl - Armed Bear Common Lisp <git+https://github.com/armedbear/abcl/> <--> <svn+https://abcl.org/svn> Bridge

sb-simd - A convenient SIMD interface for SBCL.

common-lisp-jupyter - A Common Lisp kernel for Jupyter along with a library for building Jupyter kernels.

BQN - An APL-like programming language. Self-hosted!

maiko - Medley Interlisp virtual machine

lisp-xl - Common Lisp Microsoft XLSX (Microsoft Excel) loader for arbitrarily-sized / big-size files

seed7 - Source code of Seed7

portacle - A portable common lisp development environment

qlot - A project-local library installer for Common Lisp

Co-dfns - High-performance, Reliable, and Parallel APL

cloc - cloc counts blank lines, comment lines, and physical lines of source code in many programming languages.