Thank you for the helpful comments, Raul. My main desire in that effort has been to understand what Haskell's monads and arrows *are*, without going to the trouble of learning that language in depth. The easiest way for me to understand things at this time is in terms of J.
I have noticed that the differences in type systems seems particularly important. In my faltering attempts to build parallels in J to Haskell code examples, I anticipated building types as boxed structures. There loomed the enormous difference between having those manually defined entities supported by manually-built qualifiers, and having custom-defined types supported by the native typing features of the language. But I was not yet at the point where I could identify whether custom types would be necessary to match the features of monads. I'll have to follow your clue that they rely on streams. My larger purpose in looking at Haskell's monads and arrows has been to improve my understanding of functional programming so that I can apply that understanding as I code in J. As I said, most of my struggle has been in trying to get a clear sense of what it is that Haskell programmers are trying to accomplish as they manipulate and refine their code with these techniques. In the simple examples I've seen, everything looks just like J to me. Then a threshold is crossed where it's too different for me to see in terms of J. Oh, well. Thanks again for helping me see some of the particulars which make up these differences. -- T On Sat, Nov 29, 2008 at 9:41 AM, Raul Miller <[EMAIL PROTECTED]> wrote: > On Sat, Nov 29, 2008 at 8:01 AM, Tracy Harms <[EMAIL PROTECTED]> wrote: >> Taking tacit expression as a pure-functional portion of the J >> language, how can this solution be effected? For some weeks I've been >> trying, unsuccessfully, to envision J equivalents to Haskell's monads >> and arrows. > > I am not sure that J's type system allows for monads. > > Haskell's monads are built on streams which, in the Haskell > world have the same data type as lists, but a different data > type from the elements which make up the lists. > > In J, elements and lists have the same data types but > different shapes. However, J's type system does not > support streams (infinities in shapes). > > (Thus, for example, in J you can not directly define the > data structure representing all the results you would get > from 1!:1 bind 1 or even from <@(1!:1 bind 1).) > > If you adopted a sufficiently expressive convention for > the representation of streams in J, you could build up > monads from there, but this would probably be very > inefficient. > > Also, personally, I find the use of side effects no more > distasteful than the use of infinities. (I am not opposed > to using infinities, but implementations of infinities > are as quirky as implementations of side effects.) > > That said, if you have a generator (like 1!:1 bind 1 > or 1!:1 bind 1 ; ] or some function built up from there), > you can easily apply it repeatedly, using recursion or ^: > and if you are satisfied with that, you could call any such > recursion or repetition a monad. But you do not get the > syntactic sugar of Haskell's monads from this. > > -- > Raul > ---------------------------------------------------------------------- > For information about J forums see http://www.jsoftware.com/forums.htm > ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
