Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!wuarchive!udel!rochester!pt.cs.cmu.edu!o.gp.cs.cmu.edu!spot From: spot@CS.CMU.EDU (Scott Draves) Newsgroups: comp.lang.functional Subject: Re: Applications for lazy functional languages Message-ID: Date: 23 Mar 91 16:51:51 GMT References: <4682@osc.COM> Sender: netnews@cs.cmu.edu (USENET News Group Software) Distribution: comp Organization: School of Computer Science, Carnegie Mellon University Lines: 77 In-Reply-To: jgk@osc.COM's message of 23 Mar 91 01:02:17 GMT In article <4682@osc.COM> jgk@osc.COM (Joe Keane) writes: In article acha@CS.CMU.EDU (Anurag Acharya) writes: >I am curious about the kind of applications that lazy functional languages >are suitable for. What can you do with such languages (in a natural and >elegant fashion) that you cannot similarly do with a strict language augmented >by a lazy type constructor ? Nothing. Besides the obvious argument of Turing equivalence, this isn't at all what the question was. given any language i can think of you can show how to implement lazy closures. In C you can use structs and function pointers. you can store-away a function that already existed at compile time, but you can't create new functions (unless you count forking off cc and dynamic loading :). Please show us how, if you think it can be done. In Scheme you can implement `delay' and `force' as lambda expressions. Not really. They have to be special forms. Or macros. In either case, they are not functions. For example, the C operator `&&' is defined to be lazy in its second argument. << more of the same, ie non-strict = lazy >> strict/non-strict is a different issue, although they are related. At best, I think you are stretching the definition of lazy much too far. non-strict can be implemented with lazy, but lazy implies far more than non-strict. In terms of correctness, making a strict function lazy never hurts. not true, side effects. So it makes a lot of sense to have a language where every function is lazy. he he This eliminates an artificial distinction, and allows you to get the benefits of laziness everywhere, not just where someone thought it might be useful. So why don't people do this? The answer is always the same: ``It's too slow.'' damn right Some people claim this is an inherent problem with lazy languages. I strongly disagree with this position. Naive implementations do a lot of unnecessary testing and jumping around, and i'm afraid that this has given lazy languages a bad reputation for inefficiency. laziness has significant cost. laziness is occasionally useful. It only really pays off when you don't evaluate an argument. but this doesn't happen very often. So you rarely benefit from it. But you always pay for it. It's fine in an interpreter. It's a big lose in a compiler. not to mention that it plays hell with side effects. With the proper techniques, a lazy language can be faster than a traditional one. So for now, i'll just leave this as an unsubstantiated claim. no kidding -- christianity is stupid Scott Draves communism is good spot@cs.cmu.edu give up