Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!wuarchive!udel!haven!ni.umd.edu!uc780.umd.edu!cs450a03 From: cs450a03@uc780.umd.edu Newsgroups: comp.lang.misc Subject: RE: Dynamic typing (part 3) Message-ID: <29MAR91.18143482@uc780.umd.edu> Date: 29 Mar 91 18:14:34 GMT References: <815@optima.cs.arizona.edu> <20MAR91.08580313@uc780.umd.edu> <21MAR91.23594992@uc780.umd.edu> <22MAR91.20485982@uc780.umd.edu> <039AIL3@xds13.ferranti.com> Me >> >> (2) I generally don't need to make state machines. ... >> Another thing is that usually, I'll want a history of the machine, so >> each state is stored in a separate location. ... > >Hmmm. looks like we're dealing with radically different problem spaces. >You deal with problems where it's desirable and possible to avoid information >loss. I have to deal with that entropy and give up reversibility to allow >unlimited runtime with limited memory storage. This is particularly important >in interactive programs. Hmmm... but my programs are interactive. Example from last week: I wrote a little "diff" style routine to compare two articles. It was implemented as a state machine -- the state history indicated the simplest way to change from program a to program b. I needed to keep this in memory because once I've got how many lines are changed in old and new I give the person the option of displaying only the sort of information that looks interesting (e.g. if article A is intended to replace 3 pages of article B (which is 50 pages) you can extract the exact lines in article A that changes from article B--maybe only a couple words in this application). [my example of dynamic array allocation elided] >It may not be significantly slower, but it uses up significantly more >memory. If list is large enought that can easily make the difference between >being able to run the program and not. > >Also, I tend to work through dynamically allocated lists, or even lists >that are implicitly defined. In that case "max" is unknown and potentially >unbounded. Um, yes.. You have to be careful to break up large problems into manageable chunks. In exchange for that, exception handling becomes simpler (er... assuming a few key operations are atomic). Remember, though, that I'm not working in C. "max" for a dynamic array is implicitly defined, and potentially unbounded, but known. Programming style is a bit different than with lists too. Again, if the problem is too big to be handled as a single piece, you break it up into pieces, and maintain a directory to keep track of the pieces. (Er.. don't confuse the general concept of a directory with specific implementations of a os). > while(msg = GetMsg(port)) > { switch(msg->request) { ... case FOO: state = BAR; } Reply(msg); } >I don't care how GetMsg is implemented, or Reply, but I do need to assume >that there is no limit on the number of times this loop will be run through. >This means I *have* to discard old state information. Er... I didn't mean to say that I never discard state information. I meant to say that I am very careful, when I do so, to make sure that my code will behave properly during exceptions. This may be more important to me than to you, because during debugging it is likely I'll execute code sections multiple times--stopping at a bug, fixing it, then back tracking a short distance and restarting. On the descriptive comments/code thing, consider a language that does not define a comment syntax, but allows you to include constant data wherever syntatically convenient. Then you could put strings in as comments. What the language does with those strings is up to you. (You the programmer, not you the hypothesizer.) Raul Rockwell