Darren New <[EMAIL PROTECTED]> wrote: > 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)?
It arranges that the expression "b" after that line (barring further changes) has type int{16..16}, which would make the later call to signContract illegal. > 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". We're back into discussion terminology, then. How fun. Yes, the word "typestate" is used to describe this in a good bit of literature. Nevertheless, a good number of authors -- including all of them that I'm aware of in programming language type theory -- would agree that "type" is a perfectly fine word. When I said b has a type of int{18..22}, I meant that the type that will be inferred for the expression "b" when it occurs inside this block as an rvalue will be int{18..22}. The type of the variable didn't change, because variables don't *have* types. Expressions (or, depending on your terminology preference, terms) have types. An expression "b" that occurs after your assignment is a different expression from the one that occurs before your assignment, so it's entirely expected that in the general case, it may have a different type. It's also the case (and I didn't really acknowledge this before) that the expression "b" when used as an lvalue has a different type, which is determined according to different rules. As such, the assignment to b was not at all influenced by the new type that was arranged for the expression "b" as an rvalue. (I'm using lvalue and rvalue intuitively; in practice, these would be assigned on a case-by-case basis along the lines of actual operators or language syntax.) > In other words, this is the same sort of test that disallows using an > unassigned variable in a value-returning expression. Yes, it is. > 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. If you wish to say "typestate" to mean this, be my guest. It is also correct to say "type". > It actually works quite well if the language takes advantage of it > consistantly and allows you to designate your expected typestates and such. I'm not aware of a widely used language that implements stuff like this. Are you? -- Chris Smith - Lead Software Developer / Technical Trainer MindIQ Corporation -- http://mail.python.org/mailman/listinfo/python-list