The matter is the aim:
to implement in Spad only one function (dParse):
fast parsing from a list of strings to an arbitrary domain
potentially built by a certain fixed finite set of constructors:
Integer, Fraction, Polynomial, ResidueRing, Vector, Matrix
(may be, 3-4 more).
Well, if you start with the goal of just writing one function, then this
is one of the rare cases where I would suggest to use Any.
The reason for this suggestion lies in the way Any is implemented.
https://github.com/hemmecke/fricas-svn/blob/master/src/algebra/any.spad.pamphlet#L106
Rep := Record(dm: SExpression, ob: None)
If you study the code more closely then you will see that the dm part of
this record encodes the type of the second part.
In fact, it is the SPAD way of writing something that you can better see
here.
https://svn.origo.ethz.ch/algebraist/trunk/aldor/lib/axllib/src/object.as
Usage is here... http://www.aldor.org/docs/HTML/chap23.html#10
The name "Object" in the Aldor file is well chosen, since it is what
other OO languages do, i.e. storing type information together with the
runtime object.
In SPAD, you'd encode it into Any. That is what I meant with
>> "Any" might be useful in rare cases and it still contains *more*
>> information than an ordinary expression in a typeless CA system
In fact, Any contains the type of the object, but where in Aldor it is
clear how to actually use that type information, I have no clear idea
how to do that with spad.
Translating object.as and http://www.aldor.org/docs/HTML/chap23.html#10
into SPAD is probably currently impossible. And, in fact, I don't know
whether it really solves your problem.
Since you actually will most probably send the strings from Haskell to
FriCAS, I wonder whether it would be a good idea not to do it as a
typeless string but rather prefix it with a type information string that
can quickly be parsed. If there is no type information, it will have to
be _guessed_ by FriCAS (which could be wrong).
How much freedom do you have to prepare your list of strings before you
send it to fricas?
I guess the FriCAS parser is not fast enough for you and that is the
reason to create your own parser. Nevertheless you must end up in
putting your parsed expression into some FriCAS domain, because
otherwise you cannot use any function from FriCAS. Even if your result
domain is "Expression(Integer)" there will then be need for routines
that coerce your expression to DMP([x,y,z],FRAC INT) which may be
costly, but are the only way to call concrete FriCAS functions. Note
that everything in FriCAS is done in a "domain of computation" (domain
for short). So you need a concrete domain to do the computation. How do
you currently select this domain?
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.
