Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!sdd.hp.com!news.cs.indiana.edu!att!ucbvax!bloom-beacon!dont-send-mail-to-path-lines From: mkatz@garlic.stanford.EDU (Morris Katz) Newsgroups: comp.lang.scheme Subject: Fixing the order of evaluation. Minimizing the unexpected. Message-ID: <9104051728.AA04773@garlic.Stanford.EDU> Date: 5 Apr 91 17:28:56 GMT References: <1991Apr5.021422.12385@rice.edu> Sender: daemon@athena.mit.edu (Mr Background) Organization: The Internet Lines: 67 Date: 5 Apr 91 02:14:22 GMT From: Matthias Felleisen Organization: Rice University, Houston In article <9104041629.AA19876@schizo> gjc@mitech.com writes: >Odd numbered arguments right to left and even ones left to right? >Of course that was proposed as just about the most stupid thing that >anybody could think of. (What if somebody said, *yes*?) No, let's say yes. I'd rather have some order than none! >Face it. People understand the written word, and written directions >are given to people in this format: LEFT-TO-RIGHT, TOP-TO-BOTTOM. I am so happy to see that somebody finally said this: that's the way it should be, and yes, PERIOD. Left-to-right is how we READ. And then we PARSE. And then we UNDERSTAND. If we can't even read, how are we going to understand? People want a simple mental model of program execution because that's the basis for programming. Unordered evaluation of application expressions is a major obstacle to a simple model. Ask students who learn to program in PURE SCHEME (the functional subset). They assume left-to-right and hand/head-simulate execution that way. When they get an error message or the program gets into an infinite loop, they look for sources of errors and loops in that fashion. Worst of all, we always claim that (PURE) Scheme is a deterministic language. But given that a compiler can choose an arbitrary order of evaluation for every application expression during every compilation, the "same" Pure Scheme program may never reproduce the same error or infinite-loop behavior. Don't bother to argue that errors or infinite loops are not proper behavior because if you ever programmed, you know it's not true. Whatever the benefits of an unspecified order of evaluation for compiler writers are, the costs are too high a price to pay. We all program with some mental model of program execution, and unorderedness and potential non-determinism for something as simple as PURE SCHEME is too weird. Scheme is about having-fun-with-programming, not about fun-for-compiler-writers. Let's fix the order of evaluation! GO LEFT-TO-RIGHT! :-) -- Matthias It seems to me that the logical extension of your argument is that we should return to pure scheme by removing all of the imperative constructs from Scheme since their value does not offset the loss of referential transparency. Please explain what differentiates these two arguments. I have yet to hear from your side a real cost/benefit analysis. What I have heard is that you (collectively) do not have a good feel for the benefits of unspecified order of evaluation and see a cost to it, so it should go. This is not a cost/benefit analysis. I personally see some real benefits to unordered evaluation order, an have not found the costs to students nearly as extreme as you seem to have. As some of you may know, my current research involves automatic parallelization of scheme through optimistic concurrency plus rollback. The ability to choose the effective order of evaluation of arguments at runtime can greatly reduce the amount of rollback required in a system like mine and thereby markedly improve performance. Here is a REAL benefit. I would like to see serious programs people desire to write that a seriously hampered by unspecified order of evaluation so I can better appreciate that category of costs. I have no idea how to get a handle on the cognitive dissonance problem your students have experienced as I have not seen it in practice. -------------------- Morry Katz katz@cs.stanford.edu --------------------