LATEX-L Archives

Mailing list for the LaTeX3 project

LATEX-L@LISTSERV.UNI-HEIDELBERG.DE

Options: Use Forum View

Use Monospaced Font
Show HTML Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
Lars Hellström <[log in to unmask]>
Reply To:
Mailing list for the LaTeX3 project <[log in to unmask]>
Date:
Sun, 28 Jan 2001 23:37:23 +0100
Content-Type:
text/plain
Parts/Attachments:
text/plain (72 lines)
As I have (finally) some practical experience of using templates (kind of
late, but the stuff I've been doing the last year haven't involved much
design), I have encountered some general issues about templates that I
think need some thought:

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. 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).

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.

My gut feeling is that the values for these keys should be evaluated at
declaration, although so far I haven't been able to come up with any
example where this is really needed. Anyway, if the declaration-time
expansion is done as

  \edef\name@value{<default>}

then a \DelayEvaluation can be defined through

  \def\DelayEvaluation#1{%
     \iffalse{\fi}%
     \toks@=\expandafter{\name@value #1}%
     \edef\name@value{\iffalse}\fi \the\toks@
  }

and \MultiSelection can be defined using a similar trick. Since names are
things that are to end up between a \csname and the matching \endcsname it
should be safe to use an unprotected \edef here. Of course there would have
to be some formal specification of what you can put in an `n' type value in
this case, but some discussions in the past (such as that about declaring
an \"A instance for xinitials [1]) suggest to me that such a specification
is needed for other reasons as well and has been for some time.

A comparison with fontinst might also be useful here. Although I don't
think it is spelt out like this anywhere, fontinst makes a distinction
between string variables (the values of which are fully evaluated/expanded
when they are assigned) and command variables (where no expansion takes
place until they are used). Thus what I'm suggesting is that `n' type keys
should work like string variables, whereas `f<n>' type keys should work
like command variables.

But I think that is all I've come up with, for the moment.

Lars Hellström


[1] About xinitials: The problem with that is of course not in the
template, but in the document command which passes general text to an
argument which expects a name value. The right thing to do would be to
mangle the argument into a working name before trying to use it as an
instance name. (A sketch for a mangling procedure would be the following:
Require that the text to mangle is robust and doesn't contain any TeX
primitives. Define representations for the text commands. Throw away all
commands which aren't text commands---making \protect temporarily \@gobble
should take care of that. Besides that something needs to be done about the
\chardef tokens \% and \&; making them proper text commands is probably the
way to go.)

ATOM RSS1 RSS2