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?
> 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.
>> 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.
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.
I managed to compile this boot code to an Abstract Syntax Tree (AST) I
then wrote a code generator to write AST back to boot code. This code
was different from the original (because the AST does not store format
information) but when I compiled to Lisp the code generated was
identical - all lines (except those starting with ';') were identical.
So I am sure my AST contains all the information from the boot files.
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.
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)?
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).
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.
> 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 there is a lot of natural parallelism in mathematical code,
for instance: vectors, would 'map' make use of all of that?
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.
