On Thu, Jan 21, 2010 at 10:41 AM, Dan Bron <[email protected]> wrote: > I think the best kind of simplicity is well-packaged complexity.
I agree with this sentiment of yours. > So if monads allow me to express complex topics simply (i.e. > I can outsource detail management to them), then I'm all for them. Likewise. Nevertheless, for Monads to work we need to introduce something -- in J this would be very like a noun -- to capture and encapsulate a certain class of side effect. And I just can not see a good way of doing that. It's certainly doable, but it seems to me that it is too low level of a concept. The right way to approach this issue, I feel, is from the other side -- perhaps something like the K concept of an "interpreter". In both cases, you have side effects and you have encapsulated them, but when you try to start from the simplest possible side effects and build up from there I feel that you have to push too many of their complexities into the rest of your system. To see what I mean, imagine starting with a "pure version of J" and then adding abilities to access various kinds of resources through a mechanism like monads. You wind up needing some way of representing, within J, "resource access". And, for this to be robust it can not be manipulated by the code which is being granted access and yet it must deal with a variety of complex issues. A better approach, it seems to me, puts those complexities on the other side of the fence, where manipulating them can be done robustly, without resorting to micromanagement. > And this thread (and Viktor's previous related thread) is > of great interest to me. So much so that I haven't even > read it yet, because I haven't had the time to give it the > attention I want to. Unfortunately I'm completely ignorant > when it comes to monads in the Haskell sense, as I am > about all Haskell or functional programming topics outside of J. Ouch, but yes I also have problems with perfectionism getting in my way. > I've tried dipping my toe in the topic before, but I was never > able to find a clear, concise definition of what a monad even is. > Every article on them seems to start with "Monads are such > and such, but not really", and everyone seems to define them > differently (of course, this could just be because monads are a > very abstract things that can be viewed multiple ways, or because > different people have different perspectives on the same topic, or > both). Yes, this issue was one of my objections to Monads -- it is fairly easy for me to find false statements about Monads. This indicates to me that they are hard for people to understand. Such statements would not go uncorrected and unchallenged if very many people understood what they were talking about. > My current understanding is along the lines Raul quoted: that > is, a monad is a way to package up "the state of the world" as > an input, to be (explicitly?) passed to a function, so that we can > say the function has no hidden inputs, and its output is fully > determined by its inputs (so that if you called the function again > with the same inputs, including that snapshot of "the state of > the world", you'd get the same output). In addition to this, I have > the vague sense that monads are a syntactic convenience (but > not knowing Haskell or what its syntactic hurdles are, I can't know > this). I will agree with this point of view, with a few caveats: This concept of "the state of the world" is an abstract characterization. Other abstract characterizations are possible. That syntactic convenience thing is a core feature of the haskell implementation. Some of the ideas behind monads might be seperable from the haskell implementation, but if they can be factored out they probably should not be called monads any longer. > I would be very excited and grateful if someone in this thread > posted a clear, and more or less comprehensive, definition of > a monad, in a way someone who's familiar with J but not other > types of functional programming could relate to. Or maybe a more > concrete and direct approach would be to say "here's the kind of > thing we could express in J, if it had monads" (forgive me if > someone already did this). Well, we can not do monads in J, because J is not Haskell. And, I am not a Haskell programmer, and I am certainly not a good Haskell programmer. But I can try... please note that this is based on my current understanding and may contain embarrassing mistakes. First off, monads are about dealing with state which comes from somewhere other than the definition of your program. The simplest external state would be one random bit. So, let us imagine a world where you have pure functions and this impure function which has its own state. How do you incorporate in your definitions something which has been introduced solely because it is undefinable? This should be easy, right? You just pass the result of one random bit to a function? Well, no, you can not do that in Haskell. Haskell is strongly typed and this external state stuff has to have its own type. So you can only pass stateful values to stateful functions. Most treatments of Haskell monads wind up using this as the example statefulness. However, Haskell functions can have a lot of clauses. For example, you might define a function twice, once for its initial case and once for its recursive case. Also, if we talk in J terms, all Haskell functions are monadic, rank zero, verbs. So, for example, to implement 1 + 1 in haskell you have to have an intermediate result of +&1. (List definitions must also be defined with list fragment intermediate results.) Anyways, Monads are how you build functions which can take both stateful and stateless arguments, cast into this definitional framework which Haskell provides. Of course, J has its own issues where this kind of abstraction might be useful. Probably the best kind of case would be where we need result state and intermediate result state for a verb which uses ^:_ However, in J, when we provide two definitions for a name the second definition replaces the first name. In Haskell they must both be valid. Anyways monads are, essentially, haskell functions which take as argument a stateful value and a pure value and has a result which is a stateful value and a pure value. You can also have degenerate cases where some of this gets left out. Needless to say, there is a small amount of of complexity involved in representing all of this in terms of what a J programmer might think of as "monadic rank zero verbs". Also, since this issue covers a lot of ground you can legitimately find people with different perspectives on it. Anyways, "Monad" seems to refer not just this general concept (and, for mnemonic purposes, you might think of wedging two kinds of values in and out of monadic verbs) but "Monad" also seems to refer to design patterns which use this kind of mechanism. > For my part, I'm going to go read the Wikipedia article > Raul quoted (for all my toe-dipping, I never read the WP > article on monads, which is silly, seeing as how WP consciously > tries to present topics in a way accessible to the layman > unfamiliar with the topic), then the previous posts in this thread > (which I hope the WP sheds light on). Er... keep in mind that I was using that wikipedia article to illustrate how people get confused by monads. Finally, I want to reiterate that I was objecting to monads as they are currently implemented in Haskell, and not to some of these abstract concepts that I have tried to use to describe monads. -- Raul ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
