4 ms·

I don't know, but in my limited experience, lazy evaluation makes memory use worse (usually not much), but more importantly makes performance (time and memory)

I don't know, but in my limited experience, lazy evaluation makes memory use worse (usually not much), but more importantly makes performance (time and memory) harder to reason about, because you don't easily know when something will actually evaluate. Besides that, there's also not much practical gain from it, IMO. One commonly cited benefit is a function that doesn't use all of it's arguments, therefore saving computation time when they're not evaluated. But realistically, an unused parameter should probably be removed.

gizmo686 12y ago
Some level of lazyness is nessasary for Haskell to work. For example, you can do: a=1:a main = show $ head a With lazy evaluation, this will print "1", but with strict evaluation, this program will never terminate as it attempts to fully evaluate "a=1:a", which creates an infinite list. >But realistically, an unused parameter should probably be removed. You also have cases where a parameter is only used some of the time.
tel 12y ago
Generally the argument is never around saved computation but instead around composability. Lazy languages ensure that everything behaves like a value and in that domain operations compose much more effortlessly. You can't reason about operation as easily, so you don't, and the language can cope with making that work more or less correctly. Which is definitely suboptimal in some cases! I think honestly the goal should be reasoning about evaluation order statically instead of trying to find some clever argument such that laziness or strictness is clearly "correct".
the_af 12y ago
> But realistically, an unused parameter should probably be removed. Think about the function if-then-else, which you may be familiar with from your favorite language :) if-then-else true branch1 branch2 = branch1 if-then-else false branch1 branch2 = branch2 Obviously you don't want both branches evaluated in any given invocation, and obviously you cannot remove the unused parameter. Note that the purpose is not to "save computation", since for example branch1 may be undefined if cond is false! When using a language with support for lazy evaluation, you encounter this kind of functions all the time.
- tel 12y ago
  Of course, in OCaml that's just if_then_else c t e = match c with | true -> t () | false -> e () So the question sort of becomes one of how painful thunking or anonymous function syntax is.
dragonwriter 12y ago
> One commonly cited benefit is a function that doesn't use all of it's arguments, therefore saving computation time when they're not evaluated. But realistically, an unused parameter should probably be removed. How do you do that when the values of the other arguments determine whether or not that argument will be used?
stonemetal 12y ago
an unused parameter should probably be removed. It doesn't have to be completely unused to be avoided. In a case like: if a then b + c else c + d a and c are always evaluated, only b or d is evaluated not both. Removal isn't an option because b and d maybe used.

gizmo686 12y ago

Some level of lazyness is nessasary for Haskell to work. For example, you can do: a=1:a main = show $ head a With lazy evaluation, this will print "1", but with strict evaluation, this program will never terminate as it attempts to fully evaluate "a=1:a", which creates an infinite list. >But realistically, an unused parameter should probably be removed. You also have cases where a parameter is only used some of the time.

tel 12y ago

Generally the argument is never around saved computation but instead around composability. Lazy languages ensure that everything behaves like a value and in that domain operations compose much more effortlessly. You can't reason about operation as easily, so you don't, and the language can cope with making that work more or less correctly. Which is definitely suboptimal in some cases! I think honestly the goal should be reasoning about evaluation order statically instead of trying to find some clever argument such that laziness or strictness is clearly "correct".

the_af 12y ago

> But realistically, an unused parameter should probably be removed. Think about the function if-then-else, which you may be familiar with from your favorite language :) if-then-else true branch1 branch2 = branch1 if-then-else false branch1 branch2 = branch2 Obviously you don't want both branches evaluated in any given invocation, and obviously you cannot remove the unused parameter. Note that the purpose is not to "save computation", since for example branch1 may be undefined if cond is false! When using a language with support for lazy evaluation, you encounter this kind of functions all the time.

tel 12y ago
Of course, in OCaml that's just if_then_else c t e = match c with | true -> t () | false -> e () So the question sort of becomes one of how painful thunking or anonymous function syntax is.

dragonwriter 12y ago

> One commonly cited benefit is a function that doesn't use all of it's arguments, therefore saving computation time when they're not evaluated. But realistically, an unused parameter should probably be removed. How do you do that when the values of the other arguments determine whether or not that argument will be used?

stonemetal 12y ago

an unused parameter should probably be removed. It doesn't have to be completely unused to be avoided. In a case like: if a then b + c else c + d a and c are always evaluated, only b or d is evaluated not both. Removal isn't an option because b and d maybe used.