Dotcl: Common Lisp Implementation on .NET(github.com) |
Dotcl: Common Lisp Implementation on .NET(github.com) |
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.
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.
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.
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...
Kudos on the implementation.
Really cool project! Love seeing CL work it's way into as many envs as possible
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.
The proof being the graphical UNIX workstations from Cray, SGI, Sun, NeXT that came later into the market.
As for price, they were also not cheap to get.
Though in the Unix environment, additional user accounts and groups that don't actually correspond to separate humans have a lot of pragmatic uses.