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 f16HwaH19603 for ; Tue, 6 Feb 2001 18:58:36 +0100 Received: by webgate.proteosys.de (8.11.0/8.11.0) with ESMTP id f16Hwad05600 . for ; Tue, 6 Feb 2001 18:58:36 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C09066.6D3AAE00" Received: from mail.Uni-Mainz.DE (mailserver1.zdv.Uni-Mainz.DE [134.93.8.30]) by mailgate2.zdv.Uni-Mainz.DE (8.11.0/8.10.2) with ESMTP id f16HwW729059 for ; Tue, 6 Feb 2001 18:58:36 +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 SAA06378 for ; Tue, 6 Feb 2001 18:58:32 +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 f16HwV729054 for ; Tue, 6 Feb 2001 18:58:31 +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 <10.3FCD069A@mail.listserv.gmd.de>; Tue, 6 Feb 2001 18:58:26 +0100 Received: from RELAY.URZ.UNI-HEIDELBERG.DE by RELAY.URZ.UNI-HEIDELBERG.DE (LISTSERV-TCP/IP release 1.8b) with spool id 488963 for LATEX-L@RELAY.URZ.UNI-HEIDELBERG.DE; Tue, 6 Feb 2001 18:58:28 +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 SAA12046 for ; Tue, 6 Feb 2001 18:58:26 +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 SAA26524 for ; Tue, 6 Feb 2001 18:58:26 +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 f16HwQu01477 for ; Tue, 6 Feb 2001 18:58:26 +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 SAA19522 for ; Tue, 6 Feb 2001 18:56:41 +0100 (CET) Return-Path: X-Sender: lars@abel.math.umu.se x-mime-autoconverted: from quoted-printable to 8bit by relay.urz.uni-heidelberg.de id SAA12047 Content-class: urn:content-classes:message Subject: More template experience Date: Tue, 6 Feb 2001 18:58:25 +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: 3727 This is a multi-part message in MIME format. ------_=_NextPart_001_01C09066.6D3AAE00 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I've spent the weekend actually getting the templated index package running, so now I've gained some new experience with these things. The = good news are that I got the design as I wanted it almost immediately; this suggests to me that the separation of design (which gets put in = ) and control structures (which is the for the template) furthers = good programming. In fact I suspect that if one is to develop a new LaTeX2e package which involves a lot of design issues, the best route might be = to start develop it as a LaTeX2e* package (or at least a templated package) and then write a 2e version which follows the structure of the 2e* = version (emulating the instances only, not the templates or template types). In = any case, I will try this approach in the next step of the templated index package project. The bad news are that before I got it running I had to spend several = hours tracking down the exact reason that the weren't parsed as I wanted them to. This was initially very hard but it got easier once I hacked ldcsetup.sty to actually print how it had parsed the keyvals (see latex-bugs expl3/3302; apparently something of the kind will be included = in the official code as well), however it was still much too easy to make \DeclareTemplate go haywire by making a typo in the argument. One thing I think would solve most of these problems, or at least enable TeX to catch them at a much earlier stage, would be to change the keyval defaults from being bracked-delimited to brace-delimited (i.e. put in a group). It is certainly no harder to check if the next character is a = `{' than to check if it is a `[': just do \@ifnextchar\bgroup instead of \@ifnextchar[. The main advantage with this is that the use of special characters inside the keyval default will no longer mess up the parsing; currently \DeclareTemplate{foo}{bar}{0}{ foo =3Df0 [, ] \punctuation }{\DoParameterAssignments} will die rather horribly because the comma inside the brackets will = start the declaration of a new key. When \TP@test@pt tries to grab the default value it will only stop at the end of the file or a \par, because the = right brace that was intended to end the default value is hidden inside a = group. Currently \DeclareTemplate{foo}{bar}{0}{ foo =3Df0 [{, }] \punctuation }{\DoParameterAssignments} does work and the braces are removed when the default value is grabbed, = but one would avoid errors better if it was \DeclareTemplate{foo}{bar}{0}{ foo =3Df0 {, } \punctuation }{\DoParameterAssignments} since then the comma wouldn't be visible to \KV@parse. Other characters that need this kind of special care in defaults are =3D and ]. Some other things I reacted to: The difference between a template and an instance could be explained better. I had gotten the impression that instance=3Dtemplate where there = are no unrestricted keyvals left, but after looking closer at the code I can see that this is not the case; in particular you need to do much more processing of a template before you can use it than you need to do an instance. You'll have to put a lot of \describecsfamily's into template.dtx before you can call it reasonably documented, but before you do that you may = want to consider changing the control sequence families used. Currently = control sequence names are pieced together as ... (for templates the seems to be TP>/, the is the template type, is /, is the template name, and n=3D2). = This practice works fine if n=3D1 or the 's cannot be appear in = the 's, but that is not the case with the template code. A solution less sensitive to strange characters in 's would be to surround each with a brace group (\csname doesn't mind category 1 and 2 characters), since even an ingenious fool has work very hard to get = braces mismatched in arguments, whereas with the current naming scheme \DeclareTemplate{foo}{bar/baz}... and \DeclareTemplate{foo/bar}{baz}... would be stored in the same macros. Lars Hellstr=F6m ------_=_NextPart_001_01C09066.6D3AAE00 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable More template experience

