On Sun, Sep 27, 2020 at 11:56:40PM +0200, Ralf Hemmecke wrote:
>
> >> 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).
>
> Well, in fact, I would like to get rid of all those variables and also
> reduce i-output.boot for the output of types. Algebra output could be
> done by Format2D. The only "bug" in Format2D is that it does not break
> lines. I will now play around with it and see what *my* needs are and
> perhaps other people also come forward with their wishes.
I probably was not clear enough in what I wrote: my intent is
to handle output via Spad code. For compatibility, want
program logic to be close to current 'i-output.boot'. In
particular whan I wrote "records" I meant Spad Record
(doing records in Boot is ugly). I want to keep ')set output ...'
but Boot code implementing this should call Spad code for
real work.
> > 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.
>
> Not exactly clear what you mean here, but my wish was to bring more
> stuff from BOOT to SPAD. Adding a new Formatter should be an action of
> writing a .spad file and add register it in the Makefile, but not
> additionally change something in setvart.boot, setvars.boot, msgdb.boot,
> and i-output.boot. Certainly, that's not a very big deal, but that's
> what I chose.
As I wrote, I want to keep ')set' commands. However, "variable
parts" should be on Spad side, so after transition there would
be no need to change Boot code to add new format. Clearly,
there is a need to have registry of available formats. This
can be done as separtate domain. Theoreticaly each formatter
could do call to register itself. Such approach would be
elegant and allow adding formatters at runtime. Pragmaticaly,
fixed table of formatters may be better (one can find all
available formatters in the table and there is no need for
formatters to know about the table).
> My first intention was to improve the TexFormat domain to be able to
> compile book.pdf, but it ended in a compleltely different approach of
> handling the OutputForm structure which in turn made it relatively easy
> to come up with FormatMathJax, Format1D, and Format2D. Maybe some day I
> spend some time to also put Texmacs and MathML formats into my scheme.
> However, since I do not use those much, it may need some users to push me.
I admit that I do not see why you felt need for different structure.
AFAICS old structure can handle what you are doing and code
size seem to be comparable.
> > 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.
>
> Right, that it is a problem with two output managers.
> However, I do not see my new framework as a big problem to "output on
> different streams", because the main domain that is connected to actual
> output is FormattedOutput. And, honestly, this is just my invention to
> connect my formatter domains to actual output on a stream (the
> "formatted" stream. I do not insist on this. This domain is pretty small
> and we can certainly coordinate in removing this domain or adapting it
> so that your "stream idea" gets realized. All the rest of the formatting
> framework is independent of actual streams.
No big problem. But getting code to work means that one has
to work out various little problems. More specifically,
I would like to have single output manager. I want this
manager to be compatible with current use and support
')set' commands. Note: I am not against having alternative
setup interface, but alternative should integrate cleanly
with ')set' commands.
Clearly, output manager should support what is needed by
JFriCAS. I admit that you surprised me by use of multiple
formats -- I assumed that JFriCAS will just use single
format. Concerning use of single stream versus multiple
streams: at low level we want single stream. HyperDoc
shows that with multiple low level streams one get
various synchronization problems. Such problems do not
appear when using single low level stream. At higer
level you clearly want multiple streams: the purpose
of markers that you emit is to allow demultiplexing
single low level stream into multiple logical streams.
Now, textual markers are simple but rather poor
method of demultiplexing. For HyperDoc I plan to
use simple binary scheme, using messages. Each
message would have fixed size header containing
id (identifying high level stream), and size
and a variable size payload. Such thing is rather
easy to implement. I think that it will work
well, but since it is still a plan we need to
wait to see how it will work in practice. Before
such thing is used for HyperDoc we need to do
several other changes. In fact, recent changes to
stream usage are part of preparations for HyperDoc
change.
Anyway, concerning JFriCASSupport: for current use it
may be included. However, I expect that it will
need substantial changes (or possibly vanish) in
near future.
--
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/20201001205221.GA10290%40math.uni.wroc.pl.
