Dear Martin,
Please take my statements as hints for improvements. You should not be
discouraged by my messages. I haven't tried the
Record(nme:String) ---> String switch myself. There might be issues in
FriCAS, but if there are any, they should count as bugs in my opinion.
Also, while I'm still developing this, its quite useful that the
Untyped domain has a similar sort of structure as the Typed domain and
it could be that future changes might require extra extra information
be held in an Untyped variable.
Since your typed and untyped domain are *very* similar, you should
perhaps factor out common functionality. I'll take a look and probably
suggest a patch later this week. Actually, instead of switching the
representation of Untyped to String, I'd rather unify Typed and Untyped
as much as possible.
(for instance Waldeks idea to use Kernel or SEexpression)
Yes, SExpression might be a good candidate. I guess, even type
information can be encoded there.
Furthermore, I don't really like that the output looks like a string.
What was your reason for choosing this print format?
Again lazyness on my part. I find it quite useful to have a toString
function, in all domains for debug if nothing else, so its just easy
to generate output like this:
coerce(n: %):OutputForm == toString(n)::OutputForm
Oooops. I cannot find something like
coerce: OutputForm -> String
the only available conversion is
latex: OutputForm -> String
but it would be most natural if OutputForm exported something like
algebra: OutputForm -> String
corresponding to ")set output algebra on".
I guess this has not yet been done, because the internals of OutputForm
are done in Lisp (or was it Boot?).
Again, I was thinking of optimising this at a later stage, especially
if more formatting is needed.
Yes, take your time. Rome wasn't built in a day. ;-)
Would you be happy for me to put these things on the to-do list (along
with Waldeks comments about using symbols instead of literal strings
or integers) or do you see them as urgent? (does github have a to-do
list feature that could be used for this?)
Enable "Issues" on https://github.com/martinbaker/fricas/admin and see
whether this helps in some way.
I would be very interested to hear any thoughts you might have about
the top level architectural design of the computation framework.
I'll do as soon as I find time. Keep reminding me.
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.
