Re: [Texmacs-dev] More comments on David's document

[Joris van der Hoeven]

On Wed, 10 Apr 2002, David Allouche wrote:

> On Sunday 07 April 2002 12:43, Joris van der Hoeven wrote:
> 
> Rewriting or transforming
> -------------------------
> 
> > * Do we prefer "rewriting" or "transforming"?
> 
> Rewriting is not a term I am familiar with, but you and Stephane appear to 
> prefer it over transforming. I am ok for rewriting, since it is a less common 
> word it will help avoid confusion.
> 
> Moreover, I could not help laughing when programming transformers... That 
> would be to strong a remiscence from my kid years toys :)

OK, so let us systematically use "rewriting".

> Naming and ptree
> ----------------
> 
>     stree: stay as it is
>     ptree -> ttree (path tree -> tagged tree)
>     dtree -> rewriter
> 
> ptree does not carry additional style information, it is just the tree type 
> used in rewriters notifications. I separate stree and ttree, because the 
> tagged trees only carry path information, while the source trees must also 
> ensure each node path tag is equal to the actual inverse path of the node in 
> the source tree. So tree operations on ttree will only rearrange the nodes 
> (they will probably be cut'n'pasted from edit_modify) and stree operations 
> will also update the inverse paths.

OK, so please speak about "source ttrees" instead of "strees".
Indeed, "stree" is not a new data type, it is just a ttree with
a special purpose.

> Observers
> ---------
> 
> > * I like the idea about "observers"; I would use a phrasing
> >   close to this in order to characterize a rewriter:
> >
> >   A rewriter observes changes in a source tagged tree and
> >   notifies the next rewriter about changes which have to
> >   be made in this tree after rewriting.
> >   At the end of the chain, there is no next rewriter and
> >   the result of the rewriting is rendered.
> 
> My wording was purposeful in considering that the typessetter was an 
> instance of stree observer. The class hierarchy I had in mind was:
>  
>        ttree <-- stree      rewriter --> tree_observer <-- typesetter
> 
> Do you agree with that approch? It appears nicely economic and orthogonal to 
> me. I do not like the current style of edit_modify, the basic operations 
> there perform to much processing that should be delegated. 

Like in the case of tree and stree, there is no real difference between
the rewriter, tree_observer and typesetter classes: they all refer to
the same abstract class.

In the case of rewriter, tree_observer and typesetter,
I nevertheless feel that the difference in purpose is greater,
so you may use typedefs to let the different classes become synonyms.
(I also prefer "observer" to "tree_observer", since we will never
observe other types of objects). However, I am against doing
the same thing for "stree".

> Edit tree
> ---------       
> 
> > * The use of the term "edit tree" is incorrect in your document.
> >   In TeXmacs it is just the tree which is being edited.
> >
> >   In your dia picture, you should replace "source tree"
> >   by "source ttree" and "edit tree" by "ttree ready for rendering".
> >   You may also make it clearer that the rewriting process can
> >   be a *chain* of several steps.
> 
> I do not get it.
> 
> As far as I understand, the edit tree is the structure which is apparent 
> through cursor motion commands, especially inifinitesimal ones. It is indeed 
> the same structure which is processed by the typesetter. Some parts of the 
> edit tree are made inaccessible to the editor by tagging them as decorations, 
> but they are still accessible for typesetting. So what is the purpose in 
> making a distinction between "edit tree" and "ttree ready for rendering"?

Well, in the new approach, the rewriter will rewrite the "edit tree"
(which will become synonym for "source ttree"; currently it is the "et"
field in editor) into an "object ttree" which is "ready for rendering".

> Moreover, it not obvious that the structure of a "ttree ready for rendering" 
> will affect the editor behaviour, but that is obvious if we call it "edit 
> tree".

Well, the "ttree ready for rendering" only indirectly affects the editor
behaviour (via methods for graphical interaction with the editor,
like "action" or conversions between graphical cursor positions and
logical paths). The "ttree ready for rendering" mainly affects the typsetter,
while the "source ttree", which contains the real structure of the document,
affects the editor.

> Finally, AFAIK, the edit tree is a concept that is local to each editor, so I 
> not sure if you intended to make the definiton more restrictive by saying "it 
> is just the tree which is being edited".
> 
> There must be something more that I have not yet understood.

No, the "edit tree" is shared between different views (i.e. editors).
Later on, we might create a second tree which contains more detailed
styling information, but this is not urgent; a normal style file +
environment variables will do for the moment.

> Force method
> ------------
> 
> > * The specification of the "force" method is bad:
> >   is has type "box force (void)" or "tree force (tree)".
> >   Indeed, the forcing is used in order the force
> >   the typesetting of the ttree associated to
> >   exactly this rewriter.
> 
> I do not get it either.
> 
> As far as I understand, force is used to get typesetting informations, esp. 
> strectchable dimensions, of a piece of tree in a given context, for example 
> to implement tabbing.
> 
> Giving it the prototype "box force (void)" would cause undiscerned 
> retypesetting of the whole tree, and we then would have to dig out what we 
> really want in the resulting boxes... it makes no sense at all whatsoever.

