48

Are there any Common Lisp implementations for .Net?

Joshua Taylor
  • 84,998
  • 9
  • 154
  • 353
TraumaPony
  • 10,742
  • 12
  • 54
  • 74

9 Answers9

29

I haven't looked at it recently, but at least in the past there were some problems with fully implementing common lisp on the CLR, and I'd be a little surprised if this has changed. The issues come up with things like the handling of floats where .net/clr has a way to do it that is a) subtly incorrect b) disagrees with the ANSI standard for common lisp but c) doesn't allow any way around this. There are other similar problems. This stuff is fiddly and perhaps not too important, but means you are unlikely to see an ANSI CL on the CLR.

There are bigger issues, for example common lisp has a more powerful object system, so you can't map it 1:1 to object in the runtime (no MI, for one). This is ok, but leaves you with an inside/outside sort of approach which is what a common runtime tries to avoid...

Whether or not you'll see a common lisp-ish variant running on it is a different story, but I don't know of any at the moment (not that I've looked hard)

simon
  • 7,044
  • 2
  • 28
  • 30
  • 1
    You can use the MOP to adopt any object model you want. Not so sure about how to handle the numeric edge cases problem though. – jfm3 Sep 23 '08 at 17:56
  • 2
    @jfm3: yes, there is a lot you can do, but it won't get rid of the impedence mismatch between CLOS and the runtime's object system. Being a more general system, CLOS would still have to marshall stuff and out of the runtime as objects. You can make this livable using MOP, but not exactly native. – simon Sep 24 '08 at 22:01
  • 2
    How is Lisp's object system more powerful than .Net? – Hamish Grubijan Jan 08 '10 at 02:40
  • 9
    Hamish, CLOS has multiple dispatch as well as multiple inheritance. Along with things like before/after methods, and dynamic (runtime) update of classes and instances is possible. So the call resolution is complicated and afaics you simply can't reproduce it in .NET (or Java, or c++, etc...) – simon Nov 06 '10 at 19:47
  • 1
    Due to its performance issues, many LISP programmers decide not to use CLOS and just program in "plain old lisp" (structures and functions etc.) So, a subset CL without controversial CLOS would be nice to have, IMHO. – BitTickler May 03 '22 at 13:35
17

If it's OK to go the other way around, you can access .Net from your favourite Lisp through Edi Weitz' RDNZL.

Mikael Jansson
  • 4,801
  • 1
  • 24
  • 14
17

No, but you might want to consider IronScheme running on the DLR.

From the website:

IronScheme will aim to be a R6RS conforming Scheme implementation based on the Microsoft DLR.

IronScheme will be a complete rewrite of IronLisp incorporating lessons learnt while developing IronLisp.

Michiel Borkent
  • 34,228
  • 15
  • 86
  • 149
15

Reconsidering this question from 2008 in 2010, you now might want to consider Clojure on the CLR. It's not Common Lisp, but it will be fairly easy to learn if you are coming from that direction. Interoperating with the CLR is dead-easy, it takes on more users every day and addresses several other important topics like concurrency. Might be worth investing some time in it. More CLR specific Clojure info here.

Michiel Borkent
  • 34,228
  • 15
  • 86
  • 149
7

L Sharp .NET

Scott Lerch
  • 2,620
  • 1
  • 23
  • 34
willurd
  • 11,745
  • 5
  • 28
  • 23
6

Full common lisp for .NET http://code.google.com/p/uabcl/

logicmoo
  • 46
  • 2
  • 3
2

#Script Lisp

I'm developing #Script Lisp, an enhanced version of Nukata Lisp with a number of new features that reuses #Script existing scripting capabilities to provide seamless integration with both the rest of #Script (see Language Blocks an Expressions) and .NET including Scripting of .NET Types, support for all .NET numeric types and access to its comprehensive library of over 1000+ Script Methods - optimally designed for accessing .NET functionality from a dynamic language.

To improve compatibility with existing Common Lisp source code it also implements most of the Simplified Common Lisp Reference as well as all missing functions required to implement C# LINQ 101 Examples in Lisp:

#Script Lisp LINQ Exmples

and to improve readability and familiarity it also adopts a number of Clojure syntax for defining a data list and map literals, anonymous functions, syntax in Java Interop for .NET Interop, keyword syntax for indexing collections and accessing index accessors and Clojure's popular shorter aliases for fn, def, defn - improving source-code compatibility with Clojure.

YouTube Demos

Because it's a first-class #Script language, it benefits from its wide ecosystem of supported use-cases, a few of which you can preview in the YouTube videos below:

Install

#Script Lisp can be installed instantly from the x cross-platform dotnet tool that can be installed with:

$ dotnet tool install -g x

Where you'll be able to bring up an instant Lisp REPL with:

$ x lisp

and be able to run and watch Lisp scripts where you can view changes in real-time.

The same functionality is available in the Windows app dotnet tool:

$ dotnet tool install -g app

Which in addition will let you use #Script Lisp to develop Gist Desktop Apps and Sharp Apps (.NET Core Windows Desktop Apps).

mythz
  • 141,670
  • 29
  • 246
  • 390
2

As of 2019 there is now Bike: https://github.com/Lovesan/bike It implements a cross-platform Common Lisp interface to the .Net Core platform, using lisp compatibility layers.

  • First of all, it is RDNZL reborn
  • This time, on .Net Core, without a line of C++ code, and fully cross-platform

(saw that on https://github.com/CodyReichert/awesome-cl#net-core)

Ehvince
  • 17,274
  • 7
  • 58
  • 79
0

You could try this (Disclaimer, I haven't tested it myself). Also read this. that's where the link came from.

Community
  • 1
  • 1
dsm
  • 10,263
  • 1
  • 38
  • 72