Xref: utzoo comp.object:2364 comp.lang.functional:555 Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!wuarchive!rex!samsung!noose.ecn.purdue.edu!mentor.cc.purdue.edu!purdue!haven!adm!cmcl2!kramden.acf.nyu.edu!brnstnd From: brnstnd@kramden.acf.nyu.edu (Dan Bernstein) Newsgroups: comp.object,comp.lang.functional Subject: Re: Global program state. Message-ID: <2214:Jan320:23:5791@kramden.acf.nyu.edu> Date: 3 Jan 91 20:23:57 GMT References: <27823155.211e@petunia.CalPoly.EDU> <27109:Jan301:33:4391@kramden.acf.nyu.edu> Organization: IR Lines: 22 Ever feel like you couldn't see the bugs for the program? The more program state/variables/definitions/procedures visible from one code segment, the easier it becomes for bugs to hide in that segment. That's the real reason that each segment should be as localized as possible. It's not for ``mathematical appropriateness'' or for proving that correct programs are, indeed, correct; it's for improving your chances of detecting the bugs in buggy programs. In article burley@pogo.ai.mit.edu (Craig Burley) writes: > think of global state as one huge object Nice. > Dan, does your Q language (or your formal definition) use this technique, or > something similar, to deal with the global state you use in its definition? The language per se has very little to do with the formal definition; I'm writing the latter mostly to make sure I know what I mean by the semantics of the former. Q doesn't give the programmer any way to refer to the entire program state. ---Dan