Path: utzoo!utgpu!news-server.csri.toronto.edu!clyde.concordia.ca!uunet!mcsun!ukc!stl!tom From: tom@stl.stc.co.uk (Tom Thomson) Newsgroups: comp.lang.functional Subject: Re: Can laziness sometimes be too lazy? Message-ID: <3240@stl.stc.co.uk> Date: 23 Jul 90 02:08:27 GMT References: <2706@bruce.cs.monash.OZ.AU> <25607@cs.yale.edu> <1670@opal.tubopal.UUCP> Sender: news@stl.stc.co.uk Reply-To: "Tom Thomson" Organization: STC Technology Limited, London Road, Harlow, Essex, UK Lines: 32 response to Wolfgang Grieskamp's shot across the bows of lazy languages:- I guess there'll be plenty of other responses, so I'm not going into the whole lazy versus eager thing. Three points though:- 1) WG's BOTTOM should of course be TOP, there isn't an absence of information (or a nonterminating construct), there's an excess of information (the function's type requires the argument to have type non-nil-list, the argument type is nil-list, the inferred type would have to have both pieces of information which pushes it straight to the top of the type lattice). Mostly, I prefer to call this sort of thing ERROR rather than TOP or BOTTOM but BOTTOM is just plain wrong. 2) Almost all the code I've ever written has been splattered with "if you ever get here, generate an error". Hope+ even had the type ERROR added to it to permit this style of programming. The flagship machine design included tag bits with every value, one of which indicated that the value had type "ERROR" and our parallel emulators implemented it. Most large software systems have this sort of programming, and we're quite happy when no errors are generated because those bits don't get executed. Lazy languages allow this style of programming, just as imperative languages did, but eager languages effectively prevent it 3) Why should it be assumed that the presence of a construct which, if evaluated, leads to an error or a nonterminating computation is a bug? I don't much like the original program, but if it's what the programmer intended there's no bug in it. For nice examples of bottom, some of us program with infinite lists all the time (and intentionally write non-terminating loops in imperative languages too). Tom Thomson