Re: [Haskell-cafe] Does laziness make big difference?
Jerzy Karczmarczuk, You have strict languages as Scheme or ML, with some possibilities to do lazy programming. Go ahead! (But you will pay a price. The laziness in Scheme introduced by the delay macro can produce a lot of inefficient code, much worse than coded at the base level). Maybe I am not clear enough, but this is the price I try to measure. :-) The question is NOT open. The question has been answered a long time ago in a liberal manner. You have both. You *choose* your programming approach. You choose your language, if you don't like it, you go elsewhere, or you produce another one, of your own. Yes, I agree, the world of programming is very rich. But you probably know, there are quite a few of curious people (at least in the Russian community) that begin to be interested in other (than mainstream) languages. Of course, one moment they meet Haskell, and get exited of its excellent expressive capabilities, but finally ask the same question: What advantages does lazy language have? And you see, it is incorrect to answer: Relax, no advantages at all, take a look at ML or Scheme, because it is just not true. But in order to invite new members to the community, we have to answer this question (and plus 100 other boring questions) over and over again. Especially it is even harder to avoid another holy war, because on the other side there are languages with advanced expressiveness features and macrosystem. Haskell chose a particular schema, that implied a *very concrete* decision concerning the underlying abstract machine model, and the implementation. It is a bit frustrating reading over and over the complaints of people who never needed, so they dont appreciate laziness, who want to revert Haskell to strict. As if we were really obliged to live inside of a specific Iron Curtain, where only one paradigm is legal. You misunderstood me, I don't try to revert Haskell to strict. I like Haskell as is. My motivation is different. Best regards, Nick. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Does laziness make big difference?
So, as I understand, choosing default laziness was just experimental design decision in order to answer the question: how good lazy language can be. I am practically convinced, that lazy evaluation included in the _right_ places can be extremely useful. I didn't state the question as strict vs lazy, my question is different - default laziness with optional strict -vs- default strictness with optional lazy. And sorry, but the question remains open. at the time, lazyness was also the best-known basis for pure functional i/o (result continuations and monads taking over later), still a hot and tricky topic then. as for defaults, lazy evaluation is normal order strategy + sharing of arguments, strict evaluation corresponds to applicative order strategy, and we know from lambda-calculus that normal order strategy is normalizing (reaches a normal form if one exists) whereas applicative order strategy is not. on this basis, non-strictness is a safe default, with strictness to be inferred or annotated where needed. since strictness is undecidable in general, inference has to be approximate, and a safe default is essential. of course, one can program in mostly strict languages - I started out in one that used applicative order strategy, but had normal order application as well, plus the usual \()-thunking. and as you say, modern versions of default strictness allow you to annotate the function as non-strict, so you don't have to use special application operators everywhere, and lazy-keywords are clearer than \()-thunks. but from my own experience, I had to think a lot more about evaluation order in the default-strict language than I have to in the default-non-strict language, and what is worse, I had to do this thinking up-front, whereas now I can think about the data-dependencies first, and do the thinking about evaluation order later, and only on demand:-) that is also why programs written in default-strict languages often seem to win in performance competitions: if you get it to work at all, you'll also have put in some thoughts on performance/evaluation order already. programs written in default-non-strict languages can be made to work without worrying about those details, so it often happens to look as if lazy programs were resource- hungry, and a lot of extra work had to be put in to make them efficient. but I'd put it differently: about the same amount of thought has to be put in to make either kind of program efficient, only that with non-strict default, I get to choose when (and whether) to put in that effort. in other words, default-strict languages are strict in demanding evaluation- order information early, whereas default-non-strict languages give the programmer more leeway. hth, claus ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Does laziness make big difference?
Dougal, According to one guy's analogy: the Real World is strict - in order to drink tea, you have to put the cattle on the fire, wait until water boils, brew tea and then drink. Not the cattle is put on the fire, water boils and the tea is brewed when you take the empty cup to start drinking. :-) I think the word you meant there is "kettle", since "cattle" are what get turned into burgers ;-) Still, the idea of water-boil-tea-brew happening by demand would probably save electricity in our energy-conscious world. Don't boil a full kettle for a single cuppa! Of course, I meant "kettle" that should be put on the fire. I was not intended to singe poor cows for a cup of tea.:-D And to continue this analogy: when we decide to drink tea, we run the algorithm (water-boil-tea-brew) from begin to end strictly and imperatively. We resolve the dependencies water - ... - brew only the first time at the stage of "designing" the algorithm (by means of reasoning and common sense), but after finishing the "design" we can just run it unbounded times for any amount of tea. :-) The question is the following: how big the gap between strict languages with lazy constructs and Haskell? Does the default lazyness have irrefutable advantage over default strictness? That kinda leads into thoughts of the Turing tar-pit, where everything is possible but hopelessly obfuscated by the constraints of the language. I think default laziness, to answer your actual question, has advantage in terms of thought process. It helps me consider things in terms of dependencies. To go back to the analogy: in the strict style it's very easy to boil the kettle and then let the water go cold. This is a waste of energy (CPU time, or whatever). So whether it's *computationally* more valuable, I don't know. But I find that it helps me to order my thoughts about what a problem *needs*. Well, as I understood, for your way of thinking lazy language is more suitable. I see, this is good motive for you (or people like you, I guess you have solid mathematical background or something like that) to choose Haskell or other language with default laziness, but the question in general remains open... Thank you for the answer. Best regards, Nick. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Does laziness make big difference?
Nicolas, Someone already mentioned John Hughes paper. Another resource is SPJ's "hair shirt" slides (also discusses type classes and monads). http://research.microsoft.com/~simonpj/papers/haskell-retrospective/HaskellRetrospective.pdf Laziness is addressed beginning on slide 19. I've even read "History of Haskell" paper, and accordingly to it the default laziness was chosen because it was rather unite factor for scientists, not because it had some big advantage: Then, in the late 70s and early 80s, something new happened. A series of seminal publications ignited an explosion of interest in the idea of lazy (or non-strict, or call-by-need) functional languages as a vehicle for writing serious programs. So, as I understand, choosing default laziness was just experimental design decision in order to answer the question: "how good lazy language can be". I am practically convinced, that lazy evaluation included in the _right_ places can be extremely useful. I didn't state the question as "strict vs lazy", my question is different - "default laziness with optional strict -vs- default strictness with optional lazy". And sorry, but the question remains open. Best regards, Nick. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
