On Fri, Jan 22, 2010 at 8:53 AM, Dan Bron <[email protected]> wrote: > I say that because as I mentioned in those earlier threads, I'm looking for > a definition or understanding of Monads that can be implemented in J, which > has no type system (or any other functional language which doesn't also > happen to have an algebra of types). Also, I'm a bit biased; I have no > particular affinity for type systems. > > So, my question is really: can Monads be defined independent of a type > system? If so, can you describe the advantages they'd provide?
I think the answer is yes. That said, as a caution: you could say that Monads are already implemented in J, that J's symbol table and its I/O mechanisms and so on represent access to them, and that they have been concealed so that the programmer can not access them directly. Note also that even if all assignments in J were "single assignment", the symbol table would still necessarily be monadic in character (because until a name has been defined it would be undefined). Anyways, here's an example of how Monads could become more explicit in J: First, you will need Monads to be a new type. There is no getting away from that. Monads are not like any other kind of noun in J. Second, this will be easier for me to describe using example than using formalities. So: imagine that J has a new data type representing "the state of a file". Let us also ignore the whole mechanism of how you get this thing in the first place (because that gets into the whole "J is full of Monads already" issue, and we need to start some place simple). Now, let us imagine a primitive in J which operates on this new data type. 10101!:1 will take this Monad and return the entire contents of the file at that time. We could also define a primitive in J which updates the file, based on its earlier state and some new contents. We have to be careful, here, however because if we do not get a reference to the file in its new state we get into the problem that we are ignoring how we get the original Monad -- we would more or less lose the ability to read the updated file. So, 10101!:2 will take the Monad and the new file contents and return a monad which represents the updated file. We could add a third operation 10101!:3 will take the Monad and return a new monad which possibly incorporates outside changes. So, now, let us get a bit fancier -- let us define Monadic operation 20202!:2 which takes a monad representing the state of the console and a string and returns a new monad representing the updated console (after that string has been output). Hypothetically speaking this could serve a role somewhat like smprompt. We could also define 20202!:1 to take this monad and return boxed list containing a string read from the console and a monad representing the updated state of the console. And there you have some illustrations of how Monads could exist in J, with a J-like flavor. Of course, they lose some of their "Monad character" in this process. For example, those beloved type signatures sort of fade into the woodwork. And of course these things would be inherently not useful in Haskell, because they are in J. -- Raul ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
