Path: utzoo!attcan!uunet!aplcen!uakari.primate.wisc.edu!sdd.hp.com!decwrl!pacbell.com!pacbell!osc!jgk
From: jgk@osc.COM (Joe Keane)
Newsgroups: comp.lang.functional
Subject: Re: Can laziness sometimes be too lazy?
Message-ID: <3193@osc.COM>
Date: 24 Jul 90 22:48:44 GMT
References: <2706@bruce.cs.monash.OZ.AU> <25607@cs.yale.edu> <1670@opal.tubopal.UUCP> <3913@rex.cs.tulane.edu>
Reply-To: jgk@osc.COM (Joe Keane)
Organization: Object Sciences Corp., Menlo Park, CA
Lines: 20

In article <3913@rex.cs.tulane.edu> fs@rex.cs.tulane.edu (Frank Silbermann)
writes:
>In a lazy language, you have two choices.
>You can define the result to be "bottom",
>(the least-defined domain element, according to the partial-order).
>This approach emphasizes flexibility at the expense of safety,
>and is therefore appropriate in a language for building prototypes.
>Or, you can use strong typing to catch all such operations
>at compile-time and reject such programs as illegal.  
>This approach emphasizes safety at the expense of flexibility,
>and is therefore more appropriate for building a production system.

I don't agree with this dichotomy.  Specifically, i don't like either of the
alternatives.  There are better ways to handle the problem.

Despite what some people say, i don't think strong typing is such a good deal.
It catches obvious errors, but doesn't do you any good against less obvious
bugs.  In the example given, strong typing is no help, unless perhaps your
typing system includes the length of a list.  The problem is how to predict
and deal with run-time errors.