Axiomizing .net

I have been thinking about what lisp would mean in terms of implementing it on a .net framework. Here are some conclusions:

The DLR (dynamic language runtime) provides four basic services (http://en.wikipedia.org/wiki/Dynamic_Language_Runtime):
1. Dynamic type system.
2. Dynamic method dispatch.
3. Dynamic code generation.
4. Hosting API.

The power of lisp, above and beyond other languages (for me), comes from a only three things:

1. Syntactical Simplicity. Lists of lists. This enables levels of metaprogramming that would be impossible with a complex language.
2. Macros. The ability to extend the language in ways that do not look different than any other lisp code.
3. Minimal language specification. Given 6 keywords and macros, you can build all of common lisp. It really has axiomized computing down to the basic primitives required. Everything else is gravy.

I think an appropriate LISP implementation using the DLR would be the most minimal LISP API that exposes a self hosting compiler/environment (thus macros work) as well as access to all 4 DLR services.

I think it would be awesome if you had the most bare-minimum wrapper that included just enough to work and very raw access to everything else. Then people could build macros that extended the compiler with better support for .net paradigms.

I guess what I am trying to say is that I would write a system that built, layer upon layer, upon the lowest possible denominators. The fact that you can extend the compiler easily means that I, as the language implementor, should implement bare minimum full API access to the four services. I assume that everything else comes through those services, and the more I can expose them the better.

This would be a LISP for experts. In order to use the rawest version, you will need to have an excellent understanding of the CLR and DLR. It would make literally anything possible, however.

That is the theory, anyway. Implement the bare minimum that makes supporting the full .net system theoretically possible, and then thoroughly document the implementation and its implications. This LISP wouldn't be a common lisp implementation on .net. I would have lists, car, and cdr, but not much else. There is no need for hashes or vectors or anything like that, .net already has those.

It comes down to how do you do the least amount of work in order to gain all the important advantages of LISP along with the important advantages of the .net framework, the CLR and DLR. Absolutely no 'niceness' wrapping at the lowest level, just bare minimum axiomatic access to the base services.

Perhaps using the core system, writing a standard .net class takes 5 times the LOC that it does in C# because you have to explicitly specify all the assumptions the C# compiler uses. The key point is that if you have macros, it doesn't matter at all because clients can just write macros and such that make the same assumptions but the underlying language allows experimentation with very different assumptions.

Anyway, I don't know how closely the current .net LISP matches this paradigm. I will have to study iron [python|ruby] a bit to gain a good idea on what a good .net language implementation should look like, and then go over the existing LISP one(s).

Think of the power of axiomizing support for .net. It should be similar to the power of axiomizing computing just translated into a different domain. Perhaps there are crazy ways of defining properties that csharp doesn't allow. Perhaps there are class extensions and clever things you can do that you can't in any language but that aren't explicitly forbidded in the .net system; you just don't have low level enough access to use them.

The point is that because LISP enables endlessly powerful metaprogramming, language implementors should never make any assumptions whatsoever. They should write to the exact .net platform specification, and let macros upon macros simplify the low level description into useful abstractions.

Chris