Live data from Hacker News

Modern, functional Common Lisp: myths and best practices

ambrevar.xyz

41–50 of 161 posts

Re: Modern, functional Common Lisp: myths and best practices

#41
post #3

I 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

More context:

SBCL supports TCO: see http://www.sbcl.org/manual/#index-Tail-recursion

One can drive whether SBCL optimizes tail calls by setting the proper optimization settings: see http://www.sbcl.org/manual/#Debugger-Policy-Control

Re: Modern, functional Common Lisp: myths and best practices

#42
post #5
post #4

I'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?

I recommend Fset, which other commetners have mentioned.

I wrote a wrapper for it and SERIES, called folio, followed by a revised version called folio2. If your requirements resemble mine when I wrote it, you might findit useful.

You can find it here:

  https://github.com/mikelevins/folio2/

Re: Modern, functional Common Lisp: myths and best practices

#43

Earlier quoted context omitted.

Are you aware of any memory-leak issues with fset? I once used it in a game where I updated an fset sequence in real-time. I let it run for a while, after coming back I noticed my computer was completely frozen (out of RAM).

It's inspired by Clojure after all. The language of choice for users that don't care about performance.

It probably isn't. The initial public release of Clojure was in the fall of 2007. Scott Burson has been working on FSet since at least 2004. He himself says it's inspired by Refine.

Re: Modern, functional Common Lisp: myths and best practices

#44
post #8

Very nice overview, I failed to see references to LispWorks and Allegro, though.

One little thing I did for Allegro was to compile their docs into a dash docset so you can use emacs' dash-docs with it.

- https://github.com/kidd/AllegroLisp.docset

- https://github.com/dash-docs-el/

Re: Modern, functional Common Lisp: myths and best practices

#45

Earlier quoted context omitted.

It's inspired by Clojure after all. The language of choice for users that don't care about performance.

It probably isn't. The initial public release of Clojure was in the fall of 2007. Scott Burson has been working on FSet since at least 2004. He himself says it's inspired by Refine.

I stand corrected. I still maintain my point about (idiomatic) Clojure being terribly slow though.

Re: Modern, functional Common Lisp: myths and best practices

#46

This doesn't scratch my itch at all. I love Lisp but boring old Python has the libraries I need. EDIT: Based on a comment and downvote I suppose I didn't make my point clear above. I am saying that myths are not the only thing holding Lisp back. (I may be wrong. I hope I'm wrong. Big thank-you to people who are linking ways to get libraries in Lisp, especially Python libraries.) I care 10x as much about libraries as…

These four things are common myths . It says so in the very line above them. This article is literally about debunking these myths.

Yeah, I read it. Can you explain how "red herrings" differ from "myths"? Is the distinction really that important?

My point was that it is not just myths (or red herrings either) that are holding Lisp back. There are some issues based in reality as well.

Re: Modern, functional Common Lisp: myths and best practices

#48

Thanks 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…

Can you elaborate why is it a better fit? Have you evaluated CAPI? Have you looked into building Cocoa applications with Clozure CL?

CAPI is great, very well designed and implemented.

The advantage of Swift and SwiftUI is that my application can run on both a MacBook and iPad, sync data with iCloud.

The advantage of LispWorks is that I could fairly easily support both Mac and Windows (and Linux).

I spent two evenings last week playing with Clozure CL and its Cocoa support. It has low level APIs and I had a peculiar issue with sometimes not being enter text into input components.

EDIT: to be clear, in general I love Clozure CL. In this instance I was probably shooting myself in the foot, somehow, or maybe the issue was that I blew the install in some way getting it running on Catalina which took over an hour. The Catalina problems are hopefully just short term issues.

Re: Modern, functional Common Lisp: myths and best practices

#49

This doesn't scratch my itch at all. I love Lisp but boring old Python has the libraries I need. EDIT: Based on a comment and downvote I suppose I didn't make my point clear above. I am saying that myths are not the only thing holding Lisp back. (I may be wrong. I hope I'm wrong. Big thank-you to people who are linking ways to get libraries in Lisp, especially Python libraries.) I care 10x as much about libraries as…

I'm always curious when this comes up: which libraries in particular do you have in mind? If you love Lisp and they're really absent, a short list would at least provide a data point for something that would be desirable and ambitious newcomers could cut their teeth on.

Anyway I don't think the library ecosystem is so dire... Lots of good libraries are distributed through quicklisp. It's pretty straightforward to wrap a C library. (You can even do C++ easily if you switch CL implementations to Clasp...) If you need Java libraries, you can switch CL implementations again and use ABCL. (But of course all your CL code and CL libraries still work.) Lastly, for Python there's https://github.com/pinterface/burgled-batteries (and https://github.com/snmsts/burgled-batteries3 for py3) that even in an incomplete state might suit your particular library needs.

Perhaps this capability isn't very compelling since Python can also access C without trouble (and Java via Jython, .NET via IronPython)? Well I guess all I have left to ask is whether you've considered there might be libraries (or features) in Lisp that would be needed that don't have equivalents in Python? What do you do then? One possible library for admittedly niche applications that came to mind was a hierarchical task planner (https://github.com/shop-planner/shop3) but I forgot someone did indeed make a Python library (https://github.com/oubiwann/pyhop) based on an older version (SHOP1) of the background work, so depending on if you need the v3 features it might suffice.

Re: Modern, functional Common Lisp: myths and best practices

#50
post #5

Earlier quoted context omitted.

Immutability is something I'm still exploring in Common Lisp. Any pointer, anyone?

I recommend Fset, which other commetners have mentioned. I wrote a wrapper for it and SERIES, called folio, followed by a revised version called folio2. If your requirements resemble mine when I wrote it, you might findit useful. You can find it here: https://github.com/mikelevins/folio2/

Thanks for sharing!
Post reply on HN