IronPython: A fast Python implementation for .NET and Mono

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

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

ptkwt@aracnet.com (Phil Tomson) writes:

···

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


Homepage: http://puggy.symonds.net/~bighead/
Projects:
http://peacock.sourceforge.net/
http://ore.rubyforge.net/

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 :wink:

···

il 19 May 2004 04:37:41 GMT, ptkwt@aracnet.com (Phil Tomson) ha scritto::

gabriele renzi wrote:

il 19 May 2004 04:37:41 GMT, ptkwt@aracnet.com (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.

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… :wink:

Regards,

Robert

This is interesting, in light of a recent blog by Seth Nickell:
http://www.gnome.org/~seth/blog/mono

— SER

SER wrote:

This is interesting, in light of a recent blog by Seth Nickell:
http://www.gnome.org/~seth/blog/mono

— SER

I think it’s always safer to not trust MS in any way. Trust can only
exist between equal parties.
But noone could possibly claim to be MS’s equal when it comes to legal
fights.
I won’t buy into .NET no matter what people say how good it’s supposed
to be.
If MS were really as good as they always claim, they would have invented
Ruby, right? :wink:
But as it is, MS never invented anything…

Carsten.

···


Carsten Eckelmann carsten@circle42.com
http://carsten.circle42.com

Hi,

···

In message “Re: IronPython: A fast Python implementation for .NET and Mono” on 04/05/21, Carsten Eckelmann careck@circle42.com writes:

If MS were really as good as they always claim, they would have invented
Ruby, right? :wink:

They bought Ruby, and renamed it as Visual Basic.
Google it. It’s a true story.

						matz.

p.s.
That Ruby is not our Ruby though.

matz@ruby-lang.org (Yukihiro Matsumoto) wrote:

···

In message “Re: IronPython: A fast Python implementation for .NET and Mono” > on 04/05/21, Carsten Eckelmann careck@circle42.com writes:

If MS were really as good as they always claim, they would have invented
Ruby, right? :wink:

They bought Ruby, and renamed it as Visual Basic.
Google it. It’s a true story.

  					matz.

p.s.
That Ruby is not our Ruby though.

History is funny… lets hope it doesn’t repeat :wink:


Simon Strandgaard