No, it does not retypeset the whole tree but only the corresponding subtree;
recall that a "rewriter" is really a tree with addional abstract methods.
The method force is always called for specific subtrees.

> Giving it the prototype "tree force (tree)" already makes more sense but:
> 
>   -- Why to convert the result boxes to a tree inside the rewriter protocol? 
> As you pointed it to me before, specific rewriter implementations (e.g. 
> scripting language adapters) could perform the conversion themselves if they 
> need to support that operation. Forcing the conversion in the protocol is 
> distributed fat.

You are right, but using trees instead of boxes would be interested if
we want allow rewriters to be provided as plugins in the future;
in that case, a tree might be passed easily to the plugin, but not a box.
But maybe we should not bother about this yet.

>   -- In which context would the parameter tree be transformed and typeset? 
> For the force() method would be useful, we would need to put all the 
> structure affecting typesetting (font, size, mode, etc.) in the parameter 
> tree. But that is not possible since the very correspondance between 
> structure and typesetting is abstracted in subsequent transformations.

I do not want to put structure affecting typesetting in the parameter tree,
since this information might be put in the tree itself.
The parameter is really only useful if the result is *not* a box:
in this case, the parameter should be interpreted as a query for the box,
like "how wide are you?", "how high are you?", "what is the hyperlink
attached to you?".

> I have the impression you want the rewriters to be transparent bridge-like 
> structures. They will not. The rewriters are monolithic opaque objects 
> associated to a whole document tree.

Yes, they are opaque.

No, they are not associated to the whole document tree:
they can be associated to *any* subtree of a document and
to *any* partial result of a rewriting of such a subtree

> A bridge-like structure can indeed be useful as an implementation detail to 
> help provide functional optimization, but it would be only an implementation 
> detail. All messages sent to a tree_observer from outside (stree or another 
> rewriter) are going to be sent to an object which have the responsibility for 
> the entire document.

Yes, but the object delegates it to the appropriate subobject,
in a similar way as bridges do.

> Finally, I do not understand what you mean by "typesetting of the ttree 
> associated to exactly this rewriter". In my understanding, every rewriter is 
> associated to the same typeset box tree.

No, plainly wrong: the rewriter may (I do not say must, because you may
want to do this in a different way in the case of XSL) contain subrewriters
which reflect the subtree structure of the ttree. This is efficient,
because it allows you to delegate an event in the main rewriter to
the subrewriter where the event took place.

> I fear I have not been clear enough in the document, I am going to rework it 
> to avoid potential confusion.

Yes, we need to clarify these important design issues.

> > * Remove section 3.5; this information is non relevant here.
> >   You should just mentioned that the last rewriter in the chain
> >   does the rendering, either on the screen or by monitoring
> >   events on stdout.
> 
> That explanation is needed for the reader to understand what the force method 
> does. At least, what the force method, as I understand it, does. 

But you should not go into technical details here, because you do not yet
have a full understanding on what is going on here and because it does
not really matter here. The important thing to know is that, at the end,
you have a box whose physical size is known.
 
> > * Please use a nicer layout: justify your text and resist to using
> >   a two column format for the appendices. Also recheck your document
> >   for grammatical correctness; I found many spelling errors and
> >   the use of singular instead of plurial.
> 
> I apologize for spelling errors, but as stated in the first section that 
> document is a draft. It is essentially a first pass brain dump. I will make 
> it evolve in a complete report, but it is still really immature.

It does not really matter, but at certain points, I found quite a lot of them,
and I know that you can do better.

> I used ragged text because it makes the edition much faster and much less 
> tiring to the eye. I think you should try editing the first section while 
> using the transformations-tags stylesheet (you will need the tags package I 
> posted recently on the use mailing list) and justified text. But, indeed, the 
> final document will have to be justified.

Well, please justify it before distributing it then.

In any case, edition of ragged text is *not* faster, although you may find it
more tiring for the eye (I, on the contrary, find ragged texts very tiring).
But it may also be a matter of using professional/normal hyphenation.

> I will not resist using two column format, since it is well known that 
> multicolumned text is much easier to read: putting less strain on ocular 
> muscles and easing considerably the practice of fast reading.

I may agree with this for printed texts, but I do not agree in the case of
texts on the screen in papyrus mode, because vertical scrolling is not
naturally compatible with two column texts.

Hence, please use one column text for the drafts;
you might switch to two column mode when printing it out,
using an appropriate style file.

> > * Please do not notify texmacs-users about further changes;
> >   they now know that these documents exist.
> 
> Ok. But you could have noticed that I said in the announcement that all 
> further versions of this document will only be announced in the developper 
> mailing list.

I missed that; at a certain point I just found that people were
putting a bit too many announcements (and messages with thanks for help)
on the mailing list.

Yours, Joris