(I like your convention of capitalizing Haskell's Monads to distinguish them from J's monads, and I'll adopt it from here)
> 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. > 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. > "Monad" also seems to refer to design patterns which > use this kind of mechanism. Ah, I didn't realize that Monads were so inextricable from Haskell. That clears up a lot of my confusion, and explains why I didn't understand a lot of what I read about them (authors tended to conflate these distinct topics, both of which are new to me), and why I could never get a clear definition of a "Monad" as an abstract thing implementable in J or any functional language. > 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. > 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. > Monads tend to be designed to discourage people from > holding on to references to "the state of the world". > 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 ^:_ Yes! The light has dawned. This was very, very helpful. Thank you. I encourage you to post this on the Wiki, so that the next non-Haskell schmoe who googles for Monads can get some relief. (This multi-clause thing, is this why Haskell function declarations sometimes have the form "domain -> (something else) -> codomain" as opposed to the "domain -> codomain" declaration I would expect, not coming from the Haskell world? Or is that middle thing more like the +&1 intermediate result you mentioned? Anyway multiple clauses for different domains in one function seems useful.) > Nevertheless, for Monads to work we need to introduce > something -- in J this would be very like a noun > 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". > 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. I got a little lost here (I need to spend more time looking at K). I know it's a lot to ask, but it would be much easier for me to visualize if you posted examples of a pseudo-J that took the Monad approach vs one that took the other, contrasted them, and showed what kind of concepts such a J would make it easier to express (than our existing J). Or just the "K interpreter" approach if you really feel Monads are a poor fit for J. The one random bit example would be just fine. -Dan PS: > I will agree that type systems can sometimes be useful, but given the > way people usually use them -- and represent them -- I feel they invite > unnecessary complexities. This is just the right way to express it. My only experience with type systems is with object-oriented programming, but my feeling about them is that programmers who use them end up doing a lot of "typing" at the expense of "programming", and that furthermore they lead to overengineered designs (which is already a tempting trap for the kind of people who get into programming). But whenever I tried to express this sentiment, I was accused of attacking (and being generally ignorant of) type systems. But you are right that it is not that type systems are problematic per se, only that they tend to invite overengineering (by programmers). When I was just transitioning from OOP to J, I was understudying Kirk Iverson on a project. At one point or another he wrote a function he was applying to strings. I don't remember what it was, but let's say it was cutting up the strings. I asked him "If you intend to apply this to strings, why don't you enforce that, or at least document it?", his reply was "What if someone wants to apply it to something other than strings?". And he was right, it was a more general function and it did find uses outside of the string domain. He actually felt very strongly about this philosophy and we discussed it on more than one occasion. > have problems with perfectionism It would imperfect to call me a perfectionist :). I'd say (one of) my flaw is completionism. Case in point. ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
