home *** CD-ROM | disk | FTP | other *** search
- Path: sparky!uunet!mcsun!sunic!chalmers.se!cs.chalmers.se!augustss
- From: augustss@cs.chalmers.se (Lennart Augustsson)
- Newsgroups: comp.lang.functional
- Subject: Re: programs that are too lazy
- Keywords: n
- Message-ID: <1992Jul29.164919.2677@cs.chalmers.se>
- Date: 29 Jul 92 16:49:19 GMT
- References: <1992Jul27.083020.6061@st-andrews.ac.uk>
- Sender: news@cs.chalmers.se (News administrator)
- Organization: Chalmers University of Technology
- Lines: 34
-
-
- Sorry about my last posting, the mailer mangled it.
- In article <1992Jul27.083020.6061@st-andrews.ac.uk> ajtd@st-andrews.ac.uk (Antony J. T. Davie) writes:
- >Julian Seward writes
- >>I believe the Haskell committee should
- >>consider the provision of two built-in functions:
- >>
- >> hyperstrict, whnf :: Eq a => a -> b -> b
- >>
- >>both of which evaluate their first argument (fully or to whnf)
- >>and return the second. We can simulate this at the moment using
- >>Haskell 1.2, but it might be more efficient if compilers could
- >>regard these as primitive.
- >
- >Whether or not one agrees with the provision of these fns., why restrict
- >them to Eq types? Certainly one can only easily simulate them if they
- >operate on equality types, but that's no reason to restrict primitive
- >versions of them so.
- >
- There should be some suitable restriction on the values that allow
- whnf. E.g.
- whnf :: (WHNFable a) => a -> b -> b
- The function with type a->b->b that evaluates its first argument
- and return the second is not definable within lambda calculus.
- Having it enables you to distinguish between BOT and \x.BOT,
- which are usually regarded as equal. (whnf BOT 0 --> BOT, but
- whnf (\x.BOT) 0 --> 0)
-
- -- Lennart
-
- --
-
- -- Lennart Augustsson
- [This signature is intentionally left blank.]
-