Path: utzoo!attcan!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?
Message-ID: <1681@opal.tubopal.UUCP>
Date: 26 Jul 90 13:22:52 GMT
References: <3188@osc.COM> <2734@bruce.cs.monash.OZ.AU>
Sender: news@tubopal.UUCP
Reply-To: wg@opal.cs.tu-berlin.de
Followup-To: comp.lang.functional
Organization: Technical University of Berlin
Lines: 88


jgk@osc.COM (Joe Keane) writes:

>[...] One thing that you are allowed to do [in lazy languages] is change 
>bottom into some valid value, as long as you're consistent.  

	letrec BOTTOM = BOTTOM

You cannot change bottom ever to a legal value. You can only suspend the
access to bottom in normal order languages. Bottom is not an error, 
catchable exeception, or something like this. It is  the real fatal case,
the last thing a program feels before nirwarna!

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.

Handling errors is again another thing. I dont like the idea 
extending the domain of each data object implicit by 
an error value. This last not least to avoid wasting tagging bits.

I would rather prefer some kind of subsorting (not only
for this reason). For example, you may have a sort implementation for
lists as usual, and you may have a sort implementation

	type list_or_error == list U {ERROR}

Sort list is compatible with list_or_error, but not vice versa, unless
you establish a constraining which checks that l of sort list_or_error is 
also of sort list. 

I think this is the direction suggested by Frank Silbermann which he
calls "strong typing" (i would prefer the notion subsorting. The OOPs 
people made this concept famous).

For example, list itself maybe defined as

	type list == nil_list U cons_list

If now hd and tl is only defined on cons_list, the original "first" definition 
is type incorrect. You must inspect both the nil_list argument 
and the cons_list argument case and are forced to choose a way to handle the 
nil_list. 

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.


mmcg@bruce.cs.monash.OZ.AU (Mike McGaughey) writes:

>On reflection, there are a number of possible responses to my query -
>the most common one has been "your program is incorrect - rewrite it".
>This is manifestly obvious and misses the point.  It might be closer to
>the mark to say that the example illustrates that lazy programmers are
>safer programming in a top down fashion, or in such a way that they
>never rely on a function's failure, or always making their intentions
>clear by using pattern matching (but there are certainly cases where
>pattern matching won't help.  And what about languages that don't have
>pattern matching?  

Pattern matching cannot solute the problem. Pattern matching is 
just syntactical flavour - if you translate it to low-level
case-cascardes strictness propertys do not change. Maybe, what you 
expect from pattern matching, can be supported by assertions (eiffel
has them). In a crutchy syntax:

	letrec first n l {length(l) >= n} = ...


>Also, could automatic program transformations cause problems here?.

Actually, for many transformations, you need a expensive strictness 
analysis to prove the applicatability in normal-order languages. 

>There seems to be a fundamental inelegance in having to know whether or
>not the result of a function will actually be inspected by a program.

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. 

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Wolfgang Grieskamp            "Learning form OOPs means learning victory ..."
wg@opal.cs.tu-berlin.de        tub!tubopal!wg        wg%opal@DB0TUI11.BITNET