RWH has chapters that go over implementing network based applications, database based applications, using STM, etc etc, LYAH is great for getting your head into the haskell mindset understanding functors, applicatives, the data types and abstraction techniques idiomatic in haskell
Book form about $70 for both. Shame no employer is likely to cough up for them. Books=less eye strain. I'll probably read both on line, though it will go faster if I shell out for the books.
user20683
@JimmyHoffa LHFH is interesting for a Haskell tutorial because it starts with Hello World
@psr I never read RWH, I find it a great reference when I want to work with a particular library as it has chapters for lots of the large ones, I read LYAH on a tablet on my porch every night a summer ago
The distinct difference between RWH's approach and LYAH's approach is good as people find one of the two works better for them (and usually the other works poorly for that person)
@WorldEngineer I think I looked at that one a while ago, seems decent for a tutorial style thing. Would actually fit great on SoH
@psr have a look here and keep in mind that do notation is hiding some facts from you as you progress you'll want to learn to use monads without it, but don't worry about it, just keep it in mind every time you write something with do
@JimmyHoffa - I get that monads don't change the pure evaluation style of the language - though they might fake it by building up a parse tree of actions to execute outside that environment, using whatever core level cheat the compiler must have for doing things like that. Or at least, something like that.
@psr when you get your head around monads more you'll start to see how it makes what would otherwise be impure actually pure, the first time you try to get something out of an impure context and realize you can't you'll begin to feel funny and realize there's something going on
@JimmyHoffa - I actually understand that part (proficiency is another thing entirely). I'm just saying, something somewhere got something into the impure context. It might make it easier for me to reason about things if I knew where. Possibly FFI, then.
if you have an IO a, you can't get the value of a without calling UnsafeCoerce (which you should basically never do, though as you're working with it to begin with you'll really feel like you should be using UnsafeCoerce for things)
(FFI lives in the IO monad, that's what makes the IO monad special)
Without knowing implementation details of whatever you are unsafe coercing it must be hard to know what you will actually get. At minimum what state changes have been applied to a would often be implementation dependent. If my mental model of things is correct.
mumps ffi huh? I would have presumed you'd prefer a mumps interpreter. For ffi you could just hide normal interop approaches, Haskell interops fine with C or C++
