🚀 go-pugleaf

I think we all agree that bottom is the least-defined element.  This means you
don't know anything about it.  Is it an error?  You don't know.  Is it a
number?  You don't know.  Is it bottom?  You don't know.  And so on.

The last one is key.  The most important property of bottom is that you never
know when you have it.  If you `know' something is bottom, you know something
about it, so it's not really bottom, is it?

Now, in a lot of cases we can determine that an expression is stuck in an
infinite loop.  Usually this is defined to be bottom, but we can extend the
semantics so that when this is detected it raises an `infinte loop' exception.
However, it should be clear that this is no longer bottom, and that no matter
how sophisticated our detection algorithm, some expressions will still be
bottom.

Also, depending on your type system, there can be different `degrees' of
bottom.  For example, you may know an expression is an integer but its exact
value is unknown.  I don't think this changes the arguments.

In article <1681@opal.tubopal.UUCP> wg@opal.cs.tu-berlin.de (Wolfgang
Grieskamp) writes:
>Exception handling is only little related to the problem. Like Michael Ashley 
>(who intentionally changed the subject) I believe that an exception is a 
>side effect, and you have to leave the comfortable semantic reservate
>fl's give to tread them.

Needless to say, i disagree with this.  If FL designers believe this is true,
they will only design toy languages.  You're OK as long as you don't make any
mistakes.

>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! So BOTTOM must 
>implement a kind of suspended call chain backtrace. Its clear that such a 
>BOTTOM cannot be the regular case.

You're right.  If the error `BOTTOM' does some sort of backtrace, it's not
really bottom.

>The programmer needs the freedom to choose between strict and non-strict 
>programming constructs. I would prefer to make the non-strict case explicit, 
>and let the strict one be the default. 

As i said before, i think a sort of hybrid approach is the best.  You can
declare that a given argument to a function must be valid, i.e. must not raise
an exception.  Then upon entering the function, the exception system will do
enough work to ensure that the argument is valid.  However, the actual value
need not be computed until it's really needed.

In article <10268@brazos.Rice.edu> rama@titan.rice.edu (Ramarao Kanneganti)
writes:
>Error is much more than bottom. Bottom is least informative. If you
>sitting in front of a terminal you notice when the program doesn't
>come back with any thing, or if it comes back with an error message.
>Error is more informative than bottom. Would you equate abort(5) with
>bottom, simply because abort is unhandled?

I agree completely.  Bottom gives you no information, not even that it's
bottom.

>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.

I don't think these are really any different.  It's just a matter of
implementation.  The naive way to deal with an exception is to represent it as
a return value, and keep passing it back up the chain, until someone handles
it, i.e. does something besides pass it up.  You can be a little smarter and
figure out who is going to handle the exception, and jump straight there.

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

I think it's a bad idea.