IronPython: A fast Python implementation for .NET and Mono

P

Phil Tomson

This should be of of interest to those who would like to see a .NET
implementation of Ruby:

http://www.python.org/pycon/dc2004/papers/9/

A Pithy quote:

"Unfortunately, as I carried out my experiments I found the CLR to be a
surprisingly good target for dynamic languages, or at least for the highly
dynamic specific case of Python. This was unfortunate because it meant
that instead of writing a short pithy paper I had to build a full Python
implementation for this new platform to see if there would be any hidden
traps along the way. "

I still wanna see Ruby on Parrot, though.

Phil
 
A

Archit Baweja

Hey

Well not exactly in the same domain, but there are some Ruby -> .Net proxy libs
which actually work both ways (Ruby to .Net and vice-versa). So one can use
Ruby Objects from .Net, and .Net objects from Ruby. I think a more modular way
to approach the problem than writting a byte-code compiler for Ruby for .Net

hope that helps
Archit
 
G

gabriele renzi

il 19 May 2004 04:37:41 GMT, (e-mail address removed) (Phil Tomson) ha
scritto::
A Pithy quote:

"Unfortunately, as I carried out my experiments I found the CLR to be a
surprisingly good target for dynamic languages, or at least for the highly
dynamic specific case of Python. This was unfortunate because it meant
that instead of writing a short pithy paper I had to build a full Python
implementation for this new platform to see if there would be any hidden
traps along the way. "

still, python uses less magic than ruby.
Just consider the enormous use of eval in any form, callcc, and proc
objects that we do.


IIRC one of the students of robert feldt is working on a ruby .net
compiler and there is the rubydotnet bridge that works kinda good.
I still wanna see Ruby on Parrot, though.

I'm waiting to see who wins the piethon ;)
 
R

Robert Feldt

gabriele said:
il 19 May 2004 04:37:41 GMT, (e-mail address removed) (Phil Tomson) ha
scritto::




still, python uses less magic than ruby.
Just consider the enormous use of eval in any form, callcc, and proc
objects that we do.
I'm not very much into Python but I agree that it seems to have less
magic which makes Ruby harder to compile for the CLR.
IIRC one of the students of robert feldt is working on a ruby .net
compiler and there is the rubydotnet bridge that works kinda good.
That is correct. He is finishing up a paper about it that we hope to
make available in 1-2 weeks. The prototype compiler he built is not
ready for public consumption but we hope to start an open-source project
around it this summer. As you can imagine we are far from supporting
callcc, in fact I think it is a hard one to support on the CLR without
going through major hoops (actually we are far from supporting several
things but you gotta start somewhere ;)). There are several
scheme-for-clr compilers out there though and they seem to support a
limited form of continuations so there might be at least a partial way
forward there.

Proc and eval we have high hopes of being able to solve although it is
not in the prototype. Proc is the easiest and there are several
possibilities for how to compile them (new class for each unique one or
using delegates in CIL). Eval is hairier since the compiler itself needs
to be in there for that but the dynamic update of methods seems doable
so in principle it could work. I'm sure there are many problems we have
yet to encounter though... ;)

Regards,

Robert
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,744
Messages
2,569,480
Members
44,900
Latest member
Nell636132

Latest Threads

Top