[Types-sig] Basic questions

[Greg Stein]

On Mon, 20 Dec 1999, Paul Prescod wrote:
>...
> 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.

Euh... why does it have to be explained? Why do Python programmers care
what the types are? They know.

The inferencer is just figuring out what the programmer did. The
programmer doesn't have to understand it to produce valid programs.

John responded to this in a different email listing the kinds of
mismatches between the programmer's intent and the inferencer's
deductions. He explains the situation well...

>...
> This is a class/static type definition:
> 
> class a: pass

Yes.

> This is not:
> 
> if 1:
> 	class a: pass

I disagree. This does create an implicit typedecl which can be used. In
addition the class name "a" can be used.

Caveat:
   typedef a == typedef <some-interface> or Undefined

Specifically, the compiler may warn the programmer that "a" could possibly
be undefined.
[ because I really don't think we want to do constant evaluation in the
  inferencer. although if somebody does... cool! it could then removed the
  Undefined alternative. ]

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

Agreed.

> 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 disagree again :-), for the same reasons as the class.

> I'm trying to keep thing simple.

An approach that I heartily agree with!

However, I'd rather make it simple for the Python programmer: define it
wherever you want, in whatever style you're using -- we won't force you to
use a particular style.

In other words, I think the rule of "it must be at the top-level, by which
I mean yah.. at the globals level, but not inside an 'if' statement. oh,
or inside a 'for' statement or a 'while' statement, for that matter. hrm.
imports might enter into this somehow, too... lemme think..."

I say just let them do what they want. I believe we can figure it out.

Cheers,
-g

-- 
Greg Stein, http://www.lyra.org/