[IronPython] IronPython status

Andy Somogyi andy_somogyi at hotmail.com
Wed Feb 23 01:13:49 CET 2005


>
>>Also, part of the Boo implementation is in c# and the other part is in 
>>Boo. I am really not fond of interpreters written in the interpretting 
>>language. I think the CPython / Jython / IronPython approach is MUCH 
>>better, faster, more stable and easier to follow.
>
>Quite a few very smart people would disagree with you on this point!
>
>-bob

Thats OK, this is America and we are allowed to do that :)

In the case of Boo, IMO, it might not be that bad of an idea as Boo
is essentially a statically typed python, so it can be compiled to standard 
IL instructions
just like any other statically typed .net language. In other words it does
NOT require an interpreter or run time libraries (other than the standard 
.net lib).

A dynamically typed language such as Python can not be *FULLY* compiled to
IL. This is because Python is a dynamic language, the exact operations 
performed
on variables will depend on thier type, and this is not known untill 
runtime.

IronPython does compile all stack operations expressions to IL, but
the IL code assigments, calls, etc... ends up calling the various library 
support
functions. It is the library functions where all assigments, calls, etc.. 
end
up being made as this is where the logic to determine what operation to
perform based on variable types is done.

So, you still end up requiring a farily extensive support library. 
IronPython (and Jython)
blur the line between an interpreted and a compiled language.

If the library functions were themselves written in Python, we would have
the chicken and egg issue, how do you bootstrap it? You end up needing
another interpreter / runtime to support the interpreter / runtime you are
writting.

While I'm sure there are several advantages to this approach, and I'm sure
there are many supporters of this approach, personally, I like the approach
CPython / Jython / IronPython took, and that is why I have decided to
put my efforts behind IronPython.

As for my earlier statment, I will retract the word 'better' as this is a 
very
subjective term. I'm sure there is some situation where a interpreter for
a language written in the same interpreted languge can be judged 'better'
by some set of metrics.





More information about the Ironpython-users mailing list