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.
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.
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.
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
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?
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?
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.
--
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.
