On Sun, Sep 27, 2020 at 09:52:39PM +0200, Ralf Hemmecke wrote:
>
> Thank you for this suggestion.
>
> >> Which way should I follow?
>
> > Well, usual solution chosen by others was to have something like
> >
> > setFormatMathJax()
>
> Well, yes, possible, but unflexible.
Dedicated functions give easy inflexible option which should
satisfy needs of most users. Users needing more can use
general interface suffering full complexity and possible
uglyness (like 'pretend' above).
> Currently ")set output ... on" for different formats outputs always in
> the order given by i-output.boot. Using setFormats!([F1, F2, F3]) would
> allow the user to decide the order and also to compile his/her own
> domain of type FormatterCategory and use it.
Well, adding user-settable order to 'i-output.boot' would be
rather easy. Simply nobody bothered to implement this.
My plan was to switch to tabular description. More precisly
currently 'i-output.boot' contains bunch of variables for
each format. I want to change this to a record. Records
can be created at runtime so one could register new format
if desired. OTOH with well designed output system there
would be almost no need for user formats (useful formats
should be already included).
Those changes are currently suspended, as Formatted plays
its own tricks, at least partially incompatible with the design
above. ATM I am waiting for "dust to settle", that is
too see what exactly you want to change.
Repeating what I wrote some time ago: formatter should be
resposible for rendering OutputForm on a stream. Where
stream output goes should be due to separate managment
layer. If different formatters output on the same
stream it should be manager task to decide on order, etc.
AFAICS Formatted wants to manage such things, and this
is a problem: when there are two managers we get chaos
and lack of proper coordination.
<rant> There is quality called "cohesion" or "conceptual
integrity" meaning that parts of system follow common
design and compose into coherent whole. I could list
rather long list of design choices made in Axiom time
that I am not happy about. But I keep most of them,
because current choices play together reasonably well.
Change which improves one aspect can make other things
worse and balance may be negative. There is also
reality factor: some changes need a lot of work to
implement correctly and partial, incomplete change can
make things worse. Due to modularity of Spad incompatible
changes can coexist in different packages, but this is
suboptimal situation, leading to duplicate developement
effort and user confusion.
</rant>
--
Waldek Hebisch
--
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 view this discussion on the web visit
https://groups.google.com/d/msgid/fricas-devel/20200927212512.GA36699%40math.uni.wroc.pl.
