Path: utzoo!attcan!uunet!cs.utexas.edu!usc!zaphod.mps.ohio-state.edu!sol.ctr.columbia.edu!cica!iuvax!silver!jashley
From: jashley@silver.ucs.indiana.edu (J. Michael Ashley)
Newsgroups: comp.lang.functional
Subject: Re: Can laziness sometimes be too lazy?
Message-ID: <52194@iuvax.cs.indiana.edu>
Date: 26 Jul 90 16:09:56 GMT
References: <3188@osc.COM> <2734@bruce.cs.monash.OZ.AU> <1681@opal.tubopal.UUCP>
Sender: news@iuvax.cs.indiana.edu
Organization: Graceland
Lines: 43

In article <1681@opal.tubopal.UUCP> wg@opal.cs.tu-berlin.de writes:
>
> Bottom is not an error, 
>catchable exeception, or something like this. It is  the real fatal case,
>the last thing a program feels before [nirvana]!

I think I just found my "clever .signature".

>Handling errors is again another thing. I dont like the idea 
>extending the domain of each data object implicit by 
>an error value.

A lot of people don't like this idea.  I think that's *one* of the motivations
for using continuations semantics.  If you get an error, you throw away the
current continuation and invoke an error continuation.  That way you don't have
to pass this silly ERROR value all the way through the rest of the program.

So we extend the domain or use a non-functional exception handler.
This doesn't look very good.

>However, choosing to let the result BOTTOM, the problem
>is still not soluted on my opinion.  You would like to see where the 
>bottom was produced when the fatal case handler is raised!

Sorry, I don't understand this sentence.

>So BOTTOM must 
>implement a kind of suspended call chain backtrace.

What's a suspended call chain backtrace?

>Its clear that such a BOTTOM cannot be the regular case.

Can somebody very precisely define the meaning of bottom?  I'm getting
a little confused here now that Wolfgang and other people have started
throwing it around liberally.

It sounds like people want bottom to be the value of any nonsensical
expression.  Is this right/


mike ashley
jashley@lanl.gov