On Monday 05 Dec 2011 02:07:45 Bill Page wrote: > > Another idea that occurred to me would be to have an equivalent to the > > Haskell typeclass. Like a higher order (non-concrete) category, say a > > category where all the function parameters and returns are only > > specified in terms of types (not values). So the equivalent to the > > Haskell typeclass might be: > > > > )abbrev hcategory MONADC MonadCat > > MonadCat(M):Category == with > > join: M M A -> M A > > Except for omitting the type of M, I do not see much difference from > what I wrote above. > > > So this could be implemented with 'M' as say: > > Integer -> Set Integer or Set Integer -> Set Set Integer ... > > I don't think this makes sense. M must be an endofunctor, i.e. > something like 'Set' itself. > > > Ideally 'A' would only need to be defined in join. > > As I described T above, A must be the formal parameter of the monad > MySet as the endofunctor M .
This is a difference between what I wrote (which seem to me to be the Haskell way of doing it) and your code. Because- M=Set A=PI gives: join: Set Set PI -> Set PI M=Set A=Set PI gives: join: Set Set Set PI -> Set Set PI M=Set A=Set Set PI gives: join: Set Set Set Set PI -> Set Set Set PI So the same category represents all these, but not if A is a parameter of the whole monad, this seems to me quite a fundamental aspect of monads which your code does not support? > > As I say, I'm just trying to get these issues clear in my mind and to > > try to understand if SPAD will ever be as powerful as Haskell with > > this type of construct. > > I do not see any reason to claim that SPAD is somehow less "powerful" > than Haskell even as it stands now. To be sure both SPAD and Haskell > (not to mention, Lisp, C and assembler language, etc. ) are formally > universal. The concept of the "power" of a language is almost too > vague to be useful. Even the idea of the "expressiveness" of a > language is hard to quantify. How much "effort" it takes to write code > in one language or another is highly subjective. To a large extent it > comes down to a choice of style. When I said "powerful as Haskell with this type of construct" I specifically meant Haskell seems more powerful in the ways that it can match on and combine these higher kinded types (I still get that impression but perhaps I'll be proved wrong). It goes without saying that SPAD is more powerful in other ways such as dependant types. I hope you did not assume I was knocking SPAD in general, I do think it helps to be clear about specific strengths and weaknesses of each language. Martin -- You received this message because you are subscribed to the Google Groups "FriCAS - computer algebra system" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/fricas-devel?hl=en.
