CIEL Is an Extended Lisp

Clojure syntax implemented in Go.

I'm not affiliated I just think it's brilliant.

CEIL's example in Joker:

  (prn {:a 1 :b 2 :c 3})

Executing script took 2.1s overall. Execution of example took 0.007s.

The CL sodlib is a bit overloaded already, but if you wanna go batteries included, it was definitely missing stuff like Alexandria and Bordeaux etc, so I dig this choice. Brings a sense of "best practices" or standardization to the slightly fractured CL ecosystem.

I personally have an image with Alexandria, Serapeum, Dexador, Bordeaux Threads, some JSON stuff, but it might be handy to have something others use as a similar target.

Probably stands a better chance of success than the over-pontificated CDR proposals, and CL21 which preceded it.

Curious if there’s a bunch of reader macros set up by default?

(I assume you just use standard CL methods?)

> [CIEL custom REPL ] has a shell pass-through: try !ls (available in the ciel-user package)

That's a kickass feature.

I found a snippet somewhere that messes with string interning and so symbols don't instantly get capitalized, but there's still way too much shouting.

There should also be a large disclaimer saying "Consider disregarding portability in favour of SBCL to get a more modern experience".

I wrote Lisp (Clojure) professionally for several years. It was the most fun I ever had.

My only problem was it was an ongoing battle to convince people - especially management - that I wasn't crazy.

Sure, I was crazy-productive, but they also thought that there was some nutjob in the corner that was quietly adding risk to the business.

If someone could give me the ergonomics of Clojure, but without the JVM and the ability to easily target 1/ native (incl easy bidirectional C iterop), 2/ wasm, and 3/ support both in aot and runtime + JIT modes, I would switch in a heartbeat.

Is that too much to ask?

Common Lisp is still Common Lisp.

And I know it's a slippery slope.

Someone posted (here?) a list of the language changes to Java over the years.

And for something like Java, you "have" to "change the language" to get the results they wanted. Much of these changes could not have been done with just more classes in the JRE distributions. Whereas with CL, most of those things could have been done natively with just macros and functions, rather than having to update the core.

Of course, this is the Scheme story from day one, just with a much smaller core. But CL, due to the happenstance of the time of uniting several commercial efforts under one banner, has a larger core, but also, by definition, more opportunity for the actual compiler to be "better" with the higher level constructs it works with.

Contrived example being that Lisp "knows" about Structs and CLOS, whereas while you can add Structs (records) to Scheme, at a Scheme level you can only reduce them to the given Scheme primitives (vectors or lists), when the compiler finally sees the result, all it will see is a vector or list, with no knowledge of it actually being a struct (and thus can't potentially optimized for it).

If you want "native" structs, you need to actually extend the particular Scheme compiler.

So, anyway, the point being this is a nice package of libraries (it is, really, quite nice), all bundled into a single image. Batteries included.

But it's still CL at its core, there's nothing necessarily new there.