Any benchmarks? I have a combinatorial enumeration comparison project where the .NET jit optimized my hot loops for F# to in some cases matching Rust performance. F# is inspired by OCaml, and for me F# runs twice as fast.
Scala got a face lift where indentation replaces syntax, a modern poetry look many of us can't live without. It is entirely practical to eliminate most parentheses from Lisp (I have written thousands of lines of Scheme this way, hands down my favorite code to read), but doing so will lead to a tribal swarm attack. It is also easy to train Common Lisp to lay off the caps, but any stock installation greets users with an old man shouting (GET OFF (MY LAWN)).
The idea of Lisp is pure genius. One wonders where we would be today if any Lisp took a more pragmatic attitude towards encouraging adoption.
If Dotcl does have good performance, it would be interesting to try running Coalton on top of it too. Coalton syntax is probably not unusual if you are familiar with OCaml and F#: https://github.com/coalton-lang/coalton (Though I'd expect the performance of the typical use case of running on top of SBCL to still be better.)
From the same project there's the recently released mine editor that's trying to be a friendlier gateway into trying Common Lisp (and/or Coalton) than emacs: https://coalton-lang.github.io/mine/ Time-to-first-SHOUTING is still once you start a REPL though -- it tells you that your package (namespace) is CL-USER. I sort of think it's one of those things that grows on you, or at least isn't annoying after a while (until you need to deal with certain foreign function interfaces anyway), and it's an interesting possible convention to use SHOUT-CASE in docstrings to call out specific parameters or other function names instead of some @param, \param, @link, or what have you.
Re that last: FWIW, in Emacs Lisp (which is case-preserving and mostly lowercase by convention, without the legacy symbol case behavior of CL), docstring convention is to use single quotes for most literals and to use all-caps to mean the value of a local symbol—usually a function argument, but sometimes a variable introduced in running text for describing the structure of data or such. Last I checked, CL wasn't as consistent across projects, but I tend to carry the Emacs convention there when not conforming to a different local style, and wonder sometimes who would have their monocle pop off to see it…
I feel CLISP is pragmatic (it’s both low level and high level, multi purpose, has a formal specification, is a standard), but the world just changed too much around it.
This has been the best grounded approach of introducing Lisp to the masses, myself included. Rich Hickey made a language that is the most well positioned in this new LLM era.
It has very good throughput since it's targeting the JVM. JEP 514 and JEP 515 are also making AOT a real thing, reducing warmup times. This means user will not even have to use the awesome Babashka project for scripts or drop in GraalVM.
Given how simple TCL is you would probably write a parser in a day...
JimTCL (jimsh interpreter) is not 100% TCL compatible and I just used 'source qcomplex.tcl' from it's big brother TCL and now I can do complex number operations in the spot. With just a simple file, no libraries, no nothing.
This is amazing. How long did it take you to implement it, i.e. reach that high level of Ansi test conformance? Have you been able to reuse concepts e.g. from ABCL?
I have recently blogged that AI and Common Lisp don't mix, but I've come to the opposite conclusion lately. AI evens the playing field between large teams and single developers. Now all the lone wolves in cl will be able to do large things, like a .net implementation or a yaml parser. I heard one guy say he was using AI to write a c complete in common lisp. I wonder if AI was used here or not.
Use python or whatever to build the llm, use lisp to explore and infer from the edges of what the llm has to offer. I don't do anything but lisp these days. Been waiting my whole career to be at this point. I'll never "write" a line of C# again. Just my taste and pref.
Had it not been for UNIX taking over the Lisp workstations market, followed by the first AI winter, people would be using LispTorch today, and there wouldn't have been such a waste coming up with endless ways to speed up Python, and efforts like Mojo wouldn't even be a thing.
Not really the "fault" of UNIX. The Lisp workstations would have been just as unpopular without it. They were insanely expensive and the idea of a workstation was ahead of its time, not to mention the other "unneeded" extras like GUIs, a mouse, and the photo editing and 3D modelling suites. It was plainly uneconomical.
UNIX was only cheap because AT&T was forbidden to profit from it, had it not been the case, it would have been a proprietary closed source OS, exactly at similar price points.
The proof being the graphical UNIX workstations from Cray, SGI, Sun, NeXT that came later into the market.
The dimension you're missing here is that most of the Lisp OSs were single-user (AFAIK initially all of them were but some gained multi-user support later) in a period when timeshare was king. Not to mention that the hardware itself cost multiple times more to manufacture.
Neat, I see AOT, will this be able to target WASM? I’m guessing there will be a mode that doesn’t use reflection emit since AOT doesn’t support that? I would check myself but I’m away from my computer.
MSIL was designed to support plenty of languages, including C and C++, which WebAssembly advocates tend to never mention.
As such there are plenty of MSIL and CLR capabilities not yet fully exposed in C#.
One of the improvements in C# during the last decade, has been exposing low level coding abilities into C#, which is nothing more than taking advantage of those primitives originally designed for C and C++ support.
Likewise, .NET also had support back in 2001 for FP languages, thus TCO.
It's not unusual for lisp interpreters to lack TCO. Also the (relative) popularity of dynamic binding in Common Lisp reduced the opportunities for TCO.
There's not really a consensus in the parts of the CL community that I'm familiar with on whether or not code relying on TCO is idiomatic or not.
Unfortunate near naming collision for people using doctl (the Digital Ocean CLI). I can foresee a lot of shell muscle memory causing me to use the wrong tool :-D
Really cool project! Love seeing CL work it's way into as many envs as possible
Any benchmarks? I have a combinatorial enumeration comparison project where the .NET jit optimized my hot loops for F# to in some cases matching Rust performance. F# is inspired by OCaml, and for me F# runs twice as fast.
Scala got a face lift where indentation replaces syntax, a modern poetry look many of us can't live without. It is entirely practical to eliminate most parentheses from Lisp (I have written thousands of lines of Scheme this way, hands down my favorite code to read), but doing so will lead to a tribal swarm attack. It is also easy to train Common Lisp to lay off the caps, but any stock installation greets users with an old man shouting (GET OFF (MY LAWN)).
The idea of Lisp is pure genius. One wonders where we would be today if any Lisp took a more pragmatic attitude towards encouraging adoption.
This project? https://github.com/Syzygies/Compare
If Dotcl does have good performance, it would be interesting to try running Coalton on top of it too. Coalton syntax is probably not unusual if you are familiar with OCaml and F#: https://github.com/coalton-lang/coalton (Though I'd expect the performance of the typical use case of running on top of SBCL to still be better.)
From the same project there's the recently released mine editor that's trying to be a friendlier gateway into trying Common Lisp (and/or Coalton) than emacs: https://coalton-lang.github.io/mine/ Time-to-first-SHOUTING is still once you start a REPL though -- it tells you that your package (namespace) is CL-USER. I sort of think it's one of those things that grows on you, or at least isn't annoying after a while (until you need to deal with certain foreign function interfaces anyway), and it's an interesting possible convention to use SHOUT-CASE in docstrings to call out specific parameters or other function names instead of some @param, \param, @link, or what have you.
Re that last: FWIW, in Emacs Lisp (which is case-preserving and mostly lowercase by convention, without the legacy symbol case behavior of CL), docstring convention is to use single quotes for most literals and to use all-caps to mean the value of a local symbol—usually a function argument, but sometimes a variable introduced in running text for describing the structure of data or such. Last I checked, CL wasn't as consistent across projects, but I tend to carry the Emacs convention there when not conforming to a different local style, and wonder sometimes who would have their monocle pop off to see it…
Yes, that project. I keep thinking I'm done, but it's so much fun being a language tourist.
I feel CLISP is pragmatic (it’s both low level and high level, multi purpose, has a formal specification, is a standard), but the world just changed too much around it.
Have you tried Clojure?
I admire Clojure, and Rich Hickey's deep experience and knowledge of languages that he brought to the table. Clojure bottomed out for my comparison.
Perhaps an expert could strike a better balance, but it struck me and my various agents that we'd be fighting the language to make it faster.
https://github.com/Syzygies/Compare
This has been the best grounded approach of introducing Lisp to the masses, myself included. Rich Hickey made a language that is the most well positioned in this new LLM era.
Clojure isn't known for performance.
It has very good throughput since it's targeting the JVM. JEP 514 and JEP 515 are also making AOT a real thing, reducing warmup times. This means user will not even have to use the awesome Babashka project for scripts or drop in GraalVM.
Dotcl sounds like a lisp macro that interprets TCL. :D
hehe. alternatively dotnil would have sounded closer to dotnet while hinting at lisp terminology and history
Given how simple TCL is you would probably write a parser in a day...
JimTCL (jimsh interpreter) is not 100% TCL compatible and I just used 'source qcomplex.tcl' from it's big brother TCL and now I can do complex number operations in the spot. With just a simple file, no libraries, no nothing.
Not my project, but I feel mention of IronScheme is appropriate. Leppie has been maintaining it for many years now.
[0] https://github.com/IronScheme/IronScheme
There's also Bike for CL/.NET interop: https://github.com/Lovesan/bike
Awesome! Has a MonoGame integration sample. Am curious to see if it will work with Godot or Unity. New weekend project...
This is amazing. How long did it take you to implement it, i.e. reach that high level of Ansi test conformance? Have you been able to reuse concepts e.g. from ABCL?
Yeah, pity that the early history seems to have been lost.
I have recently blogged that AI and Common Lisp don't mix, but I've come to the opposite conclusion lately. AI evens the playing field between large teams and single developers. Now all the lone wolves in cl will be able to do large things, like a .net implementation or a yaml parser. I heard one guy say he was using AI to write a c complete in common lisp. I wonder if AI was used here or not.
Use python or whatever to build the llm, use lisp to explore and infer from the edges of what the llm has to offer. I don't do anything but lisp these days. Been waiting my whole career to be at this point. I'll never "write" a line of C# again. Just my taste and pref.
Likewise, I would never have thought to be daily driving Elisp on Emacs and Clojure in production, but here we are.
may i ask which lisp variant you are using?
Franz Allegro toolchain.
Had it not been for UNIX taking over the Lisp workstations market, followed by the first AI winter, people would be using LispTorch today, and there wouldn't have been such a waste coming up with endless ways to speed up Python, and efforts like Mojo wouldn't even be a thing.
Not really the "fault" of UNIX. The Lisp workstations would have been just as unpopular without it. They were insanely expensive and the idea of a workstation was ahead of its time, not to mention the other "unneeded" extras like GUIs, a mouse, and the photo editing and 3D modelling suites. It was plainly uneconomical.
UNIX was only cheap because AT&T was forbidden to profit from it, had it not been the case, it would have been a proprietary closed source OS, exactly at similar price points.
The proof being the graphical UNIX workstations from Cray, SGI, Sun, NeXT that came later into the market.
The dimension you're missing here is that most of the Lisp OSs were single-user (AFAIK initially all of them were but some gained multi-user support later) in a period when timeshare was king. Not to mention that the hardware itself cost multiple times more to manufacture.
How many UNIX graphical workstations from Cray, SGI, Sun, NeXT do you think were multiuser in practice?
As for price, they were also not cheap to get.
You could probably say the same about any operating system, especially if you exclude the same human user operating in multiple roles.
Though in the Unix environment, additional user accounts and groups that don't actually correspond to separate humans have a lot of pragmatic uses.
Yes, however that wasn't a relevant feature for 1980-90's workstation market, like under which user the printer daemon would be running under.
Neat, I see AOT, will this be able to target WASM? I’m guessing there will be a mode that doesn’t use reflection emit since AOT doesn’t support that? I would check myself but I’m away from my computer.
There is also a native implementation of Clojure on the Common Language Runtime (CLR) https://github.com/clojure/clojure-clr
Does it have tail recursion?
If nothing else dotnet has TCO IL operations (C# doesn't compile down to them last I knew but F# does) so in theory shouldn't be hard to add.
MSIL was designed to support plenty of languages, including C and C++, which WebAssembly advocates tend to never mention.
As such there are plenty of MSIL and CLR capabilities not yet fully exposed in C#.
One of the improvements in C# during the last decade, has been exposing low level coding abilities into C#, which is nothing more than taking advantage of those primitives originally designed for C and C++ support.
Likewise, .NET also had support back in 2001 for FP languages, thus TCO.
https://news.microsoft.com/source/2001/10/22/massive-industr...
I'm pretty sure it does. I would even think that it tries to optimize such, as a recent check-in comment claims improvements of TCO.
A lisp without tail recursion would be a sad thing.
It's not unusual for lisp interpreters to lack TCO. Also the (relative) popularity of dynamic binding in Common Lisp reduced the opportunities for TCO.
There's not really a consensus in the parts of the CL community that I'm familiar with on whether or not code relying on TCO is idiomatic or not.
Common Lisp does not require implementations preform tail call optimization in general, or even in just the limited case of tail recursion.
Kudos, this is what I was looking for. Time to add dynamic "scripting" to my .net projects.
I was just wondering the other day if this exists. Great timing.
Great! A new toy on my toolbox.
Kudos on the implementation.
Does it have a REPL?
Unfortunate near naming collision for people using doctl (the Digital Ocean CLI). I can foresee a lot of shell muscle memory causing me to use the wrong tool :-D
Really cool project! Love seeing CL work it's way into as many envs as possible