## LATEX-L@LISTSERV.UNI-HEIDELBERG.DE

 Options: Use Forum View Use Monospaced Font Show Text Part by Default Show All Mail Headers Message: [<< First] [< Prev] [Next >] [Last >>] Topic: [<< First] [< Prev] [Next >] [Last >>] Author: [<< First] [< Prev] [Next >] [Last >>]

Lars,

> 1. The order of parameter assignments.
>
> I haven't seen anything in the documentation about in which order the code
> for the various keys get executed, but in the implementation it looks as if
> they are executed in the order they are listed.

i guess this is something for David to comment on, my memory is a bit hazy

the very first drafts of the template interface (where there was still
something like DeclareCommandInstance and other stuff) we tried to be able to
use key values inside an instance for specifying the values of other keys, eg

baselineskip = 12pt,
topskip      = 10pt,
textheight   = \baselineskip * 49 + \topskip,

but first of all we never came up with a good way to reference keys on the
right hand side and then there was the problem this concept only worked for
certain key types and (forgotten what) and ...

so basically that idea was abandomed again, though there might be some traces
left in the code I fear.

As it looks right now it seems to like this:

- default values are executed first order of specification at template
level (unless overwritten)
- instance values executed thereafter and in order of specification
at instance level

this is from looking at the following example:

\RequirePackage{template}
\RequirePackage{trace}

\DeclareTemplateType{xxx}{0}

\def\MultiSelection{\MultiSelectionError}
%\def\foo{bar}

%\traceon

\DeclareTemplate{xxx}{test}{0}
{
xkey=n [\foo] \xkey,
ykey=n [\Delayevaluation\foo] \ykey,
zkey=n \zkey,
last=n [last] \lastkey
}
{
\DoParameterAssignments
abc
}
\ShowTemplate{xxx}{test}

\DeclareInstance{xxx}{bar}{test}
{
zkey = foo,
xkey = baz
}
\DeclareInstance{xxx}{baz}{test}
{
last = first,
zkey = foo
}

\ShowInstance{xxx}{bar}
\ShowInstance{xxx}{baz}
----------------------------------------------

which gives:

(./template-test.tex
LaTeX2e <2000/06/01>
Babel <v3.6Z> and hyphenation patterns for english, french, german, ngerman, du
(./template.sty (./ldcsetup.sty (/cdrom/texmf/tex/latex/graphics/keyval.sty)
(/usr/local/texmf/tex/latex/tools/calc.sty))) (./trace.sty)
******* Template: xxx/test *******
*
* Defaults:
*
\TPD>/xxx/test=macro:->\KV@xxx/test@last {\def  \lastkey {last}}\KV@xxx/test@yk
ey {\def  \ykey {\Delayevaluation \foo }}\KV@xxx/test@xkey {\def  \xkey {\foo }
}
*
* Restrictions:
*
\TPR>/xxx/test=\relax
*
* Body:
*
> \TP>/xxx/test=\long macro:
-> \DoParameterAssignments abc .

l.22 \ShowTemplate{xxx}{test}

?
******* Instance: <>xxx/bar *******
*
> \<>xxx/bar=macro:
->\TP@assignments {\def  \ykey {\Delayevaluation \foo }\def  \lastkey {last}\de
f \zkey {foo}\def  \xkey {baz}}\TP>/xxx/test .

l.36 \ShowInstance{xxx}{bar}

?
******* Instance: <>xxx/baz *******
*
> \<>xxx/baz=macro:
->\TP@assignments {\def  \xkey {\foo }\def  \ykey {\Delayevaluation \foo }\def
\lastkey {first}\def \zkey {foo}}\TP>/xxx/test .

l.37 \ShowInstance{xxx}{baz}

? x

-------------------------------------------------------------

> It would be nice if this
> could be put in writing since you sometimes need one assignment to be
> carried out before another (my concrete example of this is that an instance
> key gets used in code for an s' key).

perhaps the above semantics could be made a formal specification though it
would need to be checked whether this is true for all key types. As I said my
recollection is that in the end the feeling was that we can't rely on order
of specification (though even that would need formal specification)

> 2. The nature of the n' key type
>
> Are n' keys evaluated (expanded) at declaration-time or not? template.dtx
> is actually contradicting itself on this matter: in Section 1 it says n'
> is the same thing as f0', but in Subsection 3.1 there is an example using
> \DelayEvaluation in the default for a type n' key to avoid
> declaration-time evaluation. As far as I can tell the implementation takes
> a third position as it parses a \MultiSelection but otherwise leaves the
> code unevaluated.

section 3.1 is rubbish and perhaps due to a bug that i just noticed trying the
code. the code indeed looks for \MultiSelection but since MultiSelection is an
undefined csname the test via \expandafter\ifx\@car dies a horrible death if
you do

key =n [\foo] \key

and \foo is undefined (since that is then = to \MultiSelection)

this is why the above sample code eactually \def's \MultiSelection

have to run to earn some bread and butter (more on that tonight)

frank