[1313ed01]

There is also fennel, earlier language originally by same developer, that is similar, but compiles to, and is fully implemented in, Lua. No standard library of its own so missing many nice things like the parser library from janet, but it is good for writing scripts for things that embed Lua.

https://fennel-lang.org/

[ux266478]

Fennel really is great, and a great way to get into the clojure family. My biggest gripe with it is that debugging is the typical transpilation bed of needles. The bridge between Fennel and the Lua VM is super fragile, and it just doesn't have half the quality of the Janet debugger and REPL. It's a real shame, because Fennel is way more portable, and thanks to LuaJIT is capable of breaking SBCL's jaw, which is absolutely fucking insane. But the transpilation experience just completely kneecaps it imo. There are workarounds you can do, but even if you mess around with implementing a debug.setinfo you still run into less-than-fun edge cases like with match-blocks.

I think there's a lot of value in forking LuaJIT2 and reworking the debugging and error structures within to make it more suitable for language transparency. Doing so would make languages like Fennel much more attractive.

[radiator]

Relevant issue #1457 VM instrumentation for third-party tools https://github.com/LuaJIT/LuaJIT/issues/1457 was opened by Mike Pall as recently as three weeks ago.

I gather that some features will be added to 2.1 but others only to 3.0.

[totalperspectiv]

I thought he stopped working on LuaJIT? Is it back in active development?

[radiator]

Well, looking at the commits, he has been regularly contributing for the last ten years at least. I don't know if he had stopped for a while.

[JHonaker]

> capable of breaking SBCL's jaw

What exactly do you mean by this? Speed? Portability? Ease of use?

[ux266478]

What I mean by that is that it's in the same weightclass of speed, depending on the problem being tackled. In the case where data's shape is mutable, SBCL will scream ahead thanks to CLOS. You can cheat LuaJIT with dynamically-defined C-structures via abuse of the FFI lib instead of native tables, but it's not as nice as CLOS nor is it very safe. In the case that the shape of data is changed extremely frequently? CLOS might actually end up falling behind here. Another area where SBCL will likely win out is when the hotpath is bottlenecked on string operations.

Where I'd say it advances into breaking SBCL's jaw is that the runtime, interpreter, jitter, etc. are all much smaller than SBCL's runtime and compiler. If you're looking for a complete system, I'd say SBCL wins out obviously. You're talking a world-class REPL, debugger, a high quality stdlib, etc. All it's missing is a text editor like LispWorks (emacs and pretty much every other FOSS Lisp editor I've seen is a massive downgrade.) With that in mind, SBCL is not something you embed in an application written in another language. The holy grail is getting something as fast as SBCL, as flexible as SBCL, but as a 50k loc self-contained runtime. LuaJIT is the reigning heavyweight champ there, so having a Lisp-adjacent language like Fennel running atop it is a pretty damn compelling idea.

Interestingly with regards to text editors, Lua doesn't have that problem technically. Lite-XL is dangerously close to being zmacs/LispWorks for Lua. Poetically, just like Lua it's fairly bare bones and requires extension to be a decent IDE. But the underlying structure is absolutely fantastic, being based around a fairly cohesive object model rather than coats of paint over text buffers.

[kscarlet]

Can you tell a bit more about what is missing from Emacs SLIME when compared to LispWorks?

[ux266478]

A small but illustrative example: given a live running clisp program, I can click on a UI element to inspect both the live object and the underlying code in the IDE. I can even copy and paste UI elements!

Emacs is text-centric, LispWorks is clisp-centric with a real GUI designed for computers with a keyboard and mouse. There's a whole MVC system! Wow!

GNU Emacs, Lem, etc. are all very nice editors, but they're stuck in the 1970s and are entirely keyboard-centric with very primitive UI flows. You can get used to it, but never fix it. If I wanted to use slime-fancy to inspect a class, what I get is a dead list of raw text that I have to awkwardly interact with. When I inspect a class in LispWorks, I get truly interactive UI elements which themselves map to rich Lisp objects.

Even editors like Lem that fix Emacs' performance issues (another genuine problem), they all make the same mistake of being centered around text-buffers and under-engineered UI frameworks. You can extend them ad infinitum, but if the roots are rotten...

Second Climacs exists, but it's more of a curiosity and a research project than a usable text editor IME (and is also currently tied to X, though that doesn't affect me personally). I hope that changes some day.

[lejalv]

I wish an ambitious approach such as Project Mage had taken off - https://project-mage.org/

It makes me sad that some-mthfka got some but perhaps not enough support and the effort stalled after a few months.

[kscarlet]

> A small but illustrative example: given a live running clisp program, I can click on a UI element to inspect both the live object and the underlying code in the IDE. I can even copy and paste UI elements!

I agree GUI is awkward in Emacs/SLIME. I think the reason is there isn't a standardized GUI framework across the Lisp world. Otherwise people can make SLIME support it.

> If I wanted to use slime-fancy to inspect a class, what I get is a dead list of raw text that I have to awkwardly interact with.

This part I do not agree. Nowadays "text" in Emacs/SLIME is far from "raw text", there's button that respond to hover, with right click context menu, and can be copy and pasted. I recall some small quirks (like objects in inspector are not presentations) but the only reason they aren't fixed (yet) is nobody get bothered enough. There's rarely any fundamental limitation. After all, it wouldn't be fare to call LispWorks UI "dead pixels".

BTW I once wrote yet another over ambitious project < https://github.com/neomacs-project/neomacs > but it doesn't go anywhere either. People do not care enough, Emacs is good enough.

[chamomeal]

Is fennel clojure-ish? I’m vaguely aware of it being a lisp, but I didn’t know it was clojure-ey. Pretty neat sounding!

[veqq]

All new Lisps since ~2010 have been Clojure-y-: https://p.hagelb.org/new-lisps.html (Lone Lisp and LispE are the only exceptions and LispE still has _some_ Clojure features.)