On Sat, Oct 7, 2017 at 4:53 PM, Martin Baker <[email protected]> wrote: > On 07/10/17 00:59, oldk1331 wrote: >> 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. > > But if you cant agree the form of monad how can you be sure that any maybe > code you introduce will be compatible with it? It seems to me that, to avoid > reworking the library code multiple times, it would be better to have an > overall plan first? If you can't agree that perhaps it would be better to > leave the library code as it is?
My opinion is to do one step at a time. The Maybe change and Monad change doesn't conflict each other and can be done separately. And as Linus said, "Talk is cheap, show me the code." It's hard to get agreement on talk, so it's important to commit code and see how it goes. I think the overall plan is agreed by everyone, just the details to be working on. >> There's another set of natural transformations for Monad: >> >> return : X -> Maybe X >>>> = : (Maybe X, X -> Maybe X) -> Maybe X > > Yes, I get the impression that there are two forms of monad: > 1) The mathematical form. > 2) The form used in Haskell to chain impure code. > > I seem to remember that Haskell supports both, but the second version is the > main form, used in the prelude. Perhaps FriCAS should also support both > forms but since FriCAS is all about mathematics then it should differ in > this respect and the mathematical form should be the main form. The first form needs changes to compiler, that will be difficult. >> 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. > > Is it? > > I did some experiments to compile the interpreter boot code > (src/interp/*.boot) using a more conventional compiler: > https://github.com/martinbaker/fricas2aldor > I guess Waldek would just modify the existing compilers? but I find them far > too messy to work with. Your project is very interesting. But how do you generate static type language from a dynamic type language? My thoughts on this matter: 1. clean up src/interp. Eliminate special/dynamic variables. Make the functions more modular and add necessary documentation. 2. write bindings of commonly used data structure into Spad Domain. So that we can inspect them in REPL and understand it better, and write new compiler code in Spad. 3. It is possible to replace pieces of Boot code by Spad code, see SPADCALL in i-output.boot. I think it's possible to test and replace Boot code by Spad code gradually. (And it will require a running FriCAS to do the bootstrap.) > Its then not difficult to generate SPAD or Aldor or any other language from > this AST. But the problems are: > > 1) how to handle global variables, especially dynamic variables. I think > each function would have to have an additional parameter to pass around the > runtime values of these dynamic variables. I think dynamic variables should be eliminated by hand in Boot files. > 2) The boot 'where' keword seems to hold inner fuctions and variables. How > should inner functions be converted to SPAD? SPAD has lambdas but can SPAD > lambda capture variables (closures)? SPAD lambda isn't closure. That's another thing needs to be fixed in compiler. > 3) The native Lisp code would have to be translated by hand, to handle > input/output to console, files and database (which would be different for > each language). That's the runtime, it needs a clear specification and clean up. > Perhaps another option would be to just translate boot to SPAD manually but > that's hard because Boot/Lisp passes everything around in global variables > whereas well written SPAD should encapsulate information in domains. This > means you cant just translate one function at a time and check if it works > before going on to the next. Like I said, it's possible after we get rid of special variables. >> Yes. Common Lisp can do parallel computing but it's not standardized. >> I think provide a parallel version "map" solves 50% problems. > > I get the impression that Waldek will not make any changes to library code > that is not supported by all Lisps? Is that correct? I get the impression I think he is open to that. He wrote the GMP bindings for SBCL and CCL. > there is a lot of natural parallelism in mathematical code, for instance: > vectors, would 'map' make use of all of that? > > Martin B What I said is, one can manually use parallel map for hotspot found by profiler, not automatically. A deeper integration of parallelism into code base will require more work. -- 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.
