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

[David Allouche]

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 :)

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.

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. 

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"?

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".

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.

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.

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.

  -- 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 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.

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.

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.

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

> * 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. 

> * 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.

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.

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.

> * 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.


Cheers.
-- 

                                  -- David --