Bill Page <[email protected]> writes: | On Mon, Dec 5, 2011 at 6:37 PM, Gabriel Dos Reis wrote: | > Bill Page <[email protected]> writes: | > | > [...] | > | > | I reported this as a bug in OpenAxiom | > | | > | http://sourceforge.net/tracker/?func=detail&atid=984524&aid=3448475&group_id=203172 | > | | > | Recent changes in OpenAxiom have changed the error message. The | > | original message "cannot form Join" is probably more indicative of | > | what is going wrong. The "apparent user error" | > | > It is indeed "apparent user error" :-) | > | > When you write | > | > MySet(T:SetCategory): Join(MonadCat(T,MySet),SetAggregate(T)) with --... | > | > At the point where you are using MySet as argument to MonadCat, there | > is no indication of what the return type of MySet, and that is apparent :-) | > | | There are numerous cases in the library where % occurs in the type of | a constructor.
MySet is a functor not a domain, you are defining its *return* type by using it in positing where the return type is expected to be known, i.e. when the compiler is expanding MonadCat(T,MySet) to see whether it makes sense as a category. % is a special variable in that it is the only one in the system (if my count is correct) that implements a co-inductive fixpoint. Furthermore, it is a domain, not a constructor. And the current implementation of co-induction semantics for % in the compiler is "quick and dirty" hack, see line 1075 of http://svn.open-axiom.org/viewvc/open-axiom/1.4.x/src/interp/define.boot?revision=2519&view=markup [...] | Is this use of % somehow special to the compiler? Yes, see above. | In another email thread I was asking for a method to refer to just the | functor, e.g. just 'OrdinaryDifferentialRing' not the whole | expression 'OrdinaryDifferentialRing(Kernels,R,var)'. Suppose this | was denoted by %%. Then | | %%(Kernels,R,var) | | would supposedly be equivalent to %. | | This %% is essentially what I wanted to write instead of 'MySet' | above. It seems to me that whatever is special about % could also be | special about %%, no? Yes, sort of. For OpenAxiom, I would prefer to have a general principled mechanism to write co-inductive definitions than special variable hacks. Or, maybe all constructors should be co-inductive and only ordinary values should be inductive I do not know yet. This kind of co-inductive-style use is quite popular in mainstream languages such as C++, Java, or C#. Usually it comes at some price -- e.g. you would have to accept that the compiler can't catch some "useless" definitions which might be result of typos as opposed to intentional or mere curiosities. [...] | Is possible to reference MySet implicitly as "this functor" in a | manner similar to the use of % ? As I said above, for OpenAxiom I would prefer a principled way to write co-inductive definitions and not introduce yet another special variable. If I have two, then surely I will have three; so I would prefer to have a general feature. This needs some thinking. [...] | > I appreciate bug reports in experimenting with new constructs. | > One should also note that transliterating Haskell into Spad can be | > as fun and entertaining as transliterating English to French or the | > other way around. Certain things will just sound OK; others might | > give you a pause :-) | > | | Sure, but the abstraction of "monad" really has nothing directly to do | with Haskell of other languages as such. It seems reasonable to | consider independently how this notion should be expressed in Spad. I hope nobody is under the illusion that I believe the mathematical notion of monad is Haskell-specific. My observation was merely related to the fact that since the beginning I was under the impression that people are saying "here is what people write in Haskell as monad; how do I write that code in Spad?" -- Gaby -- 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.
