Hi Sergei,
last night I was thinking a bit of a good design for a generic interface
to any external program not only Haskell.
The idea is similar to what I stated before. I don't bother with output,
since that can usually be generated in an appropriate format by simply
turning it into OutputForm and write a special transformer that returns
what is wished (algebra format, tex format, html, mathml, etc.)
For the input I see two approaches.
1) FriCAS basically already gets a collection of strings that contains
the expression already in a tree form. Then the task would be to turn
the tree form into an element of the requested type.
2) FriCAS gets a big string of input, with enough information about
types. Then the respective type is asked to parse the string where for
subparts this parsing procedure might (actually should) delegate parts
of the parsing to "subtypes" of the corresponding type. ("Subtype" is
somewhat wrong, what I mean is that for example Fraction(Integer)
delegates part of the parsing to Integer).
I believe that (2) is more flexible, but I somehow get headaches, when I
think about where to implement the parsing of
gcd(2,3)
if it is known that 2 and 3 are of type Integer? For gcd it might be
easy to have this implemented in Integer. But what about such functions as
zero?(3)
does it belong to Integer or to Boolean or to none of both? And
"groebner"? That usually lives in a package and is not attached to any
domain.
If one doesn't want to write another Interpreter for all expressions
then the really simplest way is to embellish the input string with all
type information and let the FriCAS interpreter do the parsing work.
(1) -> Z := Integer
(1) Integer
Type: Type
(2) -> Q := Fraction Z
(2) Fraction(Integer)
Type: Type
(3) -> P := SparseUnivariatePolynomial(Q)
(3) SparseUnivariatePolynomial(Fraction(Integer))
Type: Type
(4) -> N := NonNegativeInteger
(4) NonNegativeInteger
Type: Type
(5) -> x: P := monomial(1$Q,1$N)$P
(5) ?
Type:
SparseUnivariatePolynomial(Fraction(Integer))
(7) -> NP := PositiveInteger
(7) PositiveInteger
Type: Type
(11) -> p:P := ((3::Q*x^(4@NP))$P + (((-7::Z)/(4::Z))$Q*x)$P)$P
4 7
(11) 3? - - ?
4
Type:
SparseUnivariatePolynomial(Fraction(Integer))
Actually, I would have been more happy if the interpreter understood the
following
p:P := ((3@Q*x^(4@NP))$P + (((-7@Z)/(4@Z))$Q*x)$P)$P
but obviously the parsing is similar to Aldor where a type must have a
function: integer: Literal -> % in order to understand integer like
literals directly, only that FriCAS always seems to end up in
PositiveInteger instead of Integer directly.
By "embellishment", I mean the @SomeType construction, where I hope that
then the interpreter would have a clear hint what to parse. Maybe
currently that is mostly unused except that it's used after the parsing
of the value is done. Waldek?
Anyway, as you see already for polynomials. Transferring data from any
program to FriCAS means to *construct* the FriCAS internal datastructure
again and again. So unless you don't keep the fricas session open and
refer to previously computed data, that is probably a big waste of time,
in particular if the function you want to compute with FriCAS takes only
milliseconds.
So one should really think what the actual goal of a Haskell-FriCAS
connection is. Is it
(a) Let the user only see Haskell (DoCon) and do FriCAS computations in
the background, or
(b) give a Haskell user a way to drive a fricas session with a Haskell
"look & feel"?
I think both these options have been tried in Sage already. I have the
feeling they are not a big success there.
Ralf
--
You received this message because you are subscribed to the Google Groups "FriCAS -
computer algebra system" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/fricas-devel?hl=en.
