[Types-sig] Issue: definition of "type"

[Greg Stein]

On Sun, 19 Dec 1999, Paul Prescod wrote:
> A "static type" is either a statically declared (top-level) class or
> something declared with a "decl type" statement or whatever we come up
> with. Jim Fulton and Max Skaller notwithstanding, we do not seem to be
> moving in the direction that any Python name can serve as a type. For

euh... I don't think so.

We should be able to do the following:

import types
Int = types.IntType
int = type(1)

def foo(x: Int) -> int:
  return x

I think the compiler/inferencer will understand the "types" module's
interface and will understand the type() builtin. There are probably a few
other ways to get type information (e.g. foo.__class__) that it also must
understand. But each of these mechanisms are quite traceable. For example,
as the inferencer is doing its type analysis, if a value has TypeType,
then it remembers the value, too. That value can then be used in the
future for type assertions.

In the above example, the inferencer sees that types.IntType is a TypeType
(with value <IntType>). As part of its normal effort, it records that Int
has a TypeType value. In this case, it also records that the value is
<IntType>. The inferencer also understands that type(1) returns <IntType>
and records the appropriate bits with "int".

> instance, these things are not types:
> 
> if somefunc():
> 	class spam:
> 		foo: String
> else:
> 	class spam:
> 		foo: int
> 
> spam is a class but not a static type.

I disagree. After the if/else statement, spam is effectively:

spam = typedef _internal_interface_spam1 or _internal_interface_spam2

i.e. the type inferencer simply understands that the typedecl "spam" is a
class with one of two interfaces.

> Jim Fulton also defines some ways to make interfaces at runtime. Those
> are also not "static types" for our purposes. An interface constructed
> at the top level would be a valid static type.

I agree: runtime constructions such as the JimF stuff are not static
types.

However, I disagree with JimF's mechanism for interface definition. I
believe our syntax changes are sufficient.
[ still need the associated functions such as implements() ]

Cheers,
-g

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