jashley@silver.ucs.indiana.edu (J. Michael Ashley) (07/24/90)
Joe Keane@osc.com writes: > The whole idea of being lazy is that you do as little work as possible. Hmm. That's only partly it. "Being lazy," as I understand it, means normal order reduction coupled with full sharing (no expression gets reduced twice). > The > constraint is that that you can't change the return values or side effects of > an expression. Not being able to side-effect has nothing to do with "being lazy." It's just part of the semantics of functional languages. > One thing that you are allowed to do is change bottom into > some valid value, as long as you're consistent. I won't explain this, except > to point out that a program which gets stuck can't contradict one that does > something useful. Please explain this. I view bottom from a semantics perspective, and what you are saying doesn't make much sense to me, but maybe clarification will help. > Now suppose we're in a language with real exception handling. It's only a > matter of terminology whether you count an exception as a kind of return > value, a side effect, or something different. You are definitely wrong. An exception is an explicit manipulation of the program's current continuation. In particular, an exception is nothing more than throwing out the current continuation and replacing it with some other continuation. An exception is a very well-defined notion in terms of denotational semantics. An exeption is a side effect. You're playing with the state of the program. That's why exception handlers and most every other kind of control structure is a no-no in functional languages. I don't like this, and it's why I will never enjoy functional languages, but that's the nature of the beast, and you have to live with it. If you *do* want an exception handler, then go look at ML (or maybe SML). Bruce Duba worked with Chris Haynes at Indiana University on typing call/cc, which is a construct that hands the programmer the current continuation as a first-class function. He went on and is working for whoever does ML and has implemented it in the language. It's now in the standard. > Given the constraint above, the > implementation must examine the expression far enough to determine whether it > will raise an exception. This is exactly what you'd expect. If it doesn't, > it's broken. I'd like to know why it's the implementation's responsibility to detect semantic errors. I think that is a hard thing to do and is why no other langauge implementations do it. For example, should the "implementation" catch this C semantic error? int *p; p = NULL; *p = 10; > In summary, i think exception handling is an important part of any language. I agree here. There's plenty of cases where you have built up a magnificently large continuation and either want to throw it all away and return an error or else save it for later and do something else right now. That's why first-class continuations are so great. > In particular, defining errors to be the same as bottom is an unwise thing to > do. Then how do we, as programmers, interpret bottom? Maybe it I know nothing about it and my friend knows a little more about it and his friend knows still a little more... :-) mike ashley jashley@lanl.gov "Faul oder nicht faul, das is hier die Frage!"
rwh@PROOF.ERGO.CS.CMU.EDU (Robert Harper) (07/25/90)
jashley@silver.ucs.indiana.edu (J. Michael Ashley) writes: ... >An exeption is a side effect. You're playing with the state of the program. >That's why exception handlers and most every other kind of control structure >is a no-no in functional languages. I don't like this, and it's why I will >never enjoy functional languages, but that's the nature of the beast, and >you have to live with it. ML's approach to exceptions can be arguably considered as related to "side effects" (due to the dynamic binding of handlers), but it is by no means the case that control flow constructs are a "no-no" in FL's. FL's, like any other languages, have an operational semantics describing the order of evaluation, and it is perfectly sensible to consider constructs for altering the normal order (so to speak). Lazy languages have problems in this area for practical, not theoretical reasons: under CBN it is difficult to predict when a phrase will be evaluated, or whether it will be evaluated more than once (this is connected with the "full laziness" issue.) >If you *do* want an exception handler, then go look at ML (or maybe SML). >Bruce Duba worked with Chris Haynes at Indiana University on typing call/cc, >which is a construct that hands the programmer the current continuation as >a first-class function. He went on and is working for whoever does ML and >has implemented it in the language. It's now in the standard. I can't comment authoritatively on the history of the work, but it should be mentioned that Bruce worked with Andrew Appel and Dave MacQueen on the addition of call/cc to SML. It should also be mentioned that callcc is by no means a part of the standard. In fact, my own investigations indicate that to do so would involve a considerable re-working of the dynamic semantics. >I agree here. There's plenty of cases where you have built up a >magnificently large continuation and either want to throw it all away and >return an error or else save it for later and do something else right now. >That's why first-class continuations are so great. Just as are goto's in imperative languages. Robert Harper School of Computer Science Carnegie Mellon University Pittsburgh, PA 15213-3890 USA ArpaNet: rwh@cs.cmu.edu Telephone: +1 412 268 3675
duba@aten.rice.edu (Bruce Duba) (07/25/90)
>jashley@silver.ucs.indiana.edu (J. Michael Ashley) writes: >... >Bruce Duba worked with Chris Haynes at Indiana University on typing call/cc, >.... He went on and is working for whoever does ML and >has implemented it in the language. I worked with Andrew Appel (Princeton) and Dave MacQueen (ATT) on putting call/cc into Standard ML of New Jersey. A report on this EXTENSION of Standrad ML will appear shortly (jointly with Bob Harper and Dave). -- Bruce Duba
nick@lfcs.ed.ac.uk (Nick Rothwell) (07/25/90)
In article <51915@iuvax.cs.indiana.edu>, jashley@silver (J. Michael Ashley) writes: >If you *do* want an exception handler, then go look at ML (or maybe SML). >Bruce Duba worked with Chris Haynes at Indiana University on typing call/cc, >which is a construct that hands the programmer the current continuation as >a first-class function. He went on and is working for whoever does ML ML is "done" my several people all over the world. The New Jersey ML compiler was "done" by MacQueen at AT&T, Appel at Princeton, and others. >and >has implemented it in the language. It's now in the standard. * W R O N G ! * Read the Standard (published by MIT) and tell me where you see it. Callcc is not part of Standard ML. It's an extension implemented by the New Jersey ML implementors, as is the separate compilation scheme implemented by us, the exception continuation handling scheme implemented by Reppy, and so on. >mike ashley Nick. -- Nick Rothwell, Laboratory for Foundations of Computer Science, Edinburgh. nick@lfcs.ed.ac.uk <Atlantic Ocean>!mcsun!ukc!lfcs!nick ~ ~~ ~~ ~~ ~~ Hey, son, get that DeLorean off the track! And ~~ ~~ ~~ ~~ ~ what have you done with all my lovely harpsichords?
jashley@silver.ucs.indiana.edu (J. Michael Ashley) (07/25/90)
In article <5303@castle.ed.ac.uk> nick@lfcs.ed.ac.uk (Nick Rothwell) writes: >In article <51915@iuvax.cs.indiana.edu>, jashley@silver (J. Michael Ashley) writes: >>has implemented it in the language. It's now in the standard. >* W R O N G ! * >Read the Standard (published by MIT) and tell me where you see it. Sorry about that. My facts were second hand. Didn't mean to light the fireworks! :-) >Callcc is not part of Standard ML. I guess I was being too optimistic. >It's an extension implemented by >the New Jersey ML implementors, as is the separate compilation scheme >implemented by us, the exception continuation handling scheme >implemented by Reppy, and so on. Thanks everybody for settin' me straight. mike ashley jashley@lanl.gov