920 reputation
57
bio website
location
age
visits member for 3 years
seen Dec 12 at 20:02

Dec
13
awarded  Yearling
Dec
2
revised Why is the concept of lazy evaluation useful?
added 11 characters in body
Dec
1
revised Why is the concept of lazy evaluation useful?
added 80 characters in body
Nov
30
comment Why is the concept of lazy evaluation useful?
@Iztaka: "The generator can be separated from the consumer without being a lazy generator, and it's possible (albeit more difficult) to be lazy without being separated from the consumer." Note that when you go this route, you may end up with an **excessively specialized generator**—the generator was written to optimize one consumer, and when reused for others it's suboptimal. A common example is object-relational mappers that fetch and construct a whole object graph just because you want one string from the root object. Laziness avoids many such cases (but not all).
Oct
2
answered Databases: Where should the application logic run?
Aug
25
awarded  Good Answer
Jun
4
comment What is the “Free Monad + Interpreter” pattern?
A nitpick: "The free monad part is just [my emphasis] a handy way to get an AST that you can assemble using Haskell's standard monad facilities (like do-notation) without having to write lots of custom code." It's more than "just" that (as I'm certain you know). Free monads are also a normalized program representation that makes it impossible for the interpreter to distinguish between programs whose do-notation is different but actually "mean the same."
Dec
13
awarded  Yearling
Oct
25
comment What are the safety benefits of a type system?
@DonalFellows: The thing is that in practice, most functions that programmers write are primitive recursive or "nearly so" (would be primitive recursive save for the fact that it uses some external non-primitive recursive function). So having a type system that can check for conditional termination ("this function will terminate if every function call it makes also terminates") could catch many bugs.
Jun
4
comment The rationale behind Falsy values
No, Monad m => m (m a) does not have to be isomorphic to Monad m => m a, and is only so in special cases. There just needs to exist a join :: Monad m => m (m a) -> m a operation that obeys the Monad laws. Usually monads are explained in terms of >>=, which applies an a -> m b function "inside" the monad and then collapses the result, but the two operations can be factored out; ma >>= f = join (fmap f ma). And collapsing, in general, destroys some information; Maybe is one example, another one would be concat :: [[a]] -> [a], which destroys the grouping of the nested list.
Jun
3
answered The rationale behind Falsy values
Feb
25
awarded  Caucus
Dec
13
awarded  Yearling
Nov
26
comment Why is the concept of lazy evaluation useful?
@scarfridge, it's not that simple. In GHC the IO monad is actually built on top of the ST monad, which can cause effects. The STM monad in GHC is also side-effecting. But let's not confuse semantics and implementation here; all that the Haskell reports require is that there be an IO monad that provides the specified side effects. But there is not semantic reason why IO has to be the only side-effecting monad, it's just that such monads are not in the Report, and programs that use them require features outside the Report.
Nov
25
awarded  Critic
Nov
23
awarded  Good Answer
Sep
7
awarded  Nice Answer
Sep
7
answered Why is the concept of lazy evaluation useful?
Sep
7
awarded  Supporter
Aug
9
awarded  Nice Answer