Path: utzoo!attcan!utgpu!news-server.csri.toronto.edu!clyde.concordia.ca!uunet!mcsun!unido!tub!tubopal!wg
From: wg@opal.cs.tu-berlin.de (Wolfgang Grieskamp)
Newsgroups: comp.lang.functional
Subject: Re: Can laziness sometimes be too lazy?
Keywords: bottom, error, exception handling
Message-ID: <1692@opal.tubopal.UUCP>
Date: 28 Jul 90 18:05:22 GMT
References: <3188@osc.COM> <1681@opal.tubopal.UUCP> <10268@brazos.Rice.edu> <3203@osc.COM>
Sender: news@tubopal.UUCP
Reply-To: wg@opal.cs.tu-berlin.de
Followup-To: comp.lang.functional
Organization: Technical University of Berlin
Lines: 28

jgk@osc.COM (Joe Keane) writes:

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

Actually agreed. But i wouldnt say you know nothing, but inside the 
language you view nothing is known about bottom.

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

I have a simple pragmatic problem with the approach to extend the semantic.
Imagine, you have a functional language with sum-of-prod types and
you have a simple compiler for it. This compiler is able to generate
exception code for expressions like, for example, hd(nil).

Now you have written a program, gone through the valification phase and
so on, and are quite sure your program is correct. The compiler has
a switch to disable checking of undefined expressions.
Because the program is highly data-structure oriented, you will get
a speedup of about 10% using this switch. You do it!   ???


~~
Wolfgang Grieskamp 
wg@opal.cs.tu-berlin.de