Bill Page <[email protected]> writes: | 1) Does this code (in principle) capture the notion of Monad?
For me, it is just a set of signatures; I should NOT be the person being asked to reverse engineer what you wrote! :-) | 2) If yes, is it useful? How to use it? I do not know how useful it is until you've shown concrete examples (Spad) illustrating why you wrote it in the first place and what it is useful for. | 3) Why doesn't this compile? (Discussion of function versus functor.) It compiles in OpenAxiom. I do not see a fundamental reason why it should not compile in other AXIOM flavours. | 4) Is there another way to write it that does compile and that would | be a useful way to represent a monad-like construction in Axiom? It compiles; I have no idea how you wanted to use it, so I cannot tell you whether it is useful. | 5) What would have to change (if anything) in Axiom to allow it or | something similar to compile? At the moment, the definition you gave (when properly written in Spad syntax) compiles. That alone does not say much to me, because I do not know exactly how you are using it. So far it is just a category! | 6) Should we be able to pass functors as arguments, store them in | variables, etc. the way we do with functions (and as implied in the | original Axiom literature)? Which functors do you want to pass? Example of code. | 7) What type (if any) should be associated with a functor? Every functor in AXIOM has a type. You get it by executing )boot getConstructorSignature ctor where <ctor> is the name of the constructor you want, e.g. 'List, 'Integer, etc. You get the target type by )boot getConstructorSignature(ctor).target and the list of arguments types with )boot getConstructorSignature(ctor).source | Note: Here functor, like function, refers to a constructor that is | unapplied but applicable. understood. | For example in OpenAxiom you have a Maybe domain presumably modeled | after Haskell (or perhaps modeled after whatever the Haskell Maybe | type is modeled after). In Haskell Maybe is an example of a monad. The *concept* of a monadic type to indicate possible failure has always existed in AXIOM. To express that in Spad, you just form Union(T,"failed") where T is the actual data type in case of non-failure. However, that -expression- of the idea of monadic type has its own set of problems, starting with serious hackery in the Spad compiler, including inefficiency such as consing every time one performs an operation on SingleInteger that might fail. Consequently, I decided to have a better expression of the idea of failure monadic type. I decided on the name Maybe (from Haskell), as opposed to 'option' (from ML, which existed before Haskell was invented.) So, yes I took the *name* from Haskell, but my primary goal was not to write Haskell in Spad. Rather, I was looking for a name to designate a type I designed as an efficient expression of an idea that already existed. To be clear, I am not claiming that the notion of monadic type is special to Haskell or Spad. It is an idea that exists in any serious programming language that I have used -- C/C++ (null pointer to represent absence of information), Lisp (certain usage of NIL), Java/C# (null references), scripting languages, etc. | (Perhaps not such a good example?) If we could code "monad" explicitly | in Axiom and assuming it could be implemented efficiently, could we | code domains more general than Maybe without any other special | built-in support? As ever, my question has always been: to what end? What *problem* are you trying to solve? Why is that solution better than the alternatives (for a definition of "better")? If I do not know what problem you are trying to solve, how do I know that what is being proposed is in fact a solution to a known/serious problem in Spad? | Would this allow SPAD to be a more purely functional | language? Would that be a good thing? What problems are you trying to solve? Sorry for asking again. I must ask because I do not understand the goal. | Is this a useless exercise? Maybe we should stop? I do not know. You tell me. And this is not rhetorical. I am just having hard time understanding the problem you are trying to solve, and why it is a problem. -- Gaby ------------------------------------------------------------------------------ RSA(R) Conference 2012 Save $700 by Nov 18 Register now http://p.sf.net/sfu/rsa-sfdev2dev1 _______________________________________________ open-axiom-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/open-axiom-devel
