Re: QuotedDisplay in DocumentLayout Use clause

[Valeriy E. Ushakov]

Peter,

On Wed, Jun 17, 1998 at 07:40:02AM +0200, Peter Kristensen wrote:

> @Use { @DocumentLayout
>     @CaptionFormat { @QuotedDisplay @B { number: } @NoDotSep @OneCol }
> }
> 
> When I run lout this error message appears:
> 
> layout.lt.lout:38:(22) symbol @QuotedDisplay unknown or misspelt
> 
> With @QuotedDisplay defined in "dl" this should work. Shouldn't it? Or
> have I overlooked something?

@QD is defined in and exported from @DocumentLayout.  But when you use
it in a @CaptionFormat parameter to @DocumentLayout above, it is
invoked in a scope where exported symbols from @DocumentLayout are not
in visible yet.  It's only after the closing brace of @Use that
symbols exported from @DocumentLayout will be in scope.

The fact that you are trying to use @QD in a parameter to
@DocumentLayout, where this symbol is defined, doesn't change
anything.  Invocations of both @DocumentLayout and @QD obey usual
scoping rules.

What your are trying to do boils down to:

    export @Buzz
    def @Foo
      named @Bar { bar }
    {
      def @Buzz { buzz }
      @Bar
    }

and then use @Foo @Bar { @Buzz } to get "buzz".

To achive this you need to modify @Foo slighly to bring @Foo's own
exported symbols in scope into @Bar so that you can use @Buzz when you
specify @Bar:

    export @Buzz
    def @Foo
      import @Foo
      named @Bar { bar }
    {
      def @Buzz { buzz }
      @Bar
    }

Note that, though @Bar is a named paramter to @Foo, but it's a symbol
in it's own right and does *not* automatically import @Foo's exported
symbols.  Note also that for the "right" parameter Lout provides the
option of `self-import' when you use "body" instead of "right".

Of cause you can use @Use/@Open to access exported symbols as well,
but in your particular expample you are trying to access symbol
exported from @DocumentLayout *inside* the @Use for the
@DocumentLayout itself.

Hope this explains the problem.


IMHO, `dl' has grown too large.  It contains fundamental things like
low level page layout and support for generic large scale structures
along with things that logically belongs to a logically higher level -
like displays, lists, figures and the like.

May be it's time to consider splitting dl?  In particular, I thought
about the core stuff like pages and structural elements.  As Lout
becomes (I dare to hope) popular as a target of SGML formatting,
separating this stuff will help developers - for they will be able to
reuse the core but add bells and whistles that suits there backends.

Lout packages are user oriented and are often cumbersome for automatic
generation.  OTOH, where it's a burden for a user to put extra braces
and invoke extra symbols - a backend that targets Lout does not care -
so I anticipate that SGML transformations will target their own Lout
packages, tightly coupled with the backend.

It's my belief, that the main strength of Lout is it's programmability
and by reorganizing dl a bit we can emphasize this and help developers
to reuse the core code.

But then, as Jeff rightly points out, the compatibilty problems may
arise.  I think that at the minimum we can, mostly mechanically,
separate @DocumentLayout into, say, @PageLayout (with the core stutt)
and @DocumentNiceties (with stuff like lists and figures).

So instead of @Use { @DocumentLayout } setups will use two clauses for
the new symbols and options will remain all the same.


Can people that actually use Lout as a backend kindly share their
experience?

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