Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!think.com!snorkelwacker.mit.edu!ai-lab!zurich.ai.mit.edu!markf From: markf@zurich.ai.mit.edu (Mark Friedman) Newsgroups: comp.lang.scheme Subject: Re: open-input-file [topics from hell, part 2] Message-ID: Date: 29 Apr 91 16:07:34 GMT References: <5405@goanna.cs.rmit.oz.au> <9104270655.aa29839@mc.lcs.mit.edu> Sender: news@ai.mit.edu Reply-To: markf@zurich.ai.mit.edu Organization: M.I.T. Artificial Intelligence Lab. Lines: 60 In-reply-to: harlan@copper.ucs.indiana.edu's message of 27 Apr 91 18:15:28 GMT In article harlan@copper.ucs.indiana.edu (Pete Harlan) writes: cph@altdorf.ai.mit.EDU (Chris Hanson) writes: [stuff in favor of a Common Lisp style condition system] Returning an error is conceptually simpler, I think. I don't agree. As Kent Pitman points out in CLTL2 we would like to think of procedures as accepting certain sets of valid arguments. When procedures return error objects, we sort of throw away this notion because you're returning a value for all arguments. I prefer the current situation of being able to say that a certain procedure accepts arguments of a certain sort and signals an error if the arguments are not valid. As Chris said, we can build a condition system consistant with this. You are then free to handle the conditions as you see fit (e.g. return some special error object). Returning an error may be easier to implement and perhaps easier for a naive user to understand, but conceptually it is not simpler. In fact I think that it is paradoxical to say that a procedure return an error. I'd personally like to see the routine take a success and failure continuation, but the world seems to not want primitive Scheme procedures to take continuations. But just about any procedure may have an error. Do you propose that they all have explicit success and failure continuations. And what about Alan Bawden's point about all the different types of errors. Even if you don't accept that a single primitive procedure doesn't have different types of errors, a single user defined procedure should be able to handle the union of the errors of all the procedures it calls. Should procedures have failure continuations for all those errors. A top-level procedure for any interesting program would have a zillion (at least) failure continuations. In general, dynamically scoped variables are used to avoid this problem of passing along arguments by procedures which aren't really interested in them. Dynamically scoped condition handlers do the same thing for failure continuations. In any case, it is easy enough to roll your own nonlocal exiting mechanism on file failures if you want. You could equally easy to implement the error-returning system on top of the system-enforced nonlocal exit system, if that system gave the handler the continuation to get back to the point of the file call, but the error-returning system is simpler. As I argued above, I think that you should start with the condition system and build the error-returning system on top of that. -Mark -- Mark Friedman MIT Artificial Intelligence Lab 545 Technology Sq. Cambridge, Ma. 02139 markf@zurich.ai.mit.edu