On Thu, Jan 21, 2010 at 3:44 PM, Dan Bron <[email protected]> wrote: > 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.
Well... I am trying to express my view of the aspects of Monads which I think would be useful in the context of J, but I am not a Haskell programmer let alone a good Haskell programmer, and I will not be in any position to judge how accurate my current point of view is until after I have written some working Haskell programs that implement Monads. My last attempt at beginning Haskell programming foundered on the "Hello, World!" issue. I will need to carve out some chunks of time to try again, now that better tutorials are available. I currently have my eyes on http://en.wikibooks.org/wiki/Write_Yourself_a_Scheme_in_48_Hours > (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? I imagine so. Here is my (uneducated) point of view: a -> b -> c -> d should be read from right to left. The thing on the far right is the type of the result being produced. Arrows leading to it are arguments needed to get to that point. In other words, a -> b -> c -> d is equivalent to a -> (b -> ( c -> d)). But I get lost shortly beyond that point. I believe that type declarations of the form (word1 word2) declare that word2 is a type which is an instance of class word1 (where "class" is has the haskell meaning of a class of types which has almost nothing to do with the object oriented meaning). But Haskell has other kinds of words (symbols) which can appear in these declarations and I do not understand them all yet. > Or is that middle thing more like the +&1 intermediate > result you mentioned? + would be an example of something with the type Num -> Num -> Num +&1 would be an example of something with the type Num -> Num Note that I am playing fast and loose here, mixing J notation with Haskell, when their parsers operate very differently. I think the Haskell equivalent to what in J would be +&1 would be (+ 1), but I am not yet convinced that the parenthesis do not screw that up. > 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. Er... that is pushing my knowledge (and my handwaving) farther than I am prepared to deal with. I do not even know if I am right here -- I am just working with my impressions. That said, smoutput or smprompt in J could be thought of as very limited examples of a K interpreter. (In K, you typically throw sql expressions or K expressions or whatever at an interpreter, and get analogous result things back -- but it helps there that the default representation of everything in K is its serialized form and that K's serialized form does not have the limitations that J's linear representation has -- J will not allow some linear representations in valid J sentences.) I hope this helps, -- Raul ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
