On 6 October 2017 at 11:40, Martin Baker <[email protected]> wrote: > On 01/10/17 04:49, oldk1331 wrote: >> >> Again, I think this is a small problem, because >> 1. there's no point of using Maybe(Maybe(XXX)). > > I have not followed this thread closely so apologies if my thoughts here are > off track. >
Not at all. Thanks for contributing. > 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?). I think you are not wrong to continue to hope. :) > 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. > +1 > 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. > > 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 > > So I think Maybe Maybe X is a fundamental mathematical requirement. +1 > This seems to be about how Maybes are chained which is the practical > purpose. So when chaining this things you could write: > > Some partial function > if "failed" then handle error > next partial function > if "failed" then handle error > next partial function > if "failed" then handle error > ... > > This seems very messy with lots of repetitive code. What I would like to do > is this: > > Some partial function > next partial function > next partial function > if "failed" then handle error > Do you mean something like this: failed? f(g(h(x)) where f, g and h are "partial functions" with signatures like e.g. 'Integer -> Maybe Integer' map(f,map(g,h(x))) would return a value of type 'Maybe Maybe Maybe Integer' and the natural transformation you mention can reduce that to a single 'Maybe Integer' with a final testable result. I think oldk's current proposed specification for 'Maybe' with a single global representation of 'failed' would make testing the final result easy but the resulting type is still awkward, requiring 3 'unwrap/retract' calls to return an Integer value. And this proposal would making testing for intermediate failures impossible. > 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? > This is not a problem using the 3 argument form of 'map' in Maybe. (See my "reference version" of 'Maybe(R)' using 'List(R)' as a representation.) > 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? > +1 > 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. > I agree. I think it is a good idea to try to avoid adding more Lisp dependencies to the FriCAS library. But we can still depend on code generation in the SPAD compiler and even Lisp to do whatever optimizations are possible at those levels. Some day there may even will be a SPAD compiler that generates LLVM code instead of Lisp. But in any case, the choice of representation can make a big difference depending on just what optimizations are available. For example the 'List(R)' representation can make testing for failed very fast (using oldk's inlining enhancements) but at the cost of using a little more space and a bit of time for unwrapping non-failed values. At this point in the discussion I am again leaning toward this alternative. Bill Page. -- 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.
