Re^8: Is it worth using Monads in Perl ? and what the Monads are ?

[gaal]

I don't think we're disagreeing much on the technical side. There is one point I keep getting back to, which is that Haskell lets you do a lot of effectual computation without evoking the IO monad. Take STM for example: this is a way of sharing information across threads. It has great benefits over synchronization by explicit locks. But it doesn't allow you to do just any IO in the threads, so it doesn't fit all applications. But it does help terrifically with some! The takeaway is that in the imperative world, all side effects are equal in their, uh, effect on purity. If you write to a global you may as well write to a socket. With Haskell, this is not the case; you are encouraged to do more in other monads or in pure functions. STM's one example, parsing's another. If you didn't have the power of the typechecker you might find yourself wanting to parse something but thinking of ungetc!

About condescension: being a newbie often sucks! But I don't know that Haskell is worse than other language communities in this regard. Give the C FAQ a look, it's not exactly innocent of snark. In my experience the Perl community is by far the most welcoming for newcomers, but it has its share of idiots too...

[BrowserUk]

I keep getting back to, ... do a lot ... without evoking the IO monad.

Well yes. But they all involve some kind of side-effect. Using the IO monad for examples is just a simplification. The examples could be adapted to apply to any of the others equally.

Indeed, that is exactly what the category theory allows (I think), is that they can all be categorised together, characterised by the same set of rules, and manipulated using the same set of primitives.

Take STM for example: this is a way of sharing information across threads.

Basically a variable--the imperative sense of the word--plus some sequence information about who read what value when. Ie. State.

And the 'action' (side-effect) of using the STM is the reading, setting and rolling back of that state.

With Haskell, ... you are encouraged to do more in other monads, or in pure functions.

The description of a Perl program as 'one big IO monad' is a simplification. That's why I stuck to "Every Perl program ... lives inside a Monad". It is perfectly possible to write Perl scripts that never use IO, in which case the monad those programs would live inside would not be an IO monad. Equally, it is perfectly possible to write 'pure' functions in Perl (debatable given aliasing :).

Perhaps, Haskell just has more science than other languages for the uncertain to hide behind. In any case, I wouldn't call them idiots. Or maybe you weren't talking about them.

[gaal]

Take STM for example: this is a way of sharing information across threads.

Basically a variable--the imperative sense of the word--plus some sequence information about who read what value when. Ie. State.

Not quite; or, yes and no. Haskell already had run-of-the-mill mutable vars (called IORef). But STM gains its power from both monads and the fact that there's a typechecker. It's not just some sort of simulated state. You can have ten different functions updating the same TVar, and STM takes care of synchronizing this state across threads. (With no deadlocks and in composable ways; there are slides and a video that explain this very well.) And it's just TVars that you can update this way; your code won't compile if you try to update an IORef that's not part of the concurrency celebration.

Equally, it is perfectly possible to write 'pure' functions in Perl (debatable given aliasing :).

Of course it is! But the benefit that's missing is a typechecker, of the kind that doesn't let you compose functions that wouldn't make sense. How do you tell a function is pure in Perl? You read its code. But surely, the compiler could have figured this out at least?

Having good reason to believe a function is pure can be quite convenient. Your runtime could, for example, decide by default to memoize all pure functions automatically. If the compiler could prove a function only accepts one arg and that arg is a single byte in width, this can be a very cheap optimization! (Who knows, the compiler might precaluculate all possible output values if there were very few of them.) With an impure function, you simply have no grounds to do this, since you don't know if the function is looking at some other concealed input (of if indeed the caller wants it to produce some side-effectual output).

Regarding idiots, sorry, I was using the wrong word. I wasn't referring to anybody's intelligence, but rather to how some people deal with newcomers superciliously. I believe a better term is "gratuitously unpleasant person", though others may also be applicable.

[BrowserUk]

But surely, the compiler could have figured this out at least?

Hm. One way of reading it is that Haskell defaults to assuming that all functions are pure unless a monad is used, in which case they aren't. And it's the programmer that has to know to when to use the monad. Which goes back to my "monads are a complicated form of flag". Yes, I know it's more complicated than that...

Perl is the other way around. All functions are impure unless the programmer knows otherwise. It would be possible to use (say) attributes to allow the programmer to mark functions pure and the compiler could automemoize them on that basis. Maybe there is even a module idea in there somewhere.

For sure, Perl does no where near the depth of analysis that ghc does--but that is true in almost every area. Objects for instance. And maybe it's not possible without strict typing. But it is also a concious choice on behalf of the the language designers, hence Perl 6 won't have HM-style type checking either.

Is that the right decision? You'd have to argue that with Mr Wall. But without Perl's transparent coersion between strings, integers and reals (and Big::*), Perl would not be Perl.

Haskell and Perl go about achieving what they do--programs--in different ways. We all know that. This is not (for me) about which is better. It's about whether Perl could benefit from the inclusion of a monad type mechanism, to which I say emphatically no. Even if it could be implemented, without an HM-style type system, and a deep analysing compiler, it would be another manual process adding a drain on performance, without the benefits. Adding HM-style type checking to Perl (or any dynamic language) would be fairly impractical, but even if it was practical, I personally wouldn't want it. If I wanted that, I wouldn't be using Perl.

Haskell (often) sells itself on the strength of a few elegant snippets--like the quicksort routine using list comprehensions, but when you look beyond those snippets, much of the gloss is tarnished. It's a little like the Quantum::Superpositions module. When you first encounter it, especially the documentation in the form of what I am sure was a spectacular presentation, it really wows you. But when you look inside, you realise--as someone here commented--it's just a bunch of loops. That doesn't make the module any less powerful in what it does--though it is a little slow for some of it's less esoteric possible uses. What it does mean is that when you understand how it does what it does, the wow factor of the documentation/presentation fades somewhat. If the documentation was less wow, more down to earth, it might engender less ire. I'm pretty certain that Junctions will become a big factor in the success of Perl 6, assuming they are documented in a less hyperbolic fashion and are reasoably fast.

Haskell is a fine, powerful, flexible, fast, elegant language--if you like or need that sort of thing and can make the mental shift to that way of thinking. It doesn't need the hyperbole.

I've tried to keep this subthread on topic, but our interaction is rapidly descending into a which is better debate. Unless you think that Perl would benefit from the addition of a monad-like mechanism, I think we are probably done?

[BrowserUk]

An interesting aside arises from working my way through your links on STM. From section 4.4 of STM.pdf:

Like high-level languages, transactional memory does not banish bugs altogether; for example, two threads can easily deadlock if each awaits some communication from the other.

The oft-quoted problem with lock-based shared state is the deadlock problem. I was under the impression that STM was the cure for this. I'm disappointed to discover that's not the case.

See, you gotta look under the covers :)

[blazar]

In my experience the Perl community is by far the most welcoming for newcomers, but it has its share of idiots too...

Haha, from my now years long experience both in clpmisc and here, people seem to think differently. In particular I must be one of the idiots...