Mono and Python

[Robert N. Deviasse]

"Andrew Kuchling" <akuchlin at mems-exchange.org> wrote in message
news:3dheq44v45.fsf at ute.mems-exchange.org...
> Similarly, I think MS would like people to use the CLI/CLR and
> therefore entices them with the run-any-language-you-like carrot.  But
> only C# and VB will run really quickly -- remember, the .net port of
> Python ran about 10 times slower than MS's anointed languages,

That's a poor example. Take a look at their whitepaper:
   http://www.activestate.com/Initiatives/NET/Research.html

It basically says:
  Compiler
  --------
  The Python for .NET compiler is written using CPython.
  It compiles Python source code, and uses the .NET Reflection::Emit
  library to generate a .NET assembly.  The  COM Interoperability
  features of .NET are used to access the Reflection::Emit library.

  This particular strategy was chosen to minimize the implementation
  time.
  ...
  The primary drawback to this approach is the speed of the compiler.
  Much of the abstract syntax tree (AST) manipulation code is also
  written in Python code, and as this is one of the most CPU intensive
  areas of the compiler, we suffer a significant speed penalty.

  Further, the use of Reflection::Emit via COM is also causing us some
  performance problems.  Some of these problems are due to the speed of
  the Python COM bindings, but Reflection::Emit itself and/or the COM
  interoperability layers are also costing us significant time.

They basically chose the extremely slow approach in order to implement it
quickly. COM itself is slow, but writing a CPU intensive part of the code
in
Python sure doesn't help performance.

Later on, they say:
  The Python for .NET runtime defines a .NET interface (IPyType)
  that captures Python's semantics.  The definition of this interface
  is almost identical to the existing CPython type object, which is
  the object primarily responsible for object semantics in CPython.
  ...
  The Python for .NET runtime also exposes an API for use by the
  compiler, working almost exclusively with the PyObject structures.
  The runtime also provides a function for creating a new PyObject
  at runtime, given nothing but an anonymous .NET object reference.
  The compiler will frequently generate calls to create these PyObject
  structures (often storing the result in a variable), and also pass
  these PyObject structures back into the runtime as needed.

This isn't a bad approach, but why did they use non-portable COM
to implement this? They should have been able to use PInvoke() to
directly access the Python data structures. It would be far more portable
and efficient.



> because the CLR isn't well-suited to dynamic languages

Could you elaborate what you mean? Some usages of types can be
inferred, but for the general case, couldn't the following table-driven
class take care of the problem?

class FunctionDispatchTable
{
       // ...
       delegate void MemberFunction(object[] arguments);
       object addFunction(string functionName, MemberFunction
memberfunction);
       object dispatch(string functionName, params object[] arguments);
};

> -- and oh sorry,
> version 2.0 will probably break all those other languages, and at that
> point you'll just give up and write C# and VB code.


Could you elaborate? Looking at the template and functional additions to
the CLR, I don't see any reason why this would be the case.
        http://research.microsoft.com/projects/clrgen/
        http://research.microsoft.com/projects/ilx/