[Types-sig] Basic questions

[Paul Prescod]

Martijn Faassen wrote:
> 
> 
> ... I wonder if in practice this will mean
> people will start to assign types to *everything* to make it work well
> (or efficient) with types at all. If so then we need to somehow avoid
> this.

This is why I think that "make everything explicit" is too strong of a
rule in practice. I want type-checked code and untype-checked code to
work together more or less seamlessly. On the other hand, I don't want
to get into complicated data flow analysis. Even if someone implemented
it, how would we explain it to Python programmers? "In order to
understand what types your program is producing, follow this complicated
algorithm." That's why we are running away from strict
(non-conservative) type inferencing in the first place.

I think that the middle ground is more or less what I proposed last
week.

This is a class/static type definition:

class a: pass

This is not:

if 1:
	class a: pass

This is a function declaration where the function's type (Any->Any) is
known at compile time:

def a( b ): return "foo"

This is not a static function declaration and cannot be used from static
code without a type assertion:

if 1:
	def a( b ): return "foo"

I'm trying to keep thing simple.


-- 
 Paul Prescod  - ISOGEN Consulting Engineer speaking for himself
The occasional act of disrespect for the American flag creates but a 
flickering insult to the values of democracy -- unless it provokes 
America into limiting the freedoms that are its hallmark.
           -- Paul Tash, executive editor of the St. Petersburg Times