On Fri, Oct 6, 2017 at 11:40 PM, Martin Baker <[email protected]> wrote: > > I get the impression that you now agree that monads are not currently > practical in Fricas? However I still have hopes that, in the future, the > type system in Fricas may be enhanced to allow monads (am I wrong to hold > out hopes for this?). If this might be possible in the future then I think > maybe should be implemented in such a way that it could be made an instance > of monad to avoid re-working the library code a second time.
Monad is practical in FriCAS. But just like this time, we couldn't agree on a lot of things. So instead of introducing Monad first, Maybe later; I think introducing Maybe first, then add Monad later will be easier. > Also the terminology is well known from Haskell (where maybe is an instance > of monad) so its best not to diverge from that unless necessary for a > genuine mathematical reason. In previous discussion on Monad, we couldn't agree on the name 'Functor', because we already use that for Domain Constructor. I agree with you that we should borrow terminology from Haskell instead of introducing new one. > I believe that monads are an (endo) functor with two natural > transformations: > > M M X -> M X > X -> M X > > In the maybe instance: > > Maybe Maybe X -> Maybe X > X -> Maybe X That's another difficult for Monad in previous discussion. In Category Monad, you can't express signature like "Maybe Maybe X", where % stands for Maybe X. There's another set of natural transformations for Monad: return : X -> Maybe X >>= : (Maybe X, X -> Maybe X) -> Maybe X > I'm not sure about the practicalities but perhaps to chain something like > subtractIfCan would require a signature like: > > (Maybe X,Maybe X) -> Maybe X > rather than: > (X,X) -> Maybe X > > but I have not really thought this through. Does anyone know how Maybe is > used in Haskell? It's the >>= I mentioned above. It can chain single argument functions together. f : X -> Maybe X g : X -> Maybe X a >>= f >>= g > For me the most important thing is to optimise for simple and readable code > rather than optimising for performance. Perhaps if Fricas were simplified it > would be easier to move to a better type system. In fact I have issues with > all this diminishing returns performance optimisation. If things could be > made simpler perhaps Fricas could be built on top of other languages than > Lisp. I thought Krystian s project might move things in that direction? Waldek has this plan that the compiler should be written in Spad, so targeting other languages is a matter of new code generator and runtime. That is a far far goal though. > The way computer hardware is evolving with more core it seems to me that, if > you really want to optimise for speed, then multithreaded code is the real > future. So we need to move away from Lisp rather than optimise around what > Lisp happens to do fast now. > > Martin B. Yes. Common Lisp can do parallel computing but it's not standardized. I think provide a parallel version "map" solves 50% problems. -- You received this message because you are subscribed to the Google Groups "FriCAS - computer algebra system" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at https://groups.google.com/group/fricas-devel. For more options, visit https://groups.google.com/d/optout.
