Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!usc!snorkelwacker.mit.edu!bloom-beacon!dont-send-mail-to-path-lines From: cph@altdorf.ai.mit.EDU (Chris Hanson) Newsgroups: comp.lang.scheme Subject: open-input-file [topics from hell, part 2] Message-ID: <9104270655.aa29839@mc.lcs.mit.edu> Date: 27 Apr 91 10:52:07 GMT References: <5405@goanna.cs.rmit.oz.au> Sender: daemon@athena.mit.edu (Mr Background) Organization: The Internet Lines: 62 Date: 26 Apr 91 05:01:29 GMT From: "Richard A. O'Keefe" But this begins to sound like the Common Lisp condition system. I understand that Common Lisp bashing is a popular sport in the Scheme community, and I often gladly participate in it, but in this case I think it is misdirected. Once a great deal of CL "style" is stripped away, the underlying mechanism of the condition system is exceptionally simple, even elegant, and in my opinion should be seriously considered as a solution to this problem. Basically, the condition system consists of typed records (condition) whose types are a taxonomy of errors, plus named continuations (restarts) and a means of dynamically binding restarts and condition handlers. There is a little more to it than that, but really not very much. Anyone who thinks the condition system is hairy and complicated should study it more carefully, particularly ignoring all the macros, keywords, overloading, and other things that make it Common Lispish. I'm not going to argue why the CL condition system is a good solution -- I think that KMP's text in CLtL2 does that well -- but I will say that the idea of returning error objects rather than signalling them is a bad one. On the face of it, signalling seems more complicated, because it involves dynamic binding and non-local effects. But a closer examination of the problem reveals that it is a simpler solution. Let's look at the file-opening example to see why. The discussion so far has centered on what happens when the programmer is opening a file and has some particular idea of how to recover if the open fails. In my experience, this is the exception rather than the rule, so in effect this means that most file-opening code will have to detect this error and signal it "by hand", where currently the error is signalled "automatically". This is the first problem: returning an error object simplifies the unusual case at the expense of the common one. Another assumption is that the code that opens the file is a natural place to detect and handle the error. Again, in my experience, this isn't the case. Usually, the call to OPEN-{IN,OUT}PUT-FILE is not in the same place as the handler. When it isn't, returning an error object requires that all the intermediate code must know about the possibility for errors, and suitably pass the error object along to the caller. Often this "passing along" will affect the control structure of the program, imposing otherwise unnecessary constraints. This is the second problem: lots of code that isn't interested in the error must now become aware of it. In both of the cases that cause these problems, the approach of signalling errors and catching those errors with dynamically bound handlers is simpler. Despite the seeming "non-local" nature of this solution, in fact it is MORE "local", because only the code that cares to handle the error needs to know anything about it. All the other code can ignore the error entirely. The last problem with the "returning errors" proposal is that it is inconsistent with existing practice. Adopting such a solution would force everyone to rewrite their code, and Scheme implementations that supported it would not comply with the IEEE standard. In contrast, a CL-like condition system can be added without changing any code, and is totally compatible with the standard.