Hi, I think a big advantage is that programs can be written without regard for whether or not a value will in the long run actually be evaluated. For me one of the best examples of this is that of logging within a compiler.

[example goes here]

Now if this is a strict language we have to go and modify all the intermediate functions to first of all take in a boolean and then use that to decide whether or not to produce any logging information. With a lazy language though, we don't need to do that, we're already done, no logging information will be produced if 'logOrNot' is false, because it will never be forced to evaluate the thunk. Yes, I agree, lazy evaluation is important, but unfortunately you didn't convince me that it should be on *by default*. In strict languages we usually some facility like macros, and with them we can do everything

Alan, like that (and with better performance). Or, we could make the logging function (called by functions inside convertToIntermediate, convertToAssembly etc) as lazy (mark them as lazy or change them to lazy form). For example, Scala again: /* Lazily compute the logger. The computation will not start running until the value of 'logger' is actually requested. */ var logger = lazy({ Logging.getLogger() }) /* This will start the computation */ logger.debug("medved") /* No delay to compute the logger again, as it has already been calculated */ logger.debug("preved")

...

According to one guy's analogy: the Real World is strict - in order to drink tea, you have to put the kettle on the fire, wait until water boils, brew tea and then drink. Not the kettle is put on the fire, water boils and the tea is brewed when you take the empty cup to start drinking. :-) Yes true, but you don't just boil up the kettle and brew the tea unless you have first asked if anyone actually wants tea. Hmm, the analogy is very flexible, and yours argument is also reasonable. (Oops, yes - kettle should be put on the fire, not cattle :-D)

Best regards, Nick

i.e. to use Monad.Writer in stead of Monad.State. The point is that for example 'typedProgram' does not really depend on the contents of 'log', but the dependencies in your code don't express this. One should switch from

Log -> (a, Log)

to

(a, Log -> Log)

or even

(a, Log)

if Log already has a natural monoid structure. Yes of course you're quite right, in general I would have the last version ie (a, Log). I did not wish to muddy the example, but probably it was not helpful to have 'typedProgram' depend on the contents of 'log'.

regards allan

2007/2/15, Dougal Stanton :

Quoth Nick, nevermore,

...

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!

An example of real world laziness, and where it pays off, is maybe the kanban system as used in manufactering: http://en.wikipedia.org/wiki/Kanban Not sure though if such so called real world examples actually add much to the discussion. Ultimately I think you need both lazy and strict evaluation; a reasonable default depends on the flavour of the particular language. Given Haskell, it seems lazy by default is the obvious choice (however I may feel that way simply because it _is_ that way :) )Strict just can't be the _only_ option, as it too often is. Kurt

