Here is a small Lisp-like compiler for .NET, designed mainly for rapid
Domain Specific Languages implementation:

http://www.meta-alternative.net/techpreview.html

It is a binary preview release so far. Later on, depending on the
level of public interest, core sources may be released under QPL.

Potentially interesting features include:
 * Incremental, Common Lisp-style compilation semantics, while
maintaining a normal .NET separate compilation mode.
 * Compiler building tools out of the box: pattern matching, smart AST
transforms, easy lexing & parsing,   etc.
 * Relatively efficient, self-bootstrapping, pure .NET compiler, no
3rd party tools required.
 * Hierarchical metaprogramming paradigm is utilised extensively.
 * Works well with Unix and Mono (developed and tested with Mono
1.3.x).

In article <1183412244.494239.268350@c77g2000hse.googlegroups.com>,
 info@meta-alternative.net wrote:

> Here is a small Lisp-like compiler for .NET, designed mainly for rapid
> Domain Specific Languages implementation:
> 
> http://www.meta-alternative.net/techpreview.html
> 
> It is a binary preview release so far. Later on, depending on the
> level of public interest, core sources may be released under QPL.
> 
> Potentially interesting features include:
>  * Incremental, Common Lisp-style compilation semantics, while
> maintaining a normal .NET separate compilation mode.
>  * Compiler building tools out of the box: pattern matching, smart AST
> transforms, easy lexing & parsing,   etc.
>  * Relatively efficient, self-bootstrapping, pure .NET compiler, no
> 3rd party tools required.
>  * Hierarchical metaprogramming paradigm is utilised extensively.
>  * Works well with Unix and Mono (developed and tested with Mono
> 1.3.x).

How about documentation?

-- 
http://lispm.dyndns.org

On Jul 2, 10:43 pm, Rainer Joswig <jos...@lisp.de> wrote:

> How about documentation?

 Only annotated examples & tutorial so far, and generic architecture
notes (see outline.txt).

 Autogenerated documentation will be available later along with
sources; there's no reason to publish the documentation on not yet
stabilized public API - in order to discurage people from trying to
use it prematurely. We need some more generic feedback first to
decide, which parts of the core to disclose.