LATEX-L Archives

Mailing list for the LaTeX3 project

LATEX-L@LISTSERV.UNI-HEIDELBERG.DE

Options: Use Forum View

Use Proportional 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 >>]

Print Reply
Subject:
From:
Lars Hellström <[log in to unmask]>
Reply To:
Mailing list for the LaTeX3 project <[log in to unmask]>
Date:
Tue, 30 Jan 2001 11:32:38 +0100
Content-Type:
text/plain
Parts/Attachments:
text/plain (58 lines)
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@[log in to unmask]

> > 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öm

ATOM RSS1 RSS2