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 f0UAWw712185 for ; Tue, 30 Jan 2001 11:32:58 +0100 Received: by webgate.proteosys.de (8.11.0/8.11.0) with ESMTP id f0UAXj726410 . for ; Tue, 30 Jan 2001 11:33:45 +0100 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 f0UAWvM00266 for ; Tue, 30 Jan 2001 11:32:57 +0100 (MET) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C08AA8.033F6900" Received: from mailgate1.zdv.Uni-Mainz.DE (mailgate1.zdv.Uni-Mainz.DE [134.93.8.56]) by mail.Uni-Mainz.DE (8.9.3/8.9.3) with ESMTP id LAA04226 for ; Tue, 30 Jan 2001 11:32:56 +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 mailgate1.zdv.Uni-Mainz.DE (8.11.0/8.10.2) with ESMTP id f0UAWuM00262 for ; Tue, 30 Jan 2001 11:32:56 +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 <14.D6D71209@mail.listserv.gmd.de>; Tue, 30 Jan 2001 11:32:49 +0100 Received: from RELAY.URZ.UNI-HEIDELBERG.DE by RELAY.URZ.UNI-HEIDELBERG.DE (LISTSERV-TCP/IP release 1.8b) with spool id 485289 for LATEX-L@RELAY.URZ.UNI-HEIDELBERG.DE; Tue, 30 Jan 2001 11:32:45 +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 LAA19225 for ; Tue, 30 Jan 2001 11:32:43 +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 LAA38030 for ; Tue, 30 Jan 2001 11:32:44 +0100 Received: from abel.math.umu.se (abel.math.umu.se [130.239.20.139]) by relay.uni-heidelberg.de (8.10.2+Sun/8.10.2) with ESMTP id f0UAWiY13206 for ; Tue, 30 Jan 2001 11:32:44 +0100 (MET) Received: from [130.239.20.144] (mac144.math.umu.se [130.239.20.144]) by abel.math.umu.se (8.9.2/8.9.2) with ESMTP id LAA17402; Tue, 30 Jan 2001 11:31:05 +0100 (CET) In-Reply-To: <14965.51969.510549.703034@istrati.zdv.uni-mainz.de> References: Return-Path: X-Sender: lars@abel.math.umu.se x-mime-autoconverted: from quoted-printable to 8bit by relay.urz.uni-heidelberg.de id LAA19226 Content-class: urn:content-classes:message Subject: Re: Templates (collection instances) Date: Tue, 30 Jan 2001 11:32:38 +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: 3668 This is a multi-part message in MIME format. ------_=_NextPart_001_01C08AA8.033F6900 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable At 18.55 +0100 2001-01-29, Frank Mittelbach wrote: > > 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{} > >i have my doubts that there should be any unprotected edefs anywhere if = you >can't really control the contents. Perhaps a straightforward unprotected \edef isn't right, but a \protected@edef would let through a lot of things which are bad too. Perhaps the right thing would be some kind of \protect@is@error@edef. > > 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. > >that would be an alternative, but again I would like to see at least a = single >example why one would need/want expansion (beside gut feeling, though = the >latter might be useful) First example: The name value is a mangled general text; then you don't want to mangle it anew each time you use it (especially since you don't know the conditions then will be), but have it stored in a mangled form. Second example: I suspect that there will be a number of instances = declared where at least some of the key values get set to the current value of = some LaTeX parameter (one could argue that this is bad programming, but this kind of thing is sometimes hard to avoid). Currently this is straightforward for count and length keys, but not at all easy for name, boolean, and instance keys, where I think this should work as well. For function key values however the datatype is too unstructured to allow anything of this sort due to technical difficulties. At 20.56 +0100 2001-01-29, Frank Mittelbach wrote: > > 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 > >have you had any usages for CollectionInstances while getting some = practical >experience? Not yet, but I have an idea about where to use them. Last night I wrote = an environment `thedocindex' which essentially uses the `std' instance of template type `docindex'. Some documents which use this environment (for technical reasons the name is hard-wired into a .ist file) will however want another instance here, and then one can achieve this using a collection instance. Or so I think. Lars Hellstr=F6m ------_=_NextPart_001_01C08AA8.033F6900 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: Templates (collection instances)

At 18.55 +0100 2001-01-29, Frank Mittelbach = wrote:
> > 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>}
>
>i have my doubts that there should be any = unprotected edefs anywhere if you
>can't really control the contents.

Perhaps a straightforward unprotected \edef isn't = right, but a
\protected@edef would let through a lot of things = which are bad too.
Perhaps the right thing would be some kind of = \protect@is@error@edef.

> > 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.
>
>that would be an alternative, but again I would = like to see at least a single
>example why one would need/want expansion (beside = gut feeling, though the
>latter might be useful)

First example: The name value is a mangled general = text; then you don't
want to mangle it anew each time you use it = (especially since you don't
know the conditions then will be), but have it stored = in a mangled form.

Second example: I suspect that there will be a number = of instances declared
where at least some of the key values get set to the = current value of some
LaTeX parameter (one could argue that this is bad = programming, but this
kind of thing is sometimes hard to avoid). Currently = this is
straightforward for count and length keys, but not at = all easy for name,
boolean, and instance keys, where I think this should = work as well. For
function key values however the datatype is too = unstructured to allow
anything of this sort due to technical = difficulties.


At 20.56 +0100 2001-01-29, Frank Mittelbach = wrote:
> > 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
>
>have you had any usages for CollectionInstances = while getting some practical
>experience?

Not yet, but I have an idea about where to use them. = Last night I wrote an
environment `thedocindex' which essentially uses the = `std' instance of
template type `docindex'. Some documents which use = this environment (for
technical reasons the name is hard-wired into a .ist = file) will however
want another instance here, and then one can achieve = this using a
collection instance. Or so I think.

Lars Hellstr=F6m

------_=_NextPart_001_01C08AA8.033F6900--