[HN Gopher] CIEL Is an Extended Lisp
___________________________________________________________________
CIEL Is an Extended Lisp
Author : todsacerdoti
Score : 259 points
Date : 2024-08-30 15:04 UTC (7 hours ago)
(HTM) web link (ciel-lang.org)
(TXT) w3m dump (ciel-lang.org)
| draven wrote:
| Looks like SBCL plus libraries. The author, vindarel, is here on
| HN.
| vindarel wrote:
| Hi o/ Hopefully the goal of CIEL is well explained. I use it
| daily (with the core image, in my editor), I ship products with
| it. It saves me a load of time, when I start a new project,
| when I need to interact with the outside world, when I want to
| write a little something and ship it on the server without
| Python's mess, etc. Speaking of which, Django is of course
| difficult to replace, but I started an automatic DB dashboard
| for CRUD operations, something's on the way (unreleased).
|
| I integrated CL step by step for my clients' work, and CIEL is
| another means to this end. To use CL, for real. None of my
| projects _need_ CL 's superpowers, but _I_ want them for
| development, deployment and monitoring!
|
| ---
|
| Today I fixed a few issues and released a v0.2:
| https://github.com/ciel-lang/CIEL/releases/tag/v02 The key
| point is that CIEL should be much easier to install, specially
| on Mac. We now rely on many less system dependencies.
|
| If you find out that CIEL is still difficult to install on your
| platform, don't hesitate to send details on an issue. Thanks in
| advance.
|
| ---
|
| TLDR; May CIEL ease and soften your CL journey.
|
| ps: you have no idea how much time it took me to discover
| certain things! Now you have them here, ready, packaged :-]
| qup wrote:
| Can you easily compile a binary?
|
| (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.
| amelius wrote:
| What's wrong with Ctrl+Z?
| hnlmorg wrote:
| You cannot use lisp expressions and functions as arguments in
| bash.
| jxy wrote:
| so it wouldn't require a shell that supports job control?
| kstrauser wrote:
| That's a pretty low bar. What's the Venn diagram of
| (systems which can run this) & (systems with only terrible
| shells)?
| zipy124 wrote:
| Forgive me if I'm wrong but I thought that was a fairly
| standard thing? The Ipython kernel uses exactly the same
| format, or you can go for a full shell and use xonsh.
|
| Or is python the odd one out in its REPL implementations here?
| I'm only familiar with python and e-lisp for REPL's.
| qup wrote:
| > CIEL's REPL is more user friendly than the default SBCL
| one. In particular:
|
| > ...
|
| > * it has a shell pass-through: try !ls (available in the
| ciel-user package)
|
| It was specifically mentioned as a reason why CIEL is better.
| But I don't use enough languages to know overall, sorry.
| vindarel wrote:
| You are right but let's put things in order: CL's REPL is
| outstandingly more interactive than Python's. Specially with
| Emacs & Slime (or the others coming close: Pulsar with SLIMA,
| vim, VSCode, Intellij, Sublime...) We have an interactive
| debugger, restarts, we can resume a failed computation from
| anywhere in the stack, we don't loose state, the Lisp program
| actually never restarts, we compile a function against a live
| image and get immediate feedback... (it's an internal and
| difficult explanation on forums)
|
| However, neither the built-in SBCL terminal REPL nor Slime
| offer a shell pass-through or ipython-like commands. We add
| one (by using the Clesh library).
|
| The doc doesn't mention it yet, we can enable the shell
| passthrough in Slime's REPL (or any other editor):
| CIEL-USER> (enable-shell-passthrough)
| vindarel wrote:
| It is very handy.
|
| Users who want an advanced lisp shell for the terminal, where
| they can mix & match shell and lisp code, would turn to lish:
| https://github.com/nibbula/lish/ (not considered "ready" or
| "good enough" by the author, but well advanced).
|
| also https://github.com/bradleyjensen/shcl, a POSIX shell.
|
| As always: see more on https://github.com/CodyReichert/awesome-
| cl#shells-shells-int...
| vindarel wrote:
| > Can you easily compile a binary? (I assume you just use
| standard CL methods?)
|
| ATM you use standard methods, by using CIEL as a library.
|
| I'd like to add a `ciel build` command.
| Y_Y wrote:
| I'd love to see one of these revitalizations of CL that gets rid
| of the ALLCAPS. I know it's a small aesthetic thing but it drives
| me crazy.
|
| 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.
| aeneasmackenzie wrote:
| You're looking for (setq *print-case* :downcase), no need to
| mess with the reader.
| perihelions wrote:
| (You can put this in ~/.sbclrc or your implementation's
| equivalent dot file!)
|
| (Tangentially: I've encountered Common Lisp libraries in that
| wild that actually break if you do this, highly surprising
| bugs where the author was doing something too-clever with
| symbols and compared their representation against hard-coded
| strings, such that changing your *IDE's default print case*
| had the effect of breaking a very low-level library. This
| isn't important to anyone else here; I just wanted to vent. I
| have so much programming pain that only I know about and no
| one else in the world shares).
| anothername12 wrote:
| This is great.
|
| 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?
| aidenn0 wrote:
| I did a quick search of the code, and only clesh[1] seems to be
| enabled by default for shelling out from the REPL.
|
| 1: https://github.com/Neronus/Clesh
| vindarel wrote:
| It's enabled by default for the terminal repl, but not in the
| ciel-user package, that we would use on our editor's REPL. In
| that case we can enable it with CIEL-USER>
| (enable-shell-passthrough #<NAMED-READTABLE
| CLESH:SYNTAX {1003EE7F13}> CIEL-USER> ! ls
| vindarel wrote:
| Only one is enabled in the terminal repl, but none when we use
| ciel as a regular Lisp library. We don't want to mess with the
| readtables by default.
|
| (see below to enable the shell passthrough in your editor's
| REPL)
| Blackthorn wrote:
| Having a standard set of _well documented_ things ready to go as
| if they were part of the core language, all with a single snazzy
| name, is soo important. I love this; Maybe it can become the new
| standard target. All it needs now is a good mascot or logo.
| notfed wrote:
| Where is this documentation? Honestly I don't see much here.
| I'd call this a readme, not documentation.
| Blackthorn wrote:
| It's linked on the GitHub front page, for some reason it's
| not in this link at all.
| vindarel wrote:
| How so?? You should have a sidebar with menu entries. Try on
| http://ciel-lang.org/#/libraries
|
| oh, the sidebar disappears quickly when we scroll and it
| disappears when we click on "show me"... not great.
| Blackthorn wrote:
| I was on mobile when I looked and I never saw the sidebar.
| Might be something that needs fixing. Love the project
| regardless.
| notfed wrote:
| Follow-up: apparently there is a sidebar. In my defense, on
| mobile, the sidebar is closed by default, and you have to
| click the tiny hamburger menu in the very bottom left of the
| screen. I did not see this.
| vindarel wrote:
| thank you (both) for the feedback. I added links to the
| documentation at the end of the landing page.
| a012 wrote:
| It looks fun to learn it for scripting. I often use Python to
| manipulate JSON and YAML and with Python requests library, this
| seems like a fit
| aidenn0 wrote:
| CL is better than Python for very short scripts that will be
| called repeatedly (e.g. from a makefile), since a python
| already has a slower startup time than a CL binary, and for
| every import you add it gets even slower.
| beders wrote:
| Nice to see that the approach taken by Babashka
| (https://babashka.org/) is now also available in the CommonLisp
| world. Good stuff!
| rootnod3 wrote:
| Watching it on Safari gives me the same Javascript warning. No
| extensions loaded. Otherwise, checked with chrome, that looks
| like exactly what I wanna use.
|
| 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.
| mgdev wrote:
| Ahh, the siren song of Lisp
|
| 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?
| masijo wrote:
| >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.
|
| Might want to look at Jank (https://jank-lang.org/,
| https://github.com/jank-lang/jank). It's still in it's early
| stages but it's basically all you're hoping for!
| mgdev wrote:
| Will check it out!
| rootnod3 wrote:
| The name might be hard to push to management, but I love that
| it is s-expr based.
|
| I'll definitely check it out, but if you don't mind me
| asking: how good is the REPL side on Jank? If it is remotely
| close to SBCL, then I might become a fan.
| Jeaye wrote:
| jank will have full nREPL support, so the REPL story should
| be at parity with Clojure. I'm working on the nREPL server
| now We're JIT compiling C++ code, so there are indeed more
| dragons.
| netbioserror wrote:
| Nim.
|
| Not joking. I use it at work. Former Clojure crazy. All the
| referential transparency/immutable data you could want from a
| non-Clojure language.
|
| Super easy bidirectional C interop.
|
| Native compiled but does have a compile-time script engine. Is
| the absolute most powerful compile-time evaluation I've seen
| outside of Lisp.
|
| Creator calls it a "quirky Lisp".
| mgdev wrote:
| I'll check it out, thanks!
| aeontech wrote:
| Just curious, what kind of companies do you find that are
| open to using Nim professionally? It's always hard with more
| niche languages.
| netbioserror wrote:
| Smaller ones where you're the sole dev on a given
| component, there are no cross-language dependencies in your
| systems (it's a CLI-invoked tool and/or communicates
| through stdout or JSON data, etc.), and your boss has had
| such poor experiences with freelancers and Microsoft lock-
| in in the past that he's open to you choosing the best tool
| for the job within reason.
| pjmlp wrote:
| The JVM is exactly why Clojure is one of the most successful
| Lisp variants since the AI Winter.
| mgdev wrote:
| I agree! And I still love it because it's what allowed me to
| sneak a Lisp into not just _a_ Java shop, but _the_ Java
| shop: Oracle.
| sitkack wrote:
| What is wrong with the JVM? The JVM is utterly amazing and you
| know very well that you can target native, even with Clojure.
| mgdev wrote:
| I agree that the JVM is an amazing piece of technology.
|
| But the ecosystem that exists around the JVM also comes with
| both a bunch of awesome libraries, and a whole bunch of cruft
| and ceremony.
|
| If, like Clojure, you're trying to pull in compatibility with
| JVM libraries, then you pull all that in. So now if you want
| a little C in your Clojure, you have to go through JNA or
| something.
|
| I would like the _option_ of going native with a Clojure
| dialect, without passing through either JVM (Clojure) or JS
| (ClojureScript).
| pjmlp wrote:
| Now there is Panama, and then GraalVM as well.
|
| Plus OpenJ9, PTC, Aicas, Azul, and even the Java like
| MicroEJ and ART.
|
| Many don't have an idea of breath and depth of Java
| ecosystem, and what guest languages can profit from.
| sswezey wrote:
| Have you seen Jank? It's a Clojure dialect being written in
| C++ and designed for interop with C++ instead of the JVM.
|
| https://jank-lang.org/
| runevault wrote:
| Speaking as someone who was using Clojure pre-1.0 through...
| 1.2? because I was so interested in Lisps and one with access
| to a modern library ecosystem excited me, I did not enjoy my
| time with Maven at all. It felt very janky. A second issue
| that I hear they finally fixed was Clojure still gave all of
| the low level parts of the error that were basically the guts
| of Clojure and had nothing to do with my code which I got
| tired of dealing with. Probably other issues I'm forgetting
| as I have not used it in a decade or so, but I just did not
| enjoy my time dealing with the JVM ecosystem.
| cschep wrote:
| you might like https://janet-lang.org/ !
| agambrahma wrote:
| Take a look at Gerbil Scheme
|
| https://cons.io/
| beders wrote:
| Some good progress on Jank lately:
|
| https://jank-lang.org/
| whartung wrote:
| I don't consider it an extended Lisp, rather I just consider it a
| "batteries included", bundled library distribution of Lisp.
|
| 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.
| gus_massa wrote:
| > _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)._
|
| I don't know every single implementation of Scheme, but at
| least the Chez Scheme compiler has a lot of special code for
| records. The compiler sees them as records, tries to inline as
| many getters and setters as possible, and has low level support
| for the tree of subrecords and I may be missing a few more
| tricks. You can go to
| https://github.com/cisco/ChezScheme/blob/main/s/cp0.ss and
| Ctr+F record . For example
| https://github.com/cisco/ChezScheme/blob/main/s/cp0.ss#L3816...
|
| The old implementation of Racket also had some tricks, but now
| the structs are transformed to Chez Scheme records.
| ducktective wrote:
| Maybe that's why Chez is the most performant scheme.
|
| I've heard people suggest that a more expanded scheme would
| become a ~lisp. "Common" lisp was formed as a moderately
| expansive standard for lisps of its time.
| breck wrote:
| Looks different than Ciel, another Lisp from 2010
| (https://pldb.io/concepts/ciel.html), by Ron Garret, rocket
| scientist (https://flownet.com/ron/).
| floxy wrote:
| Since everyone likes something just a wee bit different, I'd also
| like to see something where most of the functions in :COMMON-LISP
| are made generic, so you can overload '+, etc. to work on
| vectors, etc.. Obviously you can do it yourself on a per-project
| basis.
| Blackthorn wrote:
| That's part of Ciel!
| floxy wrote:
| That's great! Is that described in the documentation? I can't
| seem to find it.
| vindarel wrote:
| good catch! It is only mentioned at the end of the install
| section: http://ciel-lang.org/#/install?id=use-in-the-repl-
| and-in-new...
|
| This feature is based on generic-cl, a high quality
| library. To be franc, I didn't test much the integration
| with generic-cl, it's on the todo list. When I started out,
| I was carving for a library like this. Now, I don't feel
| the need anymore.
| tmtvl wrote:
| You mean something like generic-cl? https://github.com/alex-
| gutev/generic-cl
| BoingBoomTschak wrote:
| I think https://github.com/CodyReichert/awesome-cl with a bit
| more trimming/tagging and interactivity (e.g. show all "stars")
| to empower users to explore the ecosystem and build their own
| image is a better way.
|
| There should also be a large disclaimer saying "Consider
| disregarding portability in favour of SBCL to get a more modern
| experience".
| begueradj wrote:
| "Ciel" means "sky", in French language.
| jng wrote:
| surely not a coincidence
| medo-bear wrote:
| How come Ironclad is not included?
| michael-ax wrote:
| Could this get a wrapper for building ncurses & sdl cores so that
| maybe one day lem could run right on top of ciel and a true lisp
| environment could emerge?
| https://news.ycombinator.com/item?id=41357409
___________________________________________________________________
(page generated 2024-08-30 23:00 UTC)