[IronPython] IronPython status
bob at redivi.com
Tue Feb 22 16:50:07 PST 2005
On Feb 22, 2005, at 19:13, Andy Somogyi wrote:
>>> 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!
> Thats OK, this is America and we are allowed to do that :)
Although you and I are probably both in America, the whole internet
> 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
> 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
> on variables will depend on thier type, and this is not known untill
Well the meaning of "fully" compiled is pretty ambiguous. You can do
it naively, and it would generate a bunch of code and be slow, but you
can do it.
> 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.
The line isn't very blurry, they're both completely interpreted
languages. IronPython is 100% IL bytecode and it generates nothing but
IL bytecode, which gets interpreted/translated by virtual machine.
Same for Jython, with some different acronyms.
> If the library functions were themselves written in Python, we would
> the chicken and egg issue, how do you bootstrap it? You end up needing
> another interpreter / runtime to support the interpreter / runtime you
The bootstrapping problem is solved because there is a Python
implementation already available (several, actually).
The approach that PyPy is taking is to implement Python in a subset of
Python that *can* be directly translated to a static form (but is also
valid Python code that can be tested/verified with a traditional
CPython interpreter). In order to make sure they're doing it right,
they have several backends in development (LLVM, Pyrex, C, etc.).
> While I'm sure there are several advantages to this approach, and I'm
> there are many supporters of this approach, personally, I like the
> CPython / Jython / IronPython took, and that is why I have decided to
> put my efforts behind IronPython.
And this approach is why there are three very distinct implementations.
If the majority of Python were written in Python, then Jython and
IronPython would be Python 2.4 compatible, each with the same complete
standard library (plus implementation specific support, of course).
> 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
> a language written in the same interpreted languge can be judged
> by some set of metrics.
Well there is plenty of prior art (C, C#, LISP, Scheme, Smalltalk,
etc.) that shows exactly how this is possible and reasonable, and how
it can be faster, easier to understand, and more portable than the
approach of writing a large part of the interpreter directly in some
host language. Also consider that the less code you write in C#, the
more useful it is to projects other than IronPython.
More information about the users-ironpython.com