blob: bc662cb3fde73e85db0a5d83f6e84ffc0c6d447c (
plain) (
tree)
|
|
@Section
@Title { "@OneOf" }
@Tag { oneof }
@Begin
@PP
oneof.sym @Index { @@OneOf symbol }
The @@OneOf symbol returns one of the sequence of objects which is
its right parameter as its result:
@ID @Code @Verbatim {
@OneOf {
@ResultA
@ResultB
@ResultC
}
}
The choice is made to ensure that whatever galley target is required
at the moment is found. For example, if we are evaluating @@OneOf
as part of an attempt to attach a galley whose target is
{@Code "@SomeTarget"}, then the result above will be
{@Code "@ResultA"} if it contains {@Code "@SomeTarget"}, or else
{@Code "@ResultB"} if it contains {@Code "@SomeTarget"}, or else
{@Code "@ResultC"} (whether or not it contains the target, or
if there is no target).
@PP
Use of @@OneOf in conjunction with recursive symbols can lead
to problems. Consider this example:
@ID @Code {
"def @Recursive {"
""
" def @ChoiceA { @APlace // @Recursive }"
""
" def @ChoiceB { @BPlace // @Recursive }"
""
" @OneOf {"
" @ChoiceA"
" @ChoiceB"
" }"
"}"
}
Lout believes that expanding @Code "@Recursive" is the right thing
to do when searching for either of the galley targets {@Code "@APlace"}
and {@Code "@BPlace"}. When searching for @Code "@BPlace" this leads
Lout to expand {@Code "@Recursive"}, then {@Code "@ChoiceA"}, then
the {@Code "@Recursive"} symbol within {@Code "@ChoiceA"}, and so on
infinitely. This problem can be avoided by attaching a
@Code "@NotRevealed" symbol to each of the inner @Code "@Recursive"
symbols: these are then not available for expansion until a
decision has been made to expand the symbol they lie within. In
this particular example it would be simpler to write
@ID @Code {
"def @Recursive {"
""
" @OneOf {"
" @APlace"
" @BPlace"
" }"
" // @Recursive"
"}"
}
but this factoring is not possible when the recursive calls have
parameters that are required to differ in the two cases.
@End @Section
|