Re: Just for your fun and horror
On 16-Feb-2001 Matthias Felleisen wrote:
Because imperative languages have named one half of the denotation (the value return) and not all of it for a long long long time. It's too late for Haskell to change that. -- Matthias
Well now, if I am to understand what a return statement in C does, I must realize not only that it may return a value to a calling routine, but also that it preserves the store. If it allowed the store to vanish, it wouldn't be very useful, would it? So I don't see how it's reasonable to assert that "return" means only one of these two things to a C programmer. Cheers, --Joe Joseph H. Fasel, Ph.D. email: jhf@lanl.gov Technology Modeling and Analysis phone: +1 505 667 7158 University of California fax: +1 505 667 2960 Los Alamos National Laboratory post: TSA-7 MS F609; Los Alamos, NM 87545
From: jhf@lanl.gov X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Date: Fri, 16 Feb 2001 16:53:13 -0700 (MST) Organization: Los Alamos National Laboratory Cc: karczma@info.unicaen.fr, haskell-cafe@haskell.org On 16-Feb-2001 Matthias Felleisen wrote:
Because imperative languages have named one half of the denotation (the value return) and not all of it for a long long long time. It's too late for Haskell to change that. -- Matthias
Well now, if I am to understand what a return statement in C does, I must realize not only that it may return a value to a calling routine, but also that it preserves the store. If it allowed the store to vanish, it wouldn't be very useful, would it? So I don't see how it's reasonable to assert that "return" means only one of these two things to a C programmer. Cheers, --Joe Let me spell it out in detail. When a C programmer thinks about the 'return' type of a C function, he thinks about the value-return half of a return statement's denotation. The other half, the modified store, remains entirely implicit as far as types are concerned. This is what Jerzy's exam question was all about. -- Matthias
Matthias, My apologies for being deliberately obtuse. Of course, I understood what you were saying, but my point is this: The name of the monadic "return" combinator is perfectly sensible to anyone who understands the continuation semantics of imperative languages. While it shouldn't be necessary to be a denotational semanticist to program in Haskell, I think it is essential to appreciate the philosophical difference between the _being_ of functional programming and the _doing_ of imperative programming, if you're going to play with something like the I/O monad in Haskell. If you don't grasp that when you construct a monad, you're creating a value that represents an action, or in other words have a basic understanding of the functional denotation of an imperative command, you don't really understand what you're "doing" with monads, and your program is likely not to compute what you intend. In this sense, maybe it's better not to change the (initially) confusing "return" name, but to regard it as a pons asinorum that the student must cross. Cheers, --Joe On 16-Feb-2001 Matthias Felleisen wrote:
From: jhf@lanl.gov X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Date: Fri, 16 Feb 2001 16:53:13 -0700 (MST) Organization: Los Alamos National Laboratory Cc: karczma@info.unicaen.fr, haskell-cafe@haskell.org
On 16-Feb-2001 Matthias Felleisen wrote:
Because imperative languages have named one half of the denotation (the value return) and not all of it for a long long long time. It's too late for Haskell to change that. -- Matthias
Well now, if I am to understand what a return statement in C does, I must realize not only that it may return a value to a calling routine, but also that it preserves the store. If it allowed the store to vanish, it wouldn't be very useful, would it? So I don't see how it's reasonable to assert that "return" means only one of these two things to a C programmer.
Cheers, --Joe
Let me spell it out in detail. When a C programmer thinks about the 'return' type of a C function, he thinks about the value-return half of a return statement's denotation. The other half, the modified store, remains entirely implicit as far as types are concerned. This is what Jerzy's exam question was all about.
-- Matthias
Joseph H. Fasel, Ph.D. email: jhf@lanl.gov Technology Modeling and Analysis phone: +1 505 667 7158 University of California fax: +1 505 667 2960 Los Alamos National Laboratory post: TSA-7 MS F609; Los Alamos, NM 87545
Yes, students must cross the bridge. But the name 'return' may make it more difficult than necessary to cross the bridge. I conjecture that the students of our French friend are just the tip of the iceberg. All functional programmers have problems selling our ware to such people. Haskell could have benefited from using a word such as produce 10 to say that a function produces a 10 and a store or whatever. It could have driven home the point home. Faking to be C or Java is confusing and may create a backlash. Just admit you're different -- and better. We Schemers have different problems. -- Matthias
At 21:24 -0600 2001-02-16, Matthias Felleisen wrote:
... Haskell could have benefited from using a word such as
produce 10
to say that a function produces a 10 and a store or whatever.
In my classes, I use the term "deliver". This is the first semester I've gone as deeply into monads, so it's a bit early to say how well this terminology works. --HR ------------------------------------------------------------------ Hamilton Richards, PhD Department of Computer Sciences Senior Lecturer Mail Code C0500 512-471-9525 The University of Texas at Austin Taylor Hall 5.138 Austin, Texas 78712-1188 ham@cs.utexas.edu ------------------------------------------------------------------
Despite my arguments (and Jon's and others') about the appropriateness of "return", I must confess that Ham's "deliver" is excellent terminology. --Joe Joseph H. Fasel, Ph.D. email: jhf@lanl.gov Technology Modeling and Analysis phone: +1 505 667 7158 University of California fax: +1 505 667 2960 Los Alamos National Laboratory post: TSA-7 MS F609; Los Alamos, NM 87545
participants (4)
-
Hamilton Richards -
jhf＠lanl.gov -
Joe Fasel
-
Matthias Felleisen