Very nice overview, I failed to see references to LispWorks and Allegro, though.
Which is a pity because at least for LispWorks, the IDE itself and the CAPI GUI toolkit could be considered killer apps.
Modern, functional Common Lisp: myths and best practices
11–20 of 161 posts
Re: Modern, functional Common Lisp: myths and best practices
#12I don't consider a language supportive of functional programming unless it supports tail-call optimisation, which is performed by some but not all implementations of Common Lisp. The article recommends SBCL, which does support TCO. An old (2011) survey of TCO support is at https://0branch.com/notes/tco-cl.html
That sounds more like an implementation detail, in most cases. By this metric Haskell wouldn't be a functional language.
Re: Modern, functional Common Lisp: myths and best practices
#13I've been doing some functional style programming in Common Lisp, and I was wondering what exactly should be considered functional programming. In particular, is object identity with EQ consistent with functional programming? Constructors do not act like functions if EQ is the equality. Or should that be more "immutable programming"? Common Lisp, because it has EQ and object identity, cannot perform some optimization…
Immutability is something I'm still exploring in Common Lisp. Any pointer, anyone?
It's a matter of not modifying things once constructed. CL has hooks to help do that, although a user can always get around them.
A package I've been involved with lately is fset, which is available through quicklisp, or at
https://github.com/slburson/fset
It has some interesting features, including "functional setf expansion". This would turn something like
(setf (fcar x) y)
into something equivalent to
(setf x (cons y (fcdr x)))
(where "fcar" and "fcdr" are the same as "car" and "cdr", except when they are in a setf-able place form.)
(fcar and fcdr are not in fset; I used those names just for exposition here.)
It could work with nested accessors, but only if it bottoms out in a variable.
Re: Modern, functional Common Lisp: myths and best practices
#14I've been doing some functional style programming in Common Lisp, and I was wondering what exactly should be considered functional programming. In particular, is object identity with EQ consistent with functional programming? Constructors do not act like functions if EQ is the equality. Or should that be more "immutable programming"? Common Lisp, because it has EQ and object identity, cannot perform some optimization…
Immutability is something I'm still exploring in Common Lisp. Any pointer, anyone?
https://common-lisp.net/project/fset/
By the way, I found a lot of your best practices questionable to say the least. Since it's obvious that you are a newcomer to CL, I would refrain from producing "best practices" type blog posts until I had a few years of experience under my belt.
For that reason, I also found your post confusing and I'm inclined to categorize it as "mostly rehashing stuff that is already there" rather than strong signal. There is ample, good, introductory material for CL on the net, we should strive to think before we dilute it with derivative posts.
Re: Modern, functional Common Lisp: myths and best practices
#15I've been doing some functional style programming in Common Lisp, and I was wondering what exactly should be considered functional programming. In particular, is object identity with EQ consistent with functional programming? Constructors do not act like functions if EQ is the equality. Or should that be more "immutable programming"? Common Lisp, because it has EQ and object identity, cannot perform some optimization…
I really enjoy Common Lisp being imperative enough to make iteration and collection orthogonal. You can freely mix-and-match functions for traversing data structures (dohash, maphash, etc) and ways to accumulate values (setf, push, ext:collect, etc.) I find that equivalent purely functional code often needs more functions to both traverse and collect at the same time e.g. fold, map, flatmap, etc.
I know that the functional universe has solutions to these problems, like the State monad and reusable collections protocols based on common minimal primitives, but I really appreciate being able to just freely string together tokens like DOLIST WHEN EXT:COLLECT without any elaborate frameworks.
So I suppose that programming in Common Lisp makes me appreciate non-functional programming.
Having said that, I do feel like a caveman every time I spend brain cycles on picking between EQ/EQL/EQUAL/EQUALP/STRING= or worrying about whether the object I'm updating might come from a quoted constant and invite undefined behaviour. Hard to have it all...
Re: Modern, functional Common Lisp: myths and best practices
#16Thanks for writing that up. Common Lisp as a language and ecosystem is so huge that we all have our own view of what CL is and how to use it to build applications. I have been actively using CL since around 1982 for prototyping and also building applications and tools but I feel like I use a small part of what is available, mostly because I prefer to use what I am used to. I should should probably spend a little less time building things with CL and a little more time studying it.
EDIT: off topic, sorry, but I have been actively evaluating CL (using an embedded web server that starts a browser) vs. Swift (using mostly SwiftUI) for a new product I want to write. I find myself using Swift like I would CL: using Playgrounds to prototype low level code and utilities, then XCode for developing the UI. To be honest, Swift and SwiftUI is a better fit technology-wise for what I want to do, but I am so much happier when working in CL.
Re: Modern, functional Common Lisp: myths and best practices
#17Common Lisp is also a pleasure to use for k8s-hosted services. Just deploy your Lisp-based service to k8s, forward the sly/slime port to your local system, and continue to work on it interactively with emacs and sly/slime. It's really the most interactive development approach for k8s-hosted services. See https://github.com/container-lisp/s2i-lisp
How do you do the forwarding? (That’s an interesting question to me by itself, but I ask because it seems like that feature is just as good outside of k8s too :))
Re: Modern, functional Common Lisp: myths and best practices
#18Very nice overview, I failed to see references to LispWorks and Allegro, though.
I've never used them myself, so in all honesty I have nothing to say about them! :p
That said, I support free software and I believe a proprietary compiler is not a good idea :(
Re: Modern, functional Common Lisp: myths and best practices
#19I've been doing some functional style programming in Common Lisp, and I was wondering what exactly should be considered functional programming. In particular, is object identity with EQ consistent with functional programming? Constructors do not act like functions if EQ is the equality. Or should that be more "immutable programming"? Common Lisp, because it has EQ and object identity, cannot perform some optimization…
Immutability is something I'm still exploring in Common Lisp. Any pointer, anyone?
What I do: Write pure functions, but don't shy away from mutating lexically scoped state in order to improve performance. For global stuff, wrap it with classes since objects are a commonly understood way to reason about state.
Re: Modern, functional Common Lisp: myths and best practices
#20Common Lisp is also a pleasure to use for k8s-hosted services. Just deploy your Lisp-based service to k8s, forward the sly/slime port to your local system, and continue to work on it interactively with emacs and sly/slime. It's really the most interactive development approach for k8s-hosted services. See https://github.com/container-lisp/s2i-lisp
How do you do the forwarding? (That’s an interesting question to me by itself, but I ask because it seems like that feature is just as good outside of k8s too :))
With k8s, you just create a service of type NodePort and it assigns a free external port for that service, which is mapped back to a specific port in the Lisp container.