I've spent the weekend actually getting the templated = index package
running, so now I've gained some new experience with = these things. The good
news are that I got the design as I wanted it almost = immediately; this
suggests to me that the separation of design (which = gets put in <keyvals>)
and control structures (which is the <code> for = the template) furthers good
programming. In fact I suspect that if one is to = develop a new LaTeX2e
package which involves a lot of design issues, the = best route might be to
start develop it as a LaTeX2e* package (or at least a = templated package)
and then write a 2e version which follows the = structure of the 2e* version
(emulating the instances only, not the templates or = template types). In any
case, I will try this approach in the next step of = the templated index
package project.

The bad news are that before I got it running I had to = spend several hours
tracking down the exact reason that the = <keyvals> weren't parsed as I
wanted them to. This was initially very hard but it = got easier once I
hacked ldcsetup.sty to actually print how it had = parsed the keyvals (see
latex-bugs expl3/3302; apparently something of the = kind will be included in
the official code as well), however it was still much = too easy to make
\DeclareTemplate go haywire by making a typo in the = <keyvals> argument.

One thing I think would solve most of these problems, = or at least enable
TeX to catch them at a much earlier stage, would be = to change the keyval
defaults from being bracked-delimited to = brace-delimited (i.e. put in a
group). It is certainly no harder to check if the = next character is a `{'
than to check if it is a `[': just do = \@ifnextchar\bgroup instead of
\@ifnextchar[. The main advantage with this is that = the use of special
characters inside the keyval default will no longer = mess up the parsing;
currently

   \DeclareTemplate{foo}{bar}{0}{
      foo =3Df0 [, = ]      \punctuation
   }{\DoParameterAssignments}

will die rather horribly because the comma inside the = brackets will start
the declaration of a new key. When \TP@test@pt tries = to grab the default
value it will only stop at the end of the file or a = \par, because the right
brace that was intended to end the default value is = hidden inside a group.
Currently

   \DeclareTemplate{foo}{bar}{0}{
      foo =3Df0 [{, = }]      \punctuation
   }{\DoParameterAssignments}

does work and the braces are removed when the default = value is grabbed, but
one would avoid errors better if it was

   \DeclareTemplate{foo}{bar}{0}{
      foo =3Df0 {, = }      \punctuation
   }{\DoParameterAssignments}

since then the comma wouldn't be visible to \KV@parse. = Other characters
that need this kind of special care in defaults are = =3D and ].

Some other things I reacted to:

The difference between a template and an instance = could be explained
better. I had gotten the impression that = instance=3Dtemplate where there are
no unrestricted keyvals left, but after looking = closer at the code I can
see that this is not the case; in particular you need = to do much more
processing of a template before you can use it than = you need to do an
instance.

You'll have to put a lot of \describecsfamily's into = template.dtx before
you can call it reasonably documented, but before you = do that you may want
to consider changing the control sequence families = used. Currently control
sequence names are pieced together as

   = <root><name_1><separator_1><name_2><separator_= 2> ... <name_n>

(for templates the <root> seems to be TP>/, = the <name_1> is the template
type, <separator_1> is /, <name_2> is the = template name, and n=3D2). This
practice works fine if n=3D1 or the = <separator_i>'s cannot be appear in the
<name_i>'s, but that is not the case with the = template code. A solution
less sensitive to strange characters in = <name_i>'s would be to surround
each <name_i> with a brace group (\csname = doesn't mind category 1 and 2
characters), since even an ingenious fool has work = very hard to get braces
mismatched in arguments, whereas with the current = naming scheme

  \DeclareTemplate{foo}{bar/baz}...
and
  \DeclareTemplate{foo/bar}{baz}...

would be stored in the same macros.


Lars Hellstr=F6m

------_=_NextPart_001_01C09066.6D3AAE00--