Alexander Solovets wrote: > > > I fetched your 'fricas-plugin.tgz' > > but clearly it assumes initialization via '.fricas.input'. =A0I have > > now working Texmacs and I hope to work out needed changes in next > > days. =A0Of course if you provided updated version it would be > > faster. > > > BTW2: We probably should put (updated) content of 'fricas-plugin.tgz' > > in 'contrib' subdirectory, so that somebody trying to use the interface > > has all pieces handy. > > My fault, sorry. Of course there is newer one, look at the attached archive= > .
Thanks, I have now commited changes to axiom/fricas script. Looking at formatting routines I think that there is time for a cleanup. I did some limited cleanup of TMFORM (and added support for prescripts) current version (and a diff) is at: http://www.math.uni.wroc.pl/~hebisch/fricas/TMFORM.spad http://www.math.uni.wroc.pl/~hebisch/fricas/TMFORM.diff However, I think more changes are needed. First, currently OutputForm uses mixture of symbols and strings. I would standarise and declare that a form either is a Lisp atom (which in particular may be a string) or a list such that the first element ("operator") is a symbol. One possible reasun for current use of strings is that in symbols we need to escape special charaters -- I find escaping acceptable, but alternatively we may write strings and immediately coerce to symbols. Next, MathML format currently tries to parse OutputForm to reconstruct derivatives (from superscript primes) and continuous fractions (from ZAG-s). This code has serious problem -- current version which parses textual representation of OutputForm basically can not work correctly, but even if we change it to work on level of S-expression it still will be somewhat unreliable. So, I think that if MathML really needs to know about derivatives, then we should change OutputForm so that derivatives would use different operator than superscripts. Similarely for ZAG (however, it would be better to somewhat represent ZAG in MathML, because big continouous fraction printed as fraction is harder to read than the same fraction printed using ZAG). To some degree the same applies to Texmacs and Html formats since they borrowed code from MathML. Next, currently some convertion routines output result of conversion -- this is wrong: convertion should be silent and the output should be done by 'display'. Finally, it looks that significant part of output formatter analyses form, handles priorities and dispatches to elementary operation. AFAICS we could share this code by changing formatters to be categories: top category would contain common code, specific format would provide primitives. Note: we need categories to get OO-style dispatch. -- Waldek Hebisch [email protected] -- 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.
