[Types-sig] Issue: binding assertions

[Paul Prescod]

Greg Stein wrote:
> 
> ...
> You cannot know the type of <a> because you did not add a type declaration
> to the parameter. 

Yes, I meant to do so.

> 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
not, doesn't the type declaration become meaningless documentation?

And if you support enforcing type declarations during assignments, do
you support doing so for assignments to:

 a) instance variables
 b) module variables
 c) local variables
 d) parameters

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

> 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
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.

> 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.

-- 
 Paul Prescod  - ISOGEN Consulting Engineer speaking for himself
Three things see no end: A loop with exit code done wrong
A semaphore untested, and the change that comes along
http://www.geezjan.org/humor/computers/threes.html