@NotRevealed (Was: Unidentified subject!)

[Valeriy E. Ushakov]

On Wed, Oct 03, 2001 at 10:11:18 +0200, Samuel Lacas wrote:

>    import @BasicSetup
>    export @Q @A 
>    def @QAL
>    {
>       def @Q into { @QPlace&&preceding }
>          right x
>       { x }
> 
>       def @A into { @APlace&&preceding }
>          right x
>       { x }
> 
>       def QAList
>       {
>          @B{Q: } | @QPlace  # point 1
>          //
>          @B{A: } | @APlace 
>          //
>          QAList
>       }
> 
>        QAList // @EndPlace
>    }

> Produces [output 1]
>                Q:Does this work this way ?
>                A:
>                Q:
>                A:Yes
>                Q:Does this again work this way ?
>                A:
>                Q:
>                A:Yes, once more
> 
> Forcing the galley on "Q", "A" or both does not change anything.

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.

So another QAList is expanded and @A attached to the @APlace in that
second one.

The process then repeats for the next pair of Q/A.


> Putting a @NotRevealed on @QPlace (point 1) leads to
> "no @QPlace precedes this @QPlace&&preceding" and
> 
> [output 2]
>                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.
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).


> Putting a @NotRevealed on @APlace (and removing that on @QPlace) leads to
> 
> [output 3]
>                Q:Does this work this way ?
>                A:Yes
>                Q:Does this again work this way ?
>                A:Yes, once more

When you put @NotRevealed on the @APlace, Lout will not consider the
QAList to contain a "preceding" @APlace, it is not revealed while
QAList in unexpanded.  So the first @Q forces QAList to expand, but
the second (recursive) QAList will not get in the way of the first @A
attaching to the @APlace revealed when the first QAList was expanded.

This is what you want.


> Can someone give a hint on all these outputs, especially [output 1],
> as I feel I understand [output 2] and [output 3], but I do not see
> why the first one does not work.  The [output 4] is also somewhat
> obscure to me, [output 5] is totally strange, and I can manage an
> explication on [output 6].

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.  In
other words:


       def QAList
       {
          @B{Q: } | @QPlace
          //
          @B{A: } | @APlace @NotRevealed
          //
          QAList
       }

tells lout that when it sees an unexpanded QAList, it can only find
the @QPlace in it, the @APlace is not revealed to any @A in search of
its target.  After attachment of @Q has forced the QAList to be
expanded, the @APlace (from the expansion) is revealed.  But the
recursive call to QAList doesn't reveal its @APlace.

Hope this helps.

Other outputs are left as an exercise to the reader. ;)

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