Re: references in order of appearance (again)

[Valeriy E. Ushakov]

On Tue, Oct 10, 2000 at 09:43:08 +1100, Jeff Kingston wrote:

> > > To do this you need to know if the tag has been already seen in
> > > *this* run.  But @Foo&&tag will give you the xref from the
> > > previous run...
> > 
> > How feasible would it be to ...
> 
> Quite feasible.  It's just a matter of coming up with a coherent
> design and adding it in.

It raises some interesting questions.  We have already discussed on
the list if it's possible and feasible to "merge" databases from the
previous and the current runs.  If Lout is extended with a *test* for
cross-reference being already known in *this* run (which is easy), the
natural desire of potential users would be to *retrieve* that value.
And this brings us back (sort of) to that problem of "merging"
databases.

The question is what is a useful xref database model for Lout?  The
"for Lout" part is important here, because Lout has different notions
of spatial and temporal orders because of galleys.  By "spatial" I
mean xrefs with magic "following" and "preceding" tags (let's call
them "spatial xrefs", as Expert's Guide doesn't seem to have a special
generic term for them)

A galley that is temporally in the future w.r.t. some point of
execution may be spatially preceding that point of execution as it
will be (had? would have?) attached to some target "preceding" the
point of execution (e.g. TOC entries).  Of corse that "yet-to-happen"
galley will be retrieved from the previous run database when the target
for it is seen in the current run.

Since that galley can carry other xref targets on board this means
that for some symbols the meaning of "preceding" can be established
for sure only after all galleys attached, i.e. only after the run is
complete.  I think this is the main problem for merging databases from
preceding and current runs.  The example might seem freaky, but I used
similar technique in "classified" pages problem posted to the list few
years ago (note to self, check if it still works):

    <http://snark.ptc.spbu.ru/mail-archives/lout/latest/msg00140.html>


Another related and interesting problem is what I call "double spatial
indirection": when we retrieve (via @Open) a value from a spatial xref
and the value we retrieve is itself retrieved from another spatial xref.
Something like this (not checked):

    # @Bar exports named parameter @BarValue
    # @FirstBar exports named parameter @FirstBarValue
    
    @FirstBar @FirstBarValue { @Bar&&following @Open { @BarValue } }
    
    # ...
    @Bar @BarValue { ... } # intended target of the indirection
    
    # more invocations of @Bar here
    
    # double spatial indirection
    @FirstBar&&preceding @Open { @FirstBarValue } 

with the intention to find something like first/last thing in some
structure (page, section, etc) with different combinations of
preceding/following in the two xrefs involved.

In some cases (I don't remember which and I don't have examples handy)
Lout fails to resolve this as it tries to search the wrong database:
for file foo.lt it thinks that one of the references is in foo.ld.ld
since it read it from foo.ld.


These are just my insomniac notes on the subject of coherent design.
Databases are directly related to the spatial/temporal dichotomy in
Lout and I think that this aspect is sometimes overlooked.  IMHO, it's
a gross source of fun like, say, multithreading and lazy evaluation.

SY, Uwe
-- 
address@hidden                         |       Zu Grunde kommen
http://www.ptc.spbu.ru/~uwe/            |       Ist zu Grunde gehen