[Types-sig] Progress

[Greg Stein]

On Wed, 15 Dec 1999, Paul Prescod wrote:
>...
> 1. Most people seem to agree with the idea that shadow files allow us a
> nice way to separate type assertions out so that their syntax can vary.
> I think Greg disagreed but perhaps not violently enough to argue about
> it. Interface files are in. Inline syntax is temporarily out. Syntactic
> "details" to be worked out.

I stated a preference for allowing this information to reside in the same
file as the implementation. i.e. I don't want to maintain two files.

I'll go further and state that we should not use a new language for this.
It should just be Python. (and this is where Martijn's __types__ thing
comes in, although I'm not advocating that format)

This should be equivalent to JimF's document (with extensions: I read it
and he does not define typedecl mechanims). Where we disagree, change, or
reinvent, then we provide feedback. Where we extend, we fold that back in.

>...
> 3. We agree that we need a syntax for asserting the types of expressions
> at runtime. Greg proposes ! but says he is flexible on the issue. The

Flexible on the character(s) used for the operator. That's a bit different
than flexibility on the issue :-)

> original RFC spelled this as:  has_type( foo, types.StringType ) which
> returns (in this case) a string or NULL. This strikes me as more
> flexible than ! because you can use it in an assertion but you don't
> have to. You can also use it like this:
> 
> j=has_type( foo, types.StringType ) or has_type( foo, types.ListType ):

You'll have issues with empty strings and empty lists, as Guido pointed
out.

has_type() does not create a *definitive* type assertion. The compiler
cannot extract any information from the presence of has_type(). Using an
operator which raises an exception allows the compiler to make the
assertion (and thereby assist with type inferencing and type checking).

>...
> writable modules are gone. (I have this vague feeling that maybe we
> should think of modules as classes with methods and properties that
> happen to be a subtype of a new base class "module", in that case the
> rules for modules and classes should be identical)

This is an interesting way to view the application of an interface to
either a module or a class. i.e. restate it as "apply interfaces to
classes only; modules become classes so they can have interfaces applied."

Note that this will also solve the setattr "problem" with modules.

> 5. It isn't clear WHAT we can specify in "PyDL" interface files. Clearly
> we can define function, class/interface and method interfaces.
> 
> 	a. do we allow declarations for the type of non-method instance
> variables?

Yes. My reluctance to specify types for instance variables is caused by
problems with designing a nice, inline syntax for it. If you're not
worrying about an inline syntax, then you can definitely add typedecls for
instance and class attributes.

Cheers,
-g

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