Shed Skin Python-to-C++ Compiler 0.0.21, Help needed

[Kay Schluehr]

On Apr 1, 6:07 pm, John Nagle <n... at animats.com> wrote:
> Kay Schluehr wrote:
> > Indeed. The only serious problem from an acceptance point of view is
> > that Mark tried to solve the more difficult problem first and hung on
> > it. Instead of integrating a translator/compiler early with CPython,
> > doing some factorization of Python module code into compilable and
> > interpretable functions ( which can be quite rudimentary at first )
> > together with some automatically generated glue code and *always have
> > a running system* with monotone benefit for all Python code he seemed
> > to stem an impossible task, namely translating the whole Python to C++
> > and created therefore a "lesser Python".
>
>     Trying to incrementally convert an old interpreter into a compiler
> is probably not going to work.

I'm talking about something that is not very different from what Psyco
does but Psyco works at runtime and makes continous measurements for
deciding whether it can compile some bytecodes just-in-time or let the
interpreter perform their execution. You can also try a different
approach and decide statically whether you can compile some function
or interpret it. Then you factorize each module m into m = m_native *
m_interp. This factorization shall depend only on the capabilities of
the translator / native compiler and the metadata available for your
functions. Since you care for the correct interfaces and glue code
early and maintain it continually you never run into severe
integration problems.

----------------------------------------------------------

A factorization always follows a certain pattern that preserves the
general form and creates a specialization:

def func(x,y):
    # algorithm

====>

from native import func_int_int

def func(x,y):
    if isinstance(x, int) and isinstance(y, int):
       return func_int_int(x,y)  # wrapper of natively compiled
specialized function
    else:
       # perform original unmodified algorithm on bytecode interpreter

Or in decorator notation:

from native import func_int_int

@apply_special( ((int, int), func_int_int) )
def func(x,y):
    # algorithm

where apply_special transforms the first version of func into the
second version.

Now we have the correct form and the real and hard work can begin i.e.
the part Mark was interested and engaged in.

>
> > Otherwise it
> > wouldn't be a big deal to do what is necessary here and even extend
> > the system with perspective on Py3K annotations or other means to ship
> > typed Python code into the compiler.
>
>      Shed Skin may be demonstrating that "annotations" are unnecessary
> cruft and need not be added to Python.  Automatic type inference
> may be sufficient to get good performance.

You still dream of this, isn't it? Type inference in dynamic languages
doesn't scale. It didn't scale in twenty years of research on
SmallTalk and it doesn't in Python. However there is no no-go theorem
that prevents ambitious newbies to type theory wasting their time and
efforts.

> The Py3K annotation model is to some extent a repeat of the old
> Visual Basic model.  Visual Basic started as an interpreter with one
> default type, which is now called Variant, and later added the usual types,
> Integer, String, Boolean, etc., which were then manually declared.
> That's where Py3K is going.

Read the related PEP, John. You will see that Guidos genius is that of
a good project manager in that case who knows that the community works
for him. The trade is that he supplies the syntax/interface and the
hackers around him fantasize about semantics and start
implementations. Not only annotations are optional but also their
meaning. This has nothing to do with VB and it has not even much to do
with what existed before in language design.

Giving an example of annotation semantics:

def func(x:int, y:int):
    # algorithm

can be translated according to the same pattern as above. The meaning
of the annotation according to the envisioned annotation handler is as
follows: try to specialize func on the types of the arguments and
perform local type inference. When successfull, compile func with
these arguments and map the apply_special decorator. When translation
is unfeasible, send a warning. If type violation is detected under
this specialization send a warning or an exception in strict-checking-
mode.

I fail to see how this violates duck-typing and brings VisualBasic to
the Python community. But maybe I just underrate VB :)

Kay