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

[skaller]

Greg Stein wrote:
> 
> On Tue, 28 Dec 1999, Paul Prescod wrote:
> > Greg Stein wrote:
> > > p.s. I'd recommend assignment enforcement over the notion of const; the
> > >      former seems to be more easily enforcable at runtime.
> >
> > I think we need both. We need to be able to enforce the TYPES of
> > assignments and we need to sometimes say that an object is not
> > modifiable, for all of the things we currently use tuples, files open
> > for read and other read-only objects for.
> 
> Um... Are you suggesting that we add a readonly flag to the list and dict
> types? Short of that, I'm not sure how you would do "const". IMO, adding a
> readonly flag to those types seems wrong.

'const', IMHO, in Paul's name based model, means the name
cannot be rebound:

	const x = 1 # x is always bound to 1

But:

	const x = []
	x.append(1) # fine, x is still bound to the same list

This does not require a readonly flag, it can be
enforced at compile time (in the absence of 'exec'
statements :-)

In some sense, this kind of const is a _stronger_
constraint that a type constraint:

	x: int = y

since any name which is not rebindable is necessarily
bound to the same object, and therefore has an invariant
type during its lifetime**: there is no need to give
the type for the purpose of checking assignments,
since any such asssignment is an error (because it
violates the no-rebinding requirement).

[** this is not true for raw objects in Viper,
where the type object can be dynamically changed ..
but that is another story :-]

-- 
John Skaller, mailto:skaller@maxtal.com.au
10/1 Toxteth Rd Glebe NSW 2037 Australia
homepage: http://www.maxtal.com.au/~skaller
voice: 61-2-9660-0850