[Types-sig] const (was: PyDL RFC 0.02)

[Paul Prescod]

skaller wrote:
> 
>         Hang on! removing 'const' is not the same as
> adding a restriction preventing certain name rebindings --
> as Guido pointed out in response to one of my posts,
> it is possible to detect many rebindings, and it is possible
> to ban some -- without needing a 'const' specification.

I don't follow you and anyhow I don't see why banning some name
rebindings needs to be high on our list of things to do. The
optimization and safety benefits are not as high as those of ordinary
type checking.

> > For now, we just need a solid definition of what types of rebinding are
> > legal. There are four kinds of names:
> 
>         No. There is only one kind of name.
> Perhaps you mean 'a name can be bound to one of four kinds of  object'?

Yes and no. We are now able to associate types with names so we need to
be cognizant of both the type of the name and the type of the object.

> >  * module -- we must always disallow rebinding these because we don't
> > have a notion of two modules with the "same interface". Maybe in some
> > future version we could.
> 
>         I'm not so sure. Consider:
> 
>         import m
>         module_x  = m.x
>         module_x = m.y
> 
> Here, 'module_x' is a name bound to a module, namely m.x,
> which is rebound to another module, m.y. Module objects
> can be accessed just like any other python object.
> 
> And in this case, you may not even KNOW that 'module_x'
> is bound to a module object.
> 
> I'm thinking that your intent is that the name 'module_x'
> be declared as a module (with some properties), but then ..
> 
> >  * class -- rebinding is fine as long as the new class has a signuture
> > that will produce instances that conform to the declared interface(s).
> 
>         .. should be the same as for modules. Rebinding
> is allowed, provided the constraints implied by a declaration
> the name conforms to a particular interface are met.

My point was that we need to treat modules differently than classes
because two modules cannot export the same interface whereas two classes
can.

interface Foo:
	decl bar: def( int ) -> int

decl foo1: def( ) -> Foo
decl foo2: def( ) -> Foo

class foo1:
	__impements__=[Foo]
	def bar( num ): return 5

class foo2:
	__impements__=[Foo]
	def bar( num ): return 6

foo1 = foo2 # okay

There is no equivalent code for modules because module interfaces are
not named and modules do not claim to conform to particular interfaces.

>         BUT: the is an important reason to do more,
> namely, caching of module functions and class methods.
> In this case, merely requiring interface conformance
> is not enough:

I cannot see that there is much to be gained in caching class methods.
The vast majority of time you will be handed an *instance* of the class
and you will look up the method at runtime using vtables or whatever.

 Paul Prescod