Martin Baker wrote:
>
> I have put a proposal for a project to change how FriCAS formats output
> here:
> http://www.euclideanspace.com/maths/standards/program/mycode/output/
>
> I've just realised my use of the word 'project' could be confusing here, I
> should stress that this has nothing to do with any GSoC projects, although
> it seems very complementary to what Krystian is doing, which is why I
> suggest it at this time.
>
> I would be willing to help out with such a project, if you thought it would
> be useful, although I would need a lot of help.
>
Some comments. I am not aware of anybody using script formula
output, so it probably can be safely scrapped. The other
formats all are useful.
You ask ' Where is algebraFormat (mathprintWithNumber) defined?'.
'mathprintWithNumber' is implemented in 'i-output.boot'. If
you ask about description of the format, then code is all
we have.
You ask about Rep for formaters. AFAICS HTMLFormat, MathMLFormat
and TexmacsFormat really are packages. There are no way to
create data of those type, so no need for Rep. ScriptFormulaFormat
and TexFormat have represetation as records which are used
to store prolog and epilog data. IIUC this is because those
formats need to send some setup data at start and close data
et the end. Trying to put such data around each separate
piece of data would be problematic. However, it appears
that this functionality is not used by FriCAS, so it seem
to be just a little convenience for some users. AFAICS
this could be removed from formatters, and if needed
provided by generic wrapper.
Use of OutputForm in SExpression can be easily removed:
related functions are only used in genufact.spad and
fortran.spad. Deeper problem is that fortran.spad
apparently assumes that OutputForm = SExpression and
passes values to Boot code with little regard to types.
Note that defining something like OutputForm2 will help
only a little, because code in fortran.spad is supposed
to work on OutputForm, so you would need to keep
all current mess supporting OutputForm.
Concerning using more operators, note that all parts
involved: coercion to OutputForm and formatters need
to know about operators. To allow easy adding of
new operators we would need a database storing operator
properties, like priority, associativity, how to render
it, etc. Currenty we have king of database using mixture
of Lisp and Boot, but data is available only to Boot code
and can not be used directly by Spad code. We probably
also would need to generalize properties of operators,
first, there are ordinary infix operators, but then
big variants used in prefix form and frequently having
some sorts of limits (like summation).
--
Waldek Hebisch
[email protected]
--
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 http://groups.google.com/group/fricas-devel.
For more options, visit https://groups.google.com/d/optout.
