-> CL, with batteries out of the box: http, json, csv, DB, functional data structures, regexp, pattern matching, missing docstrings, missing functions, easy script runner…
> Epsilon is a Lisp programming environment built using SBCL that provides functional data structures and some encoding, cryptographic hashing and network programming capabilities.
Recently added in Lem: tree-sitter for JSON, YAML, Nix, Markdown, WAT; new language modes: Clojure, Perl, Kotlin, Zig (with LSP); git-gutter mode.
Lem has a (quite simple still) Git/hg/fossil interactive mode (interactive rebase is there but no reword for instance) and org-mode support is coming (https://github.com/mahmoodsh36/organ-mode).
Lem now is ncurses + webview (+ the non-longer maintained SDL2 backend) and it has daily multi-platform binaries. Try it out!
I tried the latest nightly release AppImage on Fedora 43 and got a nice undefined symbol error:
/usr/lib64/gio/modules/libdconfsettings.so: undefined symbol: g_assertion_message_cmpint
Failed to load module: /usr/lib64/gio/modules/libdconfsettings.so
/usr/lib64/gvfs/libgvfscommon.so: undefined symbol: g_task_set_static_name
Failed to load module: /usr/lib64/gio/modules/libgvfsdbus.so
So I tried out the container version with podman and that worked. I am familiar with Emacs, so some things were natural to me. I like Lem quite a bit. But to really drive with it, I need:
- Solid LSP support
- Project scoped buffer switching/searching
- Great vim keybinding support (this seems to have improved since last I tried lem years ago)
- Tree-sitter support for the languages I care about.
According to the website, LSP support is still a WIP. I didn't want to go through the hassle of testing it out in the docker container. From what I can tell, there is no project scoping for buffers, but I might be wrong.
All in all, a big improvement from a few years ago when I last tried it!
Hello, yes there's project scoping: https://lem-project.github.io/usage/usage/#project-commands (added by yours truly, which was easy thanks to Lem's quality code base). I find the vim layer excellent, you can open an issue if you find obvious things missing.
Stas is a machine. Almost every single day he's in the sources making improvements. I joined the sbcl-commit list recently and the project is far more active and cared for than I had originally suspected.
- icl doesn't have an interactive debugger, you ask for the backtrace with ,bt. cl-repl has one (less feature complete than Slime). I actually like the lack of a debugger for newcomers.
- icl: does auto-indentation right
- cl-repl: has an %edit command to launch an editor and load the file content on close.
- icl: better, prettier autocompletion with a drop-down. cl-repl is based on readline.
- icl: based on Slime's backend, so you can connect to another running image.
- cl-repl: has a ! shortcut to execute a shell command.
Thanks, vinderal. Since you wrote this the other day, I've improved the auto-completion so it is more context-aware. For instance, it will auto-complete using your filesystem when it is reasonably sure that you are trying to reference a filename. There's also a new interactive object inspector TUI, and a super-experimental `,explain` command. `,explain` will fire up gemini/claude cli to have it explain the last command/result/error. It provides temporary access to an icl mcp service so the AI can use tools for read-only access to your running lisp image.
I'm not sure I'd say this is "the other way around"; Coalton strives to implement Haskell or ML-adjacent semantics (in the type system, for example) with Lisp syntax. "With" here meaning that it is both implemented in and written with Lisp syntax.
Edit: I think I see what you mean now. Lisp backend vs Haskell backend.
Anyway, Coalton is a joy to use and IMO a breath of fresh air in CL. It's quite easy start using as a library; go all-in or only use it in specific parts of the code. It's great to be able to choose between (or intermix)the flexibility of CL and the guarantees of a statically typed language (as well as some nice performance boosts with arguably less work). Some aspects are still young (some of the standard library, ecosystem, editor support), but it's quite thoughtfully crafted and I'm excited to see where it goes.
>Coalton strives to implement Haskell or ML-adjacent semantics (in the type system, for example) with Lisp syntax. "With" here meaning that it is both implemented in and written with Lisp syntax.
Not exactly. Coalton brings ML-style strong typing to Common Lisp. But Coalton code is also Lisp code.
The backend, thus, is Common Lisp, and it is available at all times, thus leveraging all its power.
Pretty good, except and I don't share the advice to use package-inferred-systems, like, at all. It hides the third-party libraries you rely on, it prevents you from using one package in multiple files (a flexibility not common out there), you can't see the project's structure at first glance… just use a simple .asd file declaration, you'll be fine.
YMMV, of course. I switched to it half a year or so ago, when doing a close read of the ASDF docs, and for my purposes it works well. But I may be odd: I have a monorepo of Lisp code which I don't intend to distribute in the sense of turning them into Open Source packages. There's an `l` subdirectory for libraries, a `p` subdirectory for "projects", and if I need something I can just import `ca.berksoft.l/math/fft` and be done. I think that having a file-per-package is not a limitation, it makes packages probably a bit more like modules in my daytime language (Elixir/Erlang), and it does save a lot of typing telling ASDF what to find where.
It's interesting to know your use case, thanks. I don't like dealing with package-inferred-systems when exploring, reading or using other people's libraries.
You can pin dependencies with Qlot or Ocicl (or vendor them with vend), but it might be a long time before you actually need this (the ecosystem is pretty darn stable).
Arc was re-written to Common Lisp (SBCL) around last year, for performance reasons.
> [Clarc] is much faster and also will easily let HN run on multiple cores. It’s been in the works for years, mainly because I rarely find time to work on it, but it’s all pretty close to done.
> there’s now an Arc-to-JS called Lilt, and an Arc-to-Common Lisp called Clarc. […]
> open-sourcing the Arc implementation (i.e. Clarc) would be much easier [than the HN site]. [Because…]
I suggest to have a look at CIEL: https://github.com/ciel-lang/CIEL/
-> CL, with batteries out of the box: http, json, csv, DB, functional data structures, regexp, pattern matching, missing docstrings, missing functions, easy script runner…
and to Epsilon: https://github.com/jbouwman/epsilon/
> Epsilon is a Lisp programming environment built using SBCL that provides functional data structures and some encoding, cryptographic hashing and network programming capabilities.