[Types-sig] RFC 0.1

[Christian Tismer]

Guido van Rossum wrote:
> 
> [Christian Tismer]

[about
  is [42]'s type "list", 
  "list with one element",
  "list with one even int"
]

> Good questions.  I'd like to remember all of this information.  It can
> help with optimization (through constant folding).  It can help detect
> unreachable code (e.g. your example function always returns a true
> value).  Etc., etc.

Fine, in general.

> Note that this can all be folded into a sufficiently rich type system;
> a type is nothing more than a (possibly infinite) set of values.

Yup, it's just open where to cut. I'd like to do compile time
checking, but to refine this at any time during the program
execution (sometimes maybe), and this needs some abstraction
to keep data limited.

> > At the same time, Python is so rich from self-inspection that
> > writing a dynamic type inference machine seems practicable,
> > so how about not declaring types, but asking your code about its
> > type?

Wrong wording of mine. I don't want to analyse bytecode, but
perhaps use AST info at some time. The initial compile time
AST is general but currently doesn't try deduction. It could
do so. But it could build derived AST's at runtime which know
much more. Well I'm still after the JIT idea, so just drop it,
I think this thread is for static types, which are a good thing!

> I suppose you could do symbolic execution on the bytecode, but I don't
> think this is a very fruitful path.  (Of course if anyone can prove
> I'm wrong, it's you. :-)

Will not try again soon, I'm tired. Proving you slightly not right
(wrong is too much) costs me half a year of work, finally a little
adjustment to truth helped. Changing truth is the easier way :-)

[interfaces and "dynamic" type inference]
> 

> Eh?  Type inference is supposed to be a compile-time thing.  You
> present your whole Python program to the typechecker and ask it "where
> could this crash if I sent it on rocket to Mars?"

I understand. I always think of importing which is already
execution of something, and then I miss the need to do it before.
Hmm, isn't it AST inspection, and after code is run, you get
a new AST instance which is richer?

...
> And that's exactly the problem.  I want to be able to be told whether
> the cache might be broken *before* I launch my rocket to Mars.

I see. The Houston traceback. You need to close the cache, and also
foresee that some module might want to break it and report a syntax
error *before*, which sounds hard.
A frozen module is a module which has proven its interface
and is protected against changes of necessary conditions.
That's indeed more than mine.

[more numb stuff of mine]

> Read my case study.

Did that. Great. I think I would use Greg's modified AST and do
the analysis there. An interpreter which runs these is also
not that hard and keeps more info than bytecodes. AFAIK this
is Skaller's approach for Viper.

You often said that you want to analyse code form the source,
instead of importing/executing stuff and use inspection. I
understand that. But analysis needs some simulation as well,
to see the effects of running some code. This simulation needs
an environment which can track effects of assignments, imports
and so on. Instead of re-inventing much stuff, why not use
Python inside of a restricted environment? A "virtual Python",
run in a real one, could execute steps, undo them, use other
control flow paths, record types(==sets of possible values),
all as long as there are no permanent side effects to the outside.
But the latter are to be avoided in either case, whatever
which approach you use.

Finally I think this is just another view of the same thing.

cheers - chris

-- 
Christian Tismer             :^)   <mailto:tismer@appliedbiometrics.com>
Applied Biometrics GmbH      :     Have a break! Take a ride on Python's
Kaiserin-Augusta-Allee 101   :    *Starship* http://starship.python.net
10553 Berlin                 :     PGP key -> http://wwwkeys.pgp.net
PGP Fingerprint       E182 71C7 1A9D 66E9 9D15  D3CC D4D7 93E2 1FAE F6DF
     we're tired of banana software - shipped green, ripens at home