Just wanted to share some (exciting) news about my Common Lisp project, euler-cl. I finally got the time to sit down and integrate it with Codecov! This means a couple of cool things:

• 📈 Test Coverage Tracking: I can now see how well my code is tested over time, giving valuable insights into code quality.
• 🏅 Codecov Badge: euler-cl now sports a snazzy Codecov badge to show off!
• 📦 Reusable Setup: The code and setup process should be simple enough to be used as a reference to integrate Codecov (and potentially other services) into your own Common Lisp projects!

If you're interested this commit is almost all you need: https://github.com/bahmanm/euler-cl/commit/855b014

Let me know in the comments if you have any questions or want to chat about integrating Codecov into your own projects!

Hello! This is another Friday Social topic. Hoping that this will be more insightful than the previous ones and we will learn something useful from this.

What useful open source projects are written in Common Lisp? To keep it interesting, try and avoid posting links to your own projects because that could turn into a thread of self-promoters. Instead share open source projects developed by others that you have come across. Here goes the questions:

1. Name one project (that is not already mentioned by others in this thread) that is written in Common Lisp.

2. Which OSI-approved license is the project released under?

3. Are you the author of this project? (I recommend that the answer to this be "No").

4. Who is/are the author(s) or team(s) behind this project?

5. Why is this project useful?

6. What in your opinion is the best thing about this project?

7. If you could recommend only one improvement that should be made in this project, what would it be?

Restricting this topic to "Common Lisp" so that we do not end up with a large list of Emacs packages. We will do similar thread for other Lisps in future. The project must be open source.

Friday Social is back! So we know we are all Lisp programmers here and we love the language and use it.

But I am sure some of us work with other languages too. Like I have to work with C, C++, Python and a number of other languages to work on different projects. I am sure some of you do too.

So the questions for this Friday Social are:

1. What Lisp programming languages do you use?
2. What non-Lisp programming languages do you use?
3. What is your favorite Lisp programming language? Why?
4. What is your favorite non-Lisp programming language? Why?
5. What is that one thing about your favorite non-Lisp language that you wish to see in your favorite Lisp language?

Happy Friday!

Hello!

I've been obsessing about the lisp language recently. I've been in the periphery with learning about Haskell and functional programming. I have actually kind of avoided learning lisp because of its "ugly" syntax at face-value, despite being raised by Emacs as my first (true) editor. I woke up one day and decided enough was enough, i'm gonna learn lisp and gain a deeper understanding of Emacs and also programming. And dear god was it so worth it.

Just today I coded this function for Eratosthenes' sieve, and I had so much fun coding it! I like to go through Project Euler's archived problems when starting off with a new language because it really forces me to interact with the code rather than passively reading a programming book (I'm reading Land of Lisp, it's so unhinged I love it)

(defun range (start end)
  (if (< start end)
      (cons start (range (1+ start) end))))

;; Checks if d is a factor of n
(defun factorofp (d n)
  (zerop (rem n d)))

;; Sieve in lisp??
(defun sieve (n)
  (let ((primes (range 2 n))
        (curprime 2))
    (maplist (lambda (tail)
               (delete-if (lambda (n)
                            (factorofp curprime n))
                          (cdr tail))
               (setf curprime (cadr tail)))
             primes)
    primes))


CL-USER> (sieve 1000)
(2 3 5 7 11 13 17 19 23 29 31 37 41 43 47 53 59 61 67 71 73 79 83 89 97 101 103
 107 109 113 127 131 137 139 149 151 157 163 167 173 179 181 191 193 197 199
 211 223 227 229 233 239 241 251 257 263 269 271 277 281 283 293 307 311 313
 317 331 337 347 349 353 359 367 373 379 383 389 397 401 409 419 421 431 433
 439 443 449 457 461 463 467 479 487 491 499 503 509 521 523 541 547 557 563
 569 571 577 587 593 599 601 607 613 617 619 631 641 643 647 653 659 661 673
 677 683 691 701 709 719 727 733 739 743 751 757 761 769 773 787 797 809 811
 821 823 827 829 839 853 857 859 863 877 881 883 887 907 911 919 929 937 941
 947 953 967 971 977 983 991 997)

I love lisp because it is at its core a functional programming language, but (as i do in my sieve function with the outermost lambda) i can specify localized points where I define, use, and mutate state. It gives me the best of both worlds, functional and imperative.

Lisp has made me kinda like coding again. Every function feels like writing poetry, especially with the indentations. People say our parentheses are ugly but they're wrong and they're the ugly ones.

New web scraping framework from Alexander Artemenko/svetlyak40wt. Meant to be a CL alternative to Scrapy. Considering we have the great lquery and plump libraries in Common Lisp, building up to a fully featured alternative shouldn't be all that surprising.

How did they implement allocate a new cons cell?

Mito docs are pretty scarce, here's a helpful tutorial for getting a nice cruddy CRUD going.

"We create a search form, display products with ready-to-use HTML templates, organize our Djula templates with inheritance. Common pitfalls. That's the basics every web developer should know!"

https://www.youtube.com/watch?v=EFRVHmOCE7Q

By Vindarel, of CL cookbook fame.

There are many things to like about Common Lisp packages. In everyday programming, I really like being able to define one or more packages in one file then just have a (in-package package-name) at the top of other files opposed to having sometimes hundreds of lines of imports. Some programming languages are worse than others, but no other programming language that I know of allows one to keep imports in a totally different file.

The real point of this post is to talk about a specific scenario that reveals in interesting interaction between asdf systems (libraries), symbols, and macros. A conversation about packages almost always involves talking about symbols. Here is the situation: there is a library, A, that implements some very useful computations. The public interface for the library is a combination of macros and functions. It is rather verbose though, so you want to wrap it in a macro and create a new library: B. You want the users of your library to only have to use your library and not have to worry about depending directly on library A, so you want to re-export some of the symbols from library A so the users of your library can just use those symbols exported from your library.

If you don't see a problem with this then congratulations: you are sane. This relies on just a couple features:

• feature of asdf: orthogonal to packages meaning that one can use a symbol from any package without having to explicitly load the system. If a package is loaded, it's symbols can be used.

• feature of packages: symbols in a package can be referred to by their full name (package-name:symbol-name) anywhere in anyone's program. It does not matter if they have the symbol imported into their package. It does not matter if they have a package local nickname. It does not matter that they have a different symbol interned with the same symbol-name.

• macros do not have any feature of their own that make this possible, but because of the previously mentioned features, using a symbol from another library in a macro expansion works just fine. As an added benefit, you cannot expand to symbol from a package that is not exported or from a non-existent package because the reader (which happens before macro expansion, even before macro definition) makes sure all the symbols are accounted for.

I witnessed someone in almost this exact situation. They were using Rust. The problem happened when someone tried to use the macro from library A that had been re-exported from library B. The macro expanded to use some symbols that were qualified assuming that the user had already imported them from library A. However, the user imported from library B. The work around ended up being to not re-export and just tell the user via documentation that they have to explicitly depend on library A, and use their macro.

That is the story. Let me know what you think, and tell me about a time that you were grateful for the way Common Lisp handles packages and symbols.

This is another Friday social topic. You are aimlessly wandering around a beautiful hilltop by a sea when an angel approaches you from the opposite direction. She is no ordinary angel. She is a Lisp angel! She will grant one Lisp wish to you. Before she can fulfill your wish, she needs this information from you:

1. Your favorite Lisp dialect.
2. Your favorite non-Lisp programming language.
3. Your favorite standard library function/macro/feature from your favorite Lisp dialect that you want to see in your favorite non-Lisp programming language.

Once you tell these 3 things to the angel, she will magically add your chosen feature to your chosen non-Lisp programming language.

What are your answers going to be?

The advantages of using Common Lisp are numerous:

1. The shape of tensors is not limited to numbers, but can also include symbols and even S-expressions!
2. Automatic Generation of Iterators, ShapeError, etc.
3. Works as a Domain Specific Language for Deep Learning embedded in Common Lisp

Added a couple desktop backgrounds to the revisited #commonlisp logo in https://gitlab.com/santiagopim/common-lisp-logo

Happy hacking !!

Another bit of gold from ICFP 2023 by Pjotr Prins of the University of Tennessee.

The actual title of the talk is "Why code in Python+C if you can code in Lisp+Zig?" but the "Lisp" in this case is actually Guile Scheme. I didn't know this, but Zig uses the C ABI so it binds to any language that can do FFI bindings to C, including most Scheme and Common Lisp implementations. But why don't I just post the abstract here:

"Most bioinformatics software today is written in Python and for performance C is used. Lisp has been around for over half a century and here I don’t have to tell how or why programming Lisp is great. I will talk about Zig as a minimalistic new language that is unapologetically focused on performance, tellingly with a blazingly fast compiler. It is advertised as a replacement for Thompson, Ritchie, and Kernighan’s C, but it may even replace C++ in places. Zig uses the C-ABI and does not do garbage collection, so it is ideal for binding against other languages. In this talk I will present combining GNU Guile Lisp with Zig. I’ll argue that everyone needs two languages: one for quick coding and one for performance. With Guile and Zig you get both at the same time and you won’t have to fight the Rust borrow checker either."

Note: this was originally a comment I wrote on Lemmy in answer to the question “what type of problems do you solve using Lisp?”. The post got to be a bit too long, and I am re-publishing it here as a proper blog post. I am also including some of a post I wrote on Mastodon which touched on some of these same issues.

So to answer the question: I have known about Common Lisp and Scheme for years, but only recently started using them. This is the story of the 3 Lisp dialects that I use.

Emacs Lisp

I use Emacs and Emacs Lisp to manage my tens of thousands of text files, I write Emacs Lisp scripts to automate simple tasks like searching for pieces of information, formatting it, and outputting it to a report that I might publish on my blog or send in an e-mail. I also use Emacs to help with data cleaning before running machine learning processes. Emacs helps with navigating CSV and JSON files, it also is a really good batch file renamer.

Scheme

I have recently started using Guile Scheme to do some personal projects. I went with Guile over the myriad other Scheme dialects because it is the implementation used for the Guix package manager and operating system.

• Also, there the Goblins, which is a distributed object-capability programming system is officially supported on the Guile platform, and I have been really wanting to write applications using this programming style ever since I first learned about it.

• Also, there is the G-Golf foreign interface layer allows Guile to automatically use an C library that implements the GObject Introspection interface. So through Guile, like with Python, you can use any C code library used to create of all native apps in the Gnome, MATE, Cinnamon, or (my personal favorite) the Xfce desktop environments. This potentially makes Guile a viable alternative to Python scripting across all of those Linux desktop environments.

Of all the Lisp dialects, Scheme is my favorite, for a few reasons:

• It is absolutely tiny. Guile is relatively large (not as big as Common Lisp), but other implementations are unbelievably small. for example the Chez Scheme “petite” interpreter is fully compliant with the R5RS standard, and the executable is like 308 kilobytes on a 64-bit Linux computer system.

• Hygienic macros with syntax-case

• Recursive functions over using the loop macro of Common Lisp. When writing algorithms, I personally find it easier to reason about recursive functions than loops. Scheme also provides me the ease-of-mind that comes with knowing the optimizing Scheme compiler will ensure recursive loops will never overflow the stack.

• Pattern matching is well supported by most Scheme implementation.

• It is a "Lisp-1" system, meaning there is only one namespaces for variables and functions, as opposed to Common Lisp (a "Lisp-2 system") which allows a name to be either a variable, a function, or both. I personally find it easier to reason about higher-order functions in Lisp-1 systems.

• Support for Delimited Continuations, which is a fairly recent discovery of computer language theory (first being discussed back in the 1990s), but is available across a few Scheme implementations.

Common Lisp

That said, I am also starting experimenting with Embedded Common Lisp (ECL) because it is a lightweight standards compliant Common Lisp implementation that compile your program into C++ code, and this is useful to my professional work.

The modern software industry, especially in the realm of big data and machine learning, has mostly settled on a pattern of using C++ for creating performance critical libraries, and creating Python binding to the C++ libraries for scripting. I was hoping languages like Haskell and/or Rust might come along and change all this, but it will take decades (if ever) for the software industry to turn in that direction.

The problem with Python, in my experience (and I believe many other software engineers would agree) is that it does not scale well to larger applications at all, whereas Common Lisp does. This is for various reasons, but mostly due to how Lisp does strong dynamic typing, and also the CLOS implementation of the meta-object protocol. Yet too many companies waste time writing large applications in Python — applications that are much larger than the scripting use cases that Python was originally intended to be used. I believe this is time and money better spent on other things.

So I see Common Lisp, and the ECL compiler, as a potentially viable alternative to the sub-optimal status quo of Python as a scripting layer around C++ code libraries, at least perhaps for my day job, if not being more generally true industry-wide. Mostly, ECL would allow me to write a program in Common Lisp instead of Python, but deliver to my clients the C++ code that ECL generates to be used in their machine learning projects. (I have not actually done this yet, I am still investigating whether this would be a viable solution to any of my projects).

ECL makes it easy to use C++ libraries through Lisp instead of Python. And there are so many good C++ libraries out there: Qt, OpenCV, Tensorflow, PyTorch, OpenSceneGraph, FreeCAD, Godot game engine, Blender. And it compiles easily on Linux/Unix (GCC), Windows (MSVC), and MacOS (via Clang++), so good for cross-platform development.

Conclusions

So in spite of Lisp being such an old family of languages (its earliest incarnations dating all the way back to 1958), and being superseded in popularity and widespread use by languages like Python and JavaScript across the software industry, Lisp is still a modern, relevant, evolving, and very useful family of programming languages. At the same time, a Lisp such as Scheme or Common Lisp would even be a better choice of programming language in many applications where Python is currently used.

I just hope I eventually find the time to try out all of these Common Lisp and Scheme related ideas I have. I especially hope ECL turns out to be a profitable technological choice for the professional work that I do. But only time will tell.

Please feel free to comment here, or on Mastodon