[Haskell-cafe] Wow Monads!
jo at durchholz.org
Wed Apr 19 13:58:39 UTC 2017
Am 19.04.2017 um 15:13 schrieb Sergiu Ivanov:
>> Seemed to be related to Haskells expressivity, with the type system
>> pretty much preventing the typical errors that people make.
> I tend to see Haskell's type system as very restrictive and only
> allowing behaviour which composes well.
From a library writer's and library user's perspective, that would
actually be a Good Thing.
> However, there are a couple big "backdoors", like the IO monad.
Well, it's so awkward that people don't *want* to use it.
> Typechecking gives zero guarantees for functions of type IO (), for
That doesn't match what I hear from elsewhere.
I don't know what is the cause for that difference though.
>> Though I doubt that that will hold up once you get more proficient in
>> Haskell and start tackling really complicated things
> To me, it really depends on the kind of complicated things. If you
> manage to explain the thing at the type level, then typechecking may
> give you pretty strong guarantees. I'm thinking of parsing and
> concurrency as positive examples and exception handling as a somewhat
> negative example.
That matches what I heard :-)
>> (Ironically, people instantly started investigating ways to work around
>> that. Still, the sort-of globals you can introduce via the State monad
>> are still better-controlled than the globals in any other language.)
> In fact, I believe having pure functions does not so much target
> removing state as it does making the state _explicit_.
Except State tends to make state implicit again, except for the fact
that there *is* state (which might be actually enough, I don't have
enough insight for any judgemental statements on the issue).
> Thus, the State
> monad is not a work-around to purity, it's a way of purely describing
>>>> And I think you can trace that to the need to interface with the real
>>> I have the same gut feeling.
>> I think interfacing with the outside world (still not "real" but just
>> bits inside the operating system and on disk) is one major source of
>> unreliability, but not the only one, and not necessarily the primary one.
> Yes, that unreliability comes with crossing the frontier between
> theoretical and applied computer sciences (that's an imprecise
> metaphor :-) )
More information about the Haskell-Cafe