[Mono-devel-list] New compiler--CIL/CTS questions

[Paolo Molaro]

On 02/14/04 Chris Capel wrote:
> As to your suggested solution: the problem is that Lisp doesn't have a
> run-time/compile-time distinction. The compiler and library are the same,
> and linked to the final executable. The compiler, to be a real Lisp, has to
> assume that any function definitions are being done at run-time. I'm not sure
> I understood what you were aiming for--the compiler generating C# code?

No, he presented the pseudo code (in C#) that you would be generating at
runtime using Reflection.Emit to implement closures in the CLI.

> I assume that you meant I would emit these types at runtime. Even still,
> (though I appreciate your example) your code is little more than mapping
> lisp primitives through a consideribly dense layer of object-oriented code,
> which goes against the purported point of the CLI, which is to allow lots of
> different languages to be implemented in a common runtime environment,

Why do you care about the implementation? It's like complaining that
many functional systems are implemented through "a considerably dense layer 
of C code and assembly". The CLI offers a fairly comprehensive instruction
set and some runtime methods: using them you can implement C#, VB,
javascript, cobol, scheme, python, java etc... Sure, some of the
implementations may incur a speed hit when implemented on the CLR,
because of the need to implement special semantics that differ from the
expected ones. But the hit is most of the time reasonable if you're
willing to spend some time on the compiler (and it's repaid by being
able to easily interface with code written in other languages).
I guess what you're looking for is a runtime that implements lisp
primitives, so you can write your lisp compiler almost with no code:-)
That's nice, but you wouldn't get any interoperability and any of the
above languages would run a lot slower on that VM.
If you have proposals for how to integrate 'lisp primitives' with teh
CLR, please, present them as many people here would love to discuss the
issues. Just complaining that the CLR doesn't provide lisp primitives
(when they can most likely be easily implemented with Re.Emit...) is not
helpful (last time I checked hw lisp machines are not in much use nowadays, 
maybe there are a few reasons...).

> Oh, I dunno. It's debateable. Developing a new compiler for mono could be
> considered mono related. The fact that it would work on any CLI compliant
> runtime is incidental. Besides, I didn't see any more appropriate mono-* list,
> and I figure you people have implemented a runtime, so you must be pretty
> familiar with it.

I think mono-devel is appropriate for discussing how to make the mono and
the CLR better at handling different languages.

> > Take a look at the DynamicMethod class from Net 1.2
>  
> Thanks, Zoltan. Do you know if this class performs well enough to be used
> as the primary function-calling mechanism of a language?

Function calls are a little more costly with delegates than with direct
calls (usually 2-3 times slower for empty methods): if your functions
actually do something it's not much of an issues (of course, where it
matters, you could build smarts in your compiler to do away with the
otherhead).

lupus

-- 
-----------------------------------------------------------------
lupus at debian.org                                     debian/rules
lupus at ximian.com                             Monkeys do it better