Received: from webgate.proteosys.de (mail.proteosys-ag.com [62.225.9.49]) by lucy.proteosys (8.11.0/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id f0SMc1704833 for ; Sun, 28 Jan 2001 23:38:05 +0100 Received: by webgate.proteosys.de (8.11.0/8.11.0) with ESMTP id f0SMcd720100 . for ; Sun, 28 Jan 2001 23:38:46 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0897A.FA9D4480" Received: from mail.Uni-Mainz.DE (mailserver1.zdv.Uni-Mainz.DE [134.93.8.30]) by mailgate1.zdv.Uni-Mainz.DE (8.11.0/8.10.2) with ESMTP id f0SMbrM27396 for ; Sun, 28 Jan 2001 23:37:53 +0100 (MET) Received: from mailgate2.zdv.Uni-Mainz.DE (mailgate2.zdv.Uni-Mainz.DE [134.93.8.57]) by mail.Uni-Mainz.DE (8.9.3/8.9.3) with ESMTP id XAA19857 for ; Sun, 28 Jan 2001 23:37:53 +0100 (MET) X-MimeOLE: Produced By Microsoft Exchange V6.5 Received: from mail.listserv.gmd.de (mail.listserv.gmd.de [192.88.97.5]) by mailgate2.zdv.Uni-Mainz.DE (8.11.0/8.10.2) with ESMTP id f0SMbq728356 for ; Sun, 28 Jan 2001 23:37:52 +0100 (MET) Received: from mail.listserv.gmd.de (192.88.97.5) by mail.listserv.gmd.de (LSMTP for OpenVMS v1.1a) with SMTP id <13.CA3F7A4E@mail.listserv.gmd.de>; Sun, 28 Jan 2001 23:37:50 +0100 Received: from RELAY.URZ.UNI-HEIDELBERG.DE by RELAY.URZ.UNI-HEIDELBERG.DE (LISTSERV-TCP/IP release 1.8b) with spool id 484044 for LATEX-L@RELAY.URZ.UNI-HEIDELBERG.DE; Sun, 28 Jan 2001 23:37:50 +0100 Received: from ix.urz.uni-heidelberg.de (mail.urz.uni-heidelberg.de [129.206.119.234]) by relay.urz.uni-heidelberg.de (8.8.8/8.8.8) with ESMTP id XAA25246 for ; Sun, 28 Jan 2001 23:37:48 +0100 (MET) Received: from relay.uni-heidelberg.de (relay.uni-heidelberg.de [129.206.100.212]) by ix.urz.uni-heidelberg.de (8.8.8/8.8.8) with ESMTP id XAA33270 for ; Sun, 28 Jan 2001 23:37:48 +0100 Received: from mail.umu.se (custer.umdac.umu.se [130.239.8.14]) by relay.uni-heidelberg.de (8.10.2+Sun/8.10.2) with ESMTP id f0SMbnY06729 for ; Sun, 28 Jan 2001 23:37:49 +0100 (MET) Received: from [130.239.137.13] (mariehemsv093.sn.umu.se [130.239.137.13]) by mail.umu.se (8.8.8/8.8.8) with ESMTP id XAA03532 for ; Sun, 28 Jan 2001 23:37:48 +0100 (MET) Return-Path: X-Sender: lars@abel.math.umu.se x-mime-autoconverted: from quoted-printable to 8bit by relay.urz.uni-heidelberg.de id XAA25247 Content-class: urn:content-classes:message Subject: Templates Date: Sun, 28 Jan 2001 23:37:23 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: From: =?iso-8859-1?Q?Lars_Hellstr=F6m?= Sender: "Mailing list for the LaTeX3 project" To: "Multiple recipients of list LATEX-L" Reply-To: "Mailing list for the LaTeX3 project" Status: R X-Status: X-Keywords: X-UID: 3653 This is a multi-part message in MIME format. ------_=_NextPart_001_01C0897A.FA9D4480 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable 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{} then a \DelayEvaluation can be defined through \def\DelayEvaluation#1{% \iffalse{\fi}% \toks@=3D\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' type keys should work like command variables. But I think that is all I've come up with, for the moment. Lars Hellstr=F6m [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.) ------_=_NextPart_001_01C0897A.FA9D4480 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Templates

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@=3D\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=F6m


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

------_=_NextPart_001_01C0897A.FA9D4480--