Wed, 29 Sep 2010 09:21:11 +0200, Norbert Nemec wrote: > IMHO, the test misses the point of compile-time metaprogramming: The > concept of "state" belongs to run-time. The D compile-time language is > purely functional and does not know a state or even an "order of > execution". > > The conditions "cannot die or be eaten twice" are, at their core, issues > of state. Any "solutions" that claim to catch one of the last three > errors must either go beyond the purely functional nature of the > compile-time language or rely on additional constraints (e.g. no reuse > of previous elements) > > Of course, one could devise a language with non-functional compile time > features, but within D, this would fundamentally break the existing > concept of meta-programming.
I only read the abstract of one typestate paper, but I think this is what they are all about - associating a (compile time) mutable state with the type. (No need to correct me, I've soon read more about the issue.) I experimented with this (a colleague of mine already solved all 11 cases at compile time with Scala) a bit and noticed that conditions like "has already been eaten" cannot be expressed without purely functional state passing via monads or explicitly (uniqueness types catch potential errors here). Why? The operation 'eat' has to change the state and states can only be verified on type level at compile time. Another way to solve this would be typestates.
