[Haskell-cafe] Wow Monads!

Joachim Durchholz 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
> example.

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
> state.


>>>> And I think you can trace that to the need to interface with the real
>>>> world.
>>> 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.
>> YMMV.
> 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 mailing list