http://qs321.pair.com?node_id=621235


in reply to Re^5: Is it worth using Monads in Perl ? and what the Monads are ?
in thread Is it worth using Monads in Perl ? and what the Monads are ?

Yes, or like Aspects of AOP: an organizational unit of behavior or functionality. If you approach them from the software engineering perspective and not from the theoretical CS/mathy perspective, one rough way to think of them is as overloading the meaning of the semicolons that separates statements.

Regarding coming out straight, I'm really not sure what to say. Some people who talk enthusiastically about Haskell come from a different background than advocates of many other languages you're familiar with, and that's part of why they take some things for granted and stress others. My own experience hasn't been easy, but it certianly hasn't been that somebody's evasive or dishonest about the design goals. So if you read Wearing the Hairshirt or Tackling the Awkward Squad, for example, I don't think you get the sense that somebody's bluffing (well, I didn't!). Sure, uncontrolled effects are presented as a bad thing, but part of what's good about monads is that they let you tag the bits that are and those that aren't pure, and the typechecker doesn't let you mix them incorrectly.

Replies are listed 'Best First'.
Re^7: Is it worth using Monads in Perl ? and what the Monads are ?
by BrowserUk (Patriarch) on Jun 14, 2007 at 15:32 UTC
    ...it certianly hasn't been that somebody's evasive or dishonest about the design goals.

    When I used the words "They are, emotionally, just a way of concealing the fact that Haskell programs contain code that has state."

    I was not saying that there was anything "evasive or dishonest" going on.

    Have read both of those papers by SPJ and I have to say, that he is the exception that proves the rule when it comes to straight talking in the Haskell community. Indeed, I've downloaded the latter many times because when I go looking for it, I can never find it because the name (mark.pdf) doesn't ring any damn bells. Last time, I remembered to change the name to something meaningful :)

    Anyway, back to what I did mean and using the those papers as exhibits in my defense.

    Section 2.1 begins: "We begin with an apparently fundamental conflict. A purely functional program implements a function; it has no side effect. Yet the ultimate purpose of running a program is invariably to cause some side effect: a changed file, some new pixels on the screen, a message sent, or whatever. Indeed it’s a bit cheeky to call input/output “awkward” at all. I/O is the raison d’ˆetre of every program. — a program that had no observable effect whatsoever (no input, no output) would not be very useful."

    Section 2.2 starts:

    "2.2 Monadic I/O

    The big breakthrough in input/output for purely-functional languages came when we learned how to use so-called monads as a general structuring mechanism for functional programs. Here is the key idea:

    A value of type IO a is an “action” that, when performed, may do some input/ output, before delivering a value of type a.

    This is an admirably abstract statement, and I would not be surprised if it means almost nothing to you at the moment.

    And moves on through a lot of syntactic and semantic discussion before reaching:

    Monads were originally invented in a branch of mathematics called category theory, which is increasingly being applied to describe the semantics of programming languages. Eugenio Moggi first identified the usefulness of monads to describe composable “computations” 32. Moggi’s work, while brilliant, is not for the faint hearted. For practical programmers the breakthrough came in Phil Wadler’s paper “Comprehending monads” 47, in which he described the usefulness of monads in a programming context. Wadler wrote several more very readable papers about monads, which I highly recommend 48, 49, 50. He and I built directly on this work to write the first paper about monadic I/O 38.

    In general, a monad is a triple of a type constructor ...

    I wish I could c&p the big lump of algebraic notation that follows, but it suffices.

    He starts out saying "functions have no side-effects" and ends up describing how actually, they can. That's smoke and mirrors!

    Not in any "deceptive", "evasive" or "dishonest" sense. But in the same sense that "tax avoidance" exploits loopholes in the law. It's not breaking the law, but it still results in you paying less tax than you might otherwise have had to pay.

    So "“monad” derived from category theory, one of the most abstract branches of mathematics" is the loophole.

    I have no doubt that if I was able to understand the notation and theory behind the concept, that I to could convince myself that theory holds up. But I don't need to do that, because I am happy to take it as read from those that do understand it.

    But, IO still has side-effects. And functions that do IO still have side-effects. They haven't disappeared, they've just been moved 'outside of the program' into the world, where they do no harm. In particular, they do no harm to the purity of the lazy functional ethics. and especially, to the compiler magic made possible by the HM type system.

    The defensiveness I referred to does not exist because there is anything wrong with the theory underlying monads (I assume :). It arises because actually, there are far more Haskellers that don't fully uunderstand the theory than do, and their defensive posture is to refer questioners to the theory, rather than try and explain it in terms that non-mathematicians can grasp. There is an old saying I cannot remember, that says something to the effect that it takes an expert practitioner--one who really, really understands his subject--to explain complicated things in simple ways.

    It's not uncommon. We've all seen the examples of the resident 'expert' asked for an explaination of something complicated, resort to waffling in techno-babble. Most of us have been there at some point or another. It doesn't mean we do not understand. It just means that we have not reached that level of comfort with the subject to be able to de-cloak it from the technicalities as a real expert--and a very few gifted teachers (of anything)--can do.

    However, there is a common and unpleasent side-effect [sic] of techno-babble. It is often perceived as condescension. And that can be detrimental.


    Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
    "Science is about questioning the status quo. Questioning authority".
    In the absence of evidence, opinion is indistinguishable from prejudice.
      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...

        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.


        Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
        "Science is about questioning the status quo. Questioning authority".
        In the absence of evidence, opinion is indistinguishable from prejudice.
        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...