[Haskell-cafe] Wow Monads!

[Joachim Durchholz]

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.

True.

>>>> 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 :-) )

:-D