RE: About Constructions rules

[Avi Kivity <Avi@xxxxxxxxxxxxx>]

On Friday, July 16, 1999 00:18, Matthias Clasen
[SMTP:clasen@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx] wrote:
> > 
> > This means that the rule is called, at most, once per grove per mode. If
> > any
> > thrashing about is to be done, you have to specify it explicitly. And of
> > course it can be done lazily.
> 
> The list of nodes which match the query has to be constructed only once,
> but you have to decide for every node you process if it is on the list.
> But there might be ways to make this cheaper: One idea would be to
> associate
> the list of matching query rules directly to the node once it is
> constructed.
> When processing a node, you would then first check if it has matching
> query rules attached. If yes, you use the most specific one, otherwise
> find the applicable rule as before.
>  
I will say it until one of us convinces the other: dsssl *never* processes
or examines the entire tree.

Dsssl only specifies that one node is processed -- the root node. Of course,
if you leave the default processing rules, you get a recursive descent. But
each level of recursion goes through the stylesheet, which usually goes to
the next level using (process-children).

A (query ...) construction rule operates in the following way:
1. The dsssl engine hands the style-query-expression the grove root. In
fact, with both hands - (current-node) and (current-root)
2. The stylesheet (you) now use standard node manipulation to gather nodes
into a node-list. The dsssl engine has no say as to the compexity of this.
It can be O(1), O(children in toplevel element), O(all elements), O(all
nodes), or O(atoms in solar system).
3. The stylesheet (still you) returns the assembled node-list to the dsssl
engine. It may be large or small.
4. The dsssl engine feeds the node-list, node by node, to the
construct-expression. This is essentially what (map-constructor) does (or
will do in 1.2.2). The sosofos keep their separate identities (they are
related to their nodes).
5. When a node's turn to be processed comes, if it is in the node-list
returned by the q-c-r, the corresponding sosofo is inserted.

So, if you have a q-c-r which looks for five consecutive character nodes
constituting the word "DSSSL" and sets the first letter in a larger font
size, then every occurence of DSSSL would be so affected, no matter where it
appears. Admittedly, this would be slow, but not because of the nature of
q-c-r's - it would be because because you're looking at character nodes.

I have a feeling most of dsssl is O(output size) rather than O(input size),
if both the implementation and the stylesheet are clever. Only the parser is
O(input size), for obvious reasons.

I would like to know how others understand the q-c-r feature, since it's
apparently very different to my perceptions.
---
"The only words which have meaning are the last ones spoken"



 DSSSList info and archive:  http://www.mulberrytech.com/dsssl/dssslist