Chris Smith wrote:
> // Inside this block, a has type int{17..21} and b has type
> // int{18..22}
No what happens if right here you code
b := 16;
Does that again change the type of "b"? Or is that an illegal
instruction, because "b" has the "local type" of (18..22)?
> signContract(a); // error, because a might be 17
> signContract(b); // no error, because even though the declared
> // type of b is int{14..22}, it has a local
> // type of int{18..22}.
If the former (i.e., if reassigning to "b" changes the "static type" of
b, then the term you're looking for is not type, but "typestate".
In other words, this is the same sort of test that disallows using an
unassigned variable in a value-returning expression. When
{ int a; int b; b := a; }
returns a compile-time error because "a" is uninitialized at the
assignment, that's not the "type" of a, but the typestate. Just FYI.
> Incidentally, I'm not saying that such a feature would be a good idea.
It actually works quite well if the language takes advantage of it
consistantly and allows you to designate your expected typestates and such.
--
Darren New / San Diego, CA, USA (PST)
This octopus isn't tasty. Too many
tentacles, not enough chops.
--
http://mail.python.org/mailman/listinfo/python-list
