[Types-sig] Issue: binding assertions

[Greg Stein]

On Sun, 19 Dec 1999, Paul Prescod wrote:
> Greg Stein wrote:
>...
> > What I believe is a distinct issue: while the interface specification of
> > Foo tells you what a.spam *is*, I believe we have a separate problem of
> > deciding whether to *enforce* that. While I am not strictly opposed to
> > enforcing type safety during assignment, I would ask that you please list
> > this as two problems: 1) declaring an interface, 2) enforcing type-safety
> > during assignments.
> 
> That's fine. Do you support enforcing type safety during assignments? If

Generally, I don't support it in V1. I think the assignments are usually
being done near to their definition, and only by the original author. In
that sense, I think there won't be too many errors in type-incorrectness.

In V2, then sure. But I want to separate the issue and discuss it later.
We can implement a system without worrying about assignments.

Small bites!

> not, doesn't the type declaration become meaningless documentation?

Absolutely not. In the following:

class Foo:
  decl member bar: Int

Anytime that the type-checker/inferencer refers to Foo_instance.bar, it
knows what the type is. Very important.

> And if you support enforcing type declarations during assignments, do
> you support doing so for assignments to:
> 
>  a) instance variables
>  b) module variables

The above two are part of assigning values to an interface's attributes.
In the future: sure, enforcement would make sense.

>  c) local variables

I don't think we should even be declaring these, thus rendering
type-enforcement moot.

>  d) parameters

Unsure. I'm punting my thoughts to V2.

[ V2 meaning Type System V2, not Python 2.0 ... I don't even think Python
  2.0 should be mentioned in our discussions... ]

> If you could summarize your proposed syntax/semantics for the four types
> of assertions in a small chart, that would help a lot.

-- No enforcement at all for any assignment.
-- All references use the declared type info (if any) for purposes of type
   checking

> > I believe that if we add syntax to declare locals, then we are going to
> > have a real hard time getting rid of that syntax. 
> 
> The syntax to declare locals would be the same syntax used to declare
> globals and instance variables. It would just be in the function

I disagree. The latter two are part of an interface declaration (of a
module or a class instance). Locals are not part of an interface, so I
don't think they fall into the same category at all.

decl member a: Int

That is an incorrect semantic for locals. And I don't support adding a
"decl var" or "decl local" for local declaration.

IMO, of course :-)

> context. Anyhow, I wasn't saying that we would ever get rid of the
> syntax. We could just allow variables so declared to vary across their
> lifetime.

My comment about getting rid of the syntax was based on the assumption
that we *might* have local declarations until the inferencer is
up-to-snuff. At that point, local declarations would be redundant. Problem
is: the interim code that used the new syntax would break once we tried to
remove that interim syntax.

> > I don't want to add syntax and
> > the resulting non-cleanliness to deal with people who do the following:
> > 
> > def foo():
> >   decl local c: Int
> >   c = "foo"
> 
> Neither do I. But I also do not want to illogically restrict the syntax
> that is used in the module context, and class context from being
> available in the local context. I also do not want parameter
> declarations to have a very different semantic from instance variable
> declarations.

I think the module/class context declarations are the same: interface
member declarations.

Parameters, locals, and return values have a different semantic
altogether. Therefore, I don't see any illogic to keeping the syntax
separate. I don't want to worry about enforcement, but I do want to worry
about declaring parameters and return values so that we can properly
infer/deduce the types of all expressions within a function.

Cheers,
-g

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