Kudos to you for invoking Plato. This forum could use a bit of epistemological levity. Your passionate and quirky style reminds me of the "Laws of Form" by G. Spencer-Brown (http://en.wikipedia.org/wiki/Laws_of_form). One quibble: I work for a one of the world's largest 3-D visual effects studios (based in LA) and I can say with some authority that of the work I've seen, the vast amount of animation (complicated or not) both embedded in photo-realistic live action and in full-feature animation is NOT inverse kinematics, but forward kinematics in an endless chain of deformer layers, painstakingly and lovingly coerced through endless iterations into place. The "obvious benefits" of physical simulation, IK, and rule-based autonomous behavior inevitably run into the brick wall of a director whose inner vision cannot be easily converged on through any complicated function of few input parameters. Even motion capture (actual human motion) often needs tweaking to more effectively tell a story. Experienced animators can fake the IK part of this fairly quickly, in any case. As such, it is not lazy programming, but greedy programming that is prominent in my industry. Lazy algorithms work best when the goal is well understood and the algorithm takes shape during development. In visual effects, efficiency of process and predictability of result are paramount (pardon the pun), and algorithms that optimize these are well understood. It is the end effect that evolves by massaging and mutating these algorithms strategically. Often, the exact goal is not known even to the director until it appears out of a lineup (or "wedge", evaluated greedily) of countless variations. Perhaps your different experience is in the domain of robotics or games programming, which have entirely different goals and requirements. Dan Weston Senior Software Engineer Sony Pictures Imageworks NOTE: The opinions and observations expressed here are personal views expressed by me alone and do not necessarily reflect those of Sony Pictures, its subsidiaries, business partners, affiliates, or other employees thereof. jerzy.karczmarczuk@info.unicaen.fr wrote:

Citing the quoted citation, or the cited quotation, or whatever:

...

...

...

According to one guy's analogy: the Real World is strict - in order to drink tea, you have to put the kettle on the fire, wait until water boils, brew tea and then drink. Not the kettle is put on the fire, water boils and the tea is brewed when you take the empty cup to > start drinking.

etc. etc.... I have been advocating for years that independently of theoretical advantages, and some nice realizations (Bird et al), there is something more. The laziness is a terric ALGORITHMIC TOOL, making it possible to write equations, with intricate cross-reference between variables, and to transform them without moving a finger into implementable algorithms. There are no miracles, and if a variable references another one, which will be instantiated later, it cannot use directly the concerned values. But plenty of algorithms *may* be effective, since they defer the access to those "future" objects. I wrote a bunch of papers on this... Getting back to the Real World. The main issue - in my opinion - is that we do not code the Real World, whatever may be your personal philosophy. The models we code bear some peculiar relations to the models we *see* in our Plato cavern. Take for a pedagogic example, the issue of robotics, or, if you prefer, the animation of humans/animals, etc. The physical causality works as follows. The brain issues the orders which propagate sequentially through the nerves, make the articulations and the limbs move, and *finally* the end effector - the hand - grasps the kettle and put in on the fire. Anybody protests? Now, a robot, or an animated personage has a *scenario* to obey, to grasp the damn kettle, and to put it on the fire.

The intermediate limbs and articulations must move accordingly. Now you will code all this... And you fall well inside the domain called the Inverse Kinematics issue, which may demand some horrible calculi, such as the evaluation of the pseudo-inverses of Jacobi matrices, but doesn't matter. You must *reason* differently. The hand "pulls" the elbow, which pulls the arm, which "says": "may dear brain, I need the following commands from you, in order that our terminal effector obey its scenario..." == Folks, this is no science fiction, but *ALL COMPLICATED ANIMATIONS* are done in this way. The IK is an established industrial domain, and in my humble opinion, the laziness IS the tool to code it in a readable manner (I work on this right now, but slowly...) Jerzy Karczmarczuk PS. BTW. The True Real World is quantum, not classical. A bottle of the most expensive champagne I can afford, to a guy who will convince me that the quantum world is strict in the computational sense of this word. In my opinion this category is not applicable at all... _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

Nick, Roughly, I'd say you can fudge laziness in data structures in a strict language without too much bother. (I don't have much experience with this, but the existence of a streams library for OCaml is the sort of thing I mean. There are plenty of papers on co- iterative streams and suchlike that show the general pattern.) If you wish to add control structures you would need to use the lazy keyword a lot, e.g.: if cond then *lazy* S1 else *lazy* S2 and for more complicated structures it's not going to be always clear what needs to be suspended. Laziness is a conservative default here. (If you want to write an EDSL in a non-lazy language, you'll need to use some kind of preprocessor / macros / ... - in other words, a two- level language - or do thunking by hand, as above, or live with doing too much evaluation.) One way to gauge how useful laziness really is might be to look through big ML projects and see how often they introduce thunks manually. A thunk there is usually something like "fn () => ..." IIRC. Also IIRC, Concurrent ML is full of them. Dare I say the tradeoff is between a relatively simple operational model (so you can judge space and time usage easily) and semantic simplicity (e.g. the beta rule is unrestricted, easing program transformation). cheers peter

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

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.

apfelmus, Cool! I really like your examples! Thank you. Nick.