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

[Kay Schluehr]

On Apr 2, 9:17 am, John Nagle <n... at animats.com> wrote:
> mark.duf... at gmail.com wrote:
> > but in any case, I believe there are several reasons why type
> > inference scalability is actually not _that_ important (as long as it
> > works and doesn't take infinite time):
>
> > -I don't think we want to do type inference on large Python programs.
> > this is indeed asking for problems, and it is not such a bad approach
> > to only compile critical parts of programs (why would we want to
> > compile PyQt code, for example.) I do think type inference scales well
> > enough to analyze arbitrary programs of up to, say, 5,000 lines. I'm
> > not there yet with Shed Skin, but I don't think it's that far away (of
> > course I'll need to prove this now :-))
>
> > -type inference can be assisted by profiling
>

>      Something else worth trying: type inference for separately
> compiled modules using the test cases for the modules.

Seem like we agree on this point. The idea of defining a type
recording phase and identifying it with UT execution was actually my
original motivation to consider alternative frameworks for compiling
Python.

> One
> big problem with compile-time type inference is what to do
> about separate compilation, where you have to make decisions
> without seeing the whole program.  An answer to this is to
> optimize for the module's test cases.  If the test cases
> always use an integer value for a parameter, generate hard
> code for the case where that variable is a integer.  As long
> as there's some way to back down, at link time, to a more general
> but slower version, programs will still run.  If the test
> cases reflect normal use cases for the module, this should
> lead to generation of reasonable library module code cases.

The nice thing about this idea is that your type system is complient
with your test base. When a test succeeds it can not be invalidated by
a recorded type that gets annotated. You really get some metadata and
program description elements for free. There are also some caveats
about subtyping and using type information that is to special - or not
special enough. In the first case the maximal nominal type that
includes the recorded type as a subtype can be chosen that is
complient to the structural properties of the type i.e. the interface
description of the class accordingly. I have no idea about deeper
specialization. Guess this can't be handled automatically.

Methodologically this means that testing and important aspects of
optimizing Python code are not separated from each other. This is
elegant and will increase overall code quality and acceptance of the
language.

Ciao,
Kay