750 reputation
37
bio website
location
age
visits member for 2 years, 7 months
seen 2 days ago

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
Aug
9
comment Do I need to use an interface when only one class will ever implement it?
And last one: 5. Clients (ideally) shouldn't care how many classes my module has or how many, or even be able to tell. All they should see is a set of types, and some factories or façades to get the ball rolling. I.e., I often see value in encapsulating even what classes your library consists of.
Aug
9
comment Do I need to use an interface when only one class will ever implement it?
1. Code organization; having the interface in its own file that has only signatures and documentation comments helps keep code clean. 2. Frameworks that force you to expose methods that you'd rather keep private (e.g., containers that inject dependencies through public setters). 3. Separate compilation, as mentioned already; if class Foo depends on interface Bar then BarImpl can be modified without having to recompile Foo. 4. Finer-grained access control than public/private offers (expose the same class to two clients through different interfaces).
Aug
7
awarded  Teacher
Aug
7
awarded  Editor
Aug
7
revised Do I need to use an interface when only one class will ever implement it?
added 319 characters in body
Aug
7
answered Do I need to use an interface when only one class will ever implement it?