Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!samsung!uunet!dino!ux1.cso.uiuc.edu!iuvax!silver!jashley
From: jashley@silver.ucs.indiana.edu (J. Michael Ashley)
Newsgroups: comp.lang.functional
Subject: side effects in FL's (was "Can laziness sometimes be too lazy?")
Message-ID: <51915@iuvax.cs.indiana.edu>
Date: 24 Jul 90 15:19:05 GMT
Sender: news@iuvax.cs.indiana.edu
Reply-To: jashley@silver.ucs.indiana.edu (J. Michael Ashley)
Organization: Graceland
Lines: 76


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!"