Re: @NotRevealed (Was: Unidentified subject!)

[Samuel Lacas]

Valeriy E. Ushakov a écrit 3.5K le Sat, Oct 06, 2001 at 06:38:56AM +0400:

# When the first @Q is manifested Lout searches for the target for @Q
# and finds it in an yet unexpanded QAList.  At this point you have:
#     @QPlace # with first @Q already in there
#     @APlace
#     QAList
# When the first @A in manifested lout searches the preceding @APlace
# and it finds it in the yet unexpanded @AQList.  The @APlace manifested
# during the first expanstion of QAList is "too far" to be receding.

Thank you for having spent some time on these, and your answers are
perfectly clear. This first case was indeed very simple, but I did not
think of the @APlace "hidden" in the @QAList being closer than the
revealed one. I mean, I understood the notion of "distance" for
galleys based on something like the number of symbols to expand to
reveal the galley; thus, the revealed @APlace was closer for me than
the "hidden" one.

This makes me wonder: would not it be possible to have a
"look for galleys in order of appearance" rather than the "preceding",
"followin" or "foll or prec" features; of course, that would only
stand for "unflushed" ones. May be it too memory consuming.

# >                Q:Does this again work this way ?
# >                A:Yes
# >                Q:
# >                A:Yes, once more
# First @Q can't find it's target because @NotRevealed hides it.

OK...

# Attaching @A causes QAList to expand and then the second @Q can find
# the revealed @QPlace from the first QAList (the @QPlace in the second
# one is, again, not revealed to it).

...but what happens to the poor and first @Q ? Is it deleted (I already
got warning messages stating "@blabla deleted, could not find target",
or something similar while tinkering with galleys and @Case) by the
second one in the "waiting galleys queue" ?

# > [output 3]
# This is what you want.

Yes. That one was clear to me. 

# The point of @NotRevealed is to mark "subsidary" targets, so to say.
# Here you want @Q to drive the expansion of QAList, but not @A. 

Well, with my former reading of "closer", I though exactly the other
way round: I wanted to have an @A[nswer] to "flush" the pair (@Q,@A)
into its couple of (expanded, thus closer to me) targets.
 
# Other outputs are left as an exercise to the reader. ;)

Well, I succeeded in understanding them now. But notice how the fourth
one is twisted. For the reader who has forgot, this is the working
one, with the @NotRevealed on the @APlace, but with the following in
the input: @Q{1} @Q{2} @A{1} @A{2}, which leads to
    Q:1
    A:2
    Q:2
    A:1
that is, the order of answers is reversed. My explanation is:

First, @QAList is expanded two times for the @Q's to be attached,
leading to
    Q:1
    A:  (waiting)
    Q:2
    A:  (waiting)
    QAList (@Aplace not visible)
with @A{1} waiting, which finds the closest galley, thus
    Q:1
    A:  (waiting)
    Q:2
    A:1
    QAList (@Aplace not visible)
with @A{2} waiting; the only visible A target is obvious and that is
why you obtain the result. One can easily see, if I'm not wrong, that
an input like @address@hidden @address@hidden would produce the @Q's in
ascending order and the @A's in reverse order...

Well, my intuition now is that, if someone wants to have the correct
output order whatever the input order, I may need to resort to sorted
galleys.
 
# Hope this helps.

Perfectly. Thank you very much.

sL