DO WANT is a block structure for undoing changes made within a block.
HAI CAN HAS STDIO? I HAS A CHEESE CHEESE IZ 1 HAI UP CHEESE!!10 DO WANT CHEESE > 12 VISIBLE "OH NOES! CHEESE 2 SMALL" DO NOT WANT VISIBLE CHEESE # => 1 KTHXBYE KTHXBYE
CHEESE is initially set to 1. When the DO WANT block opens, CHEESE is set to 11. The block then asks if CHEESE is greater than 12. Since it is not, the changes to the state made between HAI…DO WANT are undone, returning the variable to its previous value of 1.
From a programmer standpoint, this sort of construct is one that I've never really come into contact with, and one that I don't think I'd use… It would also pose a problem from an implementation standpoint, as you basically have to save the entire system state before you get into the HAI/DO block, and revert on a bad condition. I would propose that this could be modified into an exception-type situation, but then you still have to handle the clean-up yourself. The above would be better handled, in my opinion, with an if statement.
— Kyle, 2007/05/29 04:25
Conceptually, it would require saving and restoring state. In actuality, though, it wouldn't be implemented that way. In an interpreted language, a reasonable approach would be to keep a stack of “want block states”, which would be mappings of variable identifiers to values. (A compiled version would probably be able to use static analysis.) When the variable foo is set, if there is a current want block state, and it has no value for “foo”, the value for “foo” is set to the old value of foo.
For a purely functional language, this would be sufficient, and the want block stack could be local to the current function. However, when side effects are considered, it becomes more complex. Making the stat stack global would handle quite a lot of the issues (with new problems like identifying variables with scope), but things like IO would be problematic. Deferring it would complicate matters…
A broader question of interest, though, is whether to stick to traditional control structures, or look for novel ones.
— Ahruman, 2007/05/30 17:28
i propose a different usage of the DO WANT/DO NOT WANT syntax. it seems perfectly suitable for an expect language.
DO WANT "sername:" VISIBLE "diz" DO WANT "assword:" VISIBLE "somepassword" DO NOT WANT "ogin failed" DIAF "OH NOES"
the NOT keyword does't seem to add much… perhaps the syntax can be twiddled with a bit to make it better fit the paradigm. comments?
— diz, 2007/05/31 11:09:55 CDT