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

[Leandro André Zis]

Hi

There is a project in microsoft research called ILX that proposes 
functional extensions to IL like closures.
They implemented a Caml in .Net using ILX.

The adress is:
http://research.microsoft.com/projects/ilx/ilx.aspx

Paolo Molaro wrote:

>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
>
>  
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ximian.com/pipermail/mono-devel-list/attachments/20040216/0104f312/attachment.html