[Types-sig] Progress

[Martijn Faassen]

Paul Prescod wrote:
> 
> We are actually making progress among all of the sound and fury here.
> You guys have a lot of good ideas and I think that we are converging
> more than it seems.
> 
> 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.

Actually I can see the arguments for including type annotations in the
module files themselves as there's something to say for keeping it
together. As long as the syntax isn't inline in our first design I'm
fine. See the syntax example I just posted to the list.

> 2. Everybody but me is comfortable with defining
> genericity/templating/parameterization only for built-in types for now.

What do you mean by 'built-in types'? Does this include classes?

> But now that we are separating interfaces from implementations I am
> thinking that I may be able to think more clearly about
> parameterizability. It may be possible to define parameterizable
> interfaces by IPC8. Parameterization is in. Syntactic "details" to be
> worked out.

See my syntax response to Guido's challenge for my take on things.

> 3. We agree that we need a syntax for asserting the types of expressions
> at runtime. 

I'm not sure I do agree with this. It's an intruiging concept but I'm
still
not convinced we shouldn't go with annotating names instead. This may be
easier to think about for the programmer, see an earlier response of
mine to the list for an example.

[snip]
 
> 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, eventually at least. We could focus on functions first, but I think
supporting classes will become necessary very quickly.

>         b. do we check assignments to class and module attributes from other
> modules at runtime? We need to expect that some cross-module assignments
> will come from modules that are not statically type checked.

You can manually add extra annotations for the names you use from other
modules  that those other modules don't annotate; see my syntax
proposal.
 
>         c. should we perhaps just disallow writing to "declared" attributes
> from other modules?

Hm, yes, this could become complicated, even for run-time checks. We
should come up with somekind of rule. run-time checks can help, but we
need to figure out when they're necessary, and when they aren't; i.e if
you write to a declared attribute from a module with something that
doesn't have a compile-time type associated, a run time check should
occur. But otherwise, it shouldn't.

>         d. is it possible to write to UN-declared attributes from other
> modules? And what are the type safety implications of doing so?

This would generally be fine; undeclared attributes can contain objects
of any type, right? What will be tricky (and which is why I'm clamoring
for full type annotations and other strictness, at least initially) is
*reading* from these..

Regards,

Martijn