Modern, functional Common Lisp: myths and best practices
1–10 of 161 posts
Re: Modern, functional Common Lisp: myths and best practices
#2Common 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
Re: Modern, functional Common Lisp: myths and best practices
#3I 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
Re: Modern, functional Common Lisp: myths and best practices
#4I'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 optimizations that a truly functional language's implementation could. In particular, it cannot combine equivalent function calls, and cannot merge equivalent data (hash consing or the equivalent.)
Re: Modern, functional Common Lisp: myths and best practices
#5I'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?
Re: Modern, functional Common Lisp: myths and best practices
#6Amusing set of quotes about CL by famous lispers:
Re: Modern, functional Common Lisp: myths and best practices
#7I 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
Indeed, tail-call optimization is not part of the standard, unlike Scheme.
The point of the article is that while the Common Lisp standard is not really focused on functional programming, nothing prevents the implementions (and libraries) of today to be so.
Re: Modern, functional Common Lisp: myths and best practices
#8Very nice overview, I failed to see references to LispWorks and Allegro, though.
Re: Modern, functional Common Lisp: myths and best practices
#9I 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
All the CL implementations that matter support TCO.
Re: Modern, functional Common Lisp: myths and best practices
#10Amusing set of quotes about CL by famous lispers: http://xahlee.info/comp/Common_Lisp_quotations.html
A fun read with some good points, although many of them are a bit dated :p