[IronPython] IronPython status

[Bob Ippolito]

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 
isn't :)

> 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.

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 
> 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.

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 
> 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.

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 
> for
> a language written in the same interpreted languge can be judged 
> 'better'
> 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.

-bob