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 f16IdfH19692 for ; Tue, 6 Feb 2001 19:39:41 +0100 Received: by webgate.proteosys.de (8.11.0/8.11.0) with ESMTP id f16Ided05708 . for ; Tue, 6 Feb 2001 19:39:40 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0906C.2A7BD480" 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 f16Idd702001 for ; Tue, 6 Feb 2001 19:39:39 +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 TAA14943 for ; Tue, 6 Feb 2001 19:39:39 +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 f16Idc701997 for ; Tue, 6 Feb 2001 19:39:38 +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.FE76F636@mail.listserv.gmd.de>; Tue, 6 Feb 2001 19:39:33 +0100 Received: from RELAY.URZ.UNI-HEIDELBERG.DE by RELAY.URZ.UNI-HEIDELBERG.DE (LISTSERV-TCP/IP release 1.8b) with spool id 488986 for LATEX-L@RELAY.URZ.UNI-HEIDELBERG.DE; Tue, 6 Feb 2001 19:39:35 +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 TAA12690 for ; Tue, 6 Feb 2001 19:39:33 +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 TAA21636 for ; Tue, 6 Feb 2001 19:39:34 +0100 Received: from nag.co.uk (openmath.nag.co.uk [62.232.54.144]) by relay.uni-heidelberg.de (8.10.2+Sun/8.10.2) with ESMTP id f16IdYu13728 for ; Tue, 6 Feb 2001 19:39:34 +0100 (MET) Received: (from davidc@localhost) by nag.co.uk (AIX4.2/UCB 8.7/8.7) id SAA14684; Tue, 6 Feb 2001 18:39:18 GMT In-Reply-To: (message from Lars =?iso-8859-1?Q?Hellstr=F6m?= on Tue, 6 Feb 2001 18:58:25 +0100) References: Return-Path: Content-class: urn:content-classes:message Subject: Re: More template experience Date: Tue, 6 Feb 2001 19:39:18 +0100 Message-ID: <200102061839.SAA14684@nag.co.uk> X-MS-Has-Attach: X-MS-TNEF-Correlator: From: "David Carlisle" 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: 3729 This is a multi-part message in MIME format. ------_=_NextPart_001_01C0906C.2A7BD480 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable > The main advantage with this is that the use of special > characters inside the keyval default will no longer mess up the = parsing; > currently Yes this is of course a general problem with the latex [] syntax, but it is particularly bad here I agree, because if it goes wrong in the middle of that code then it _really_ goes wrong. There is a general rule of optional things using {} and mandatory things using [] but perhaps since the syntax for template declarations are so formalised anyway, the rules can be different here. Frank? Chris? > The difference between a template and an instance could be explained > better. ah documentation. Yes that could be improved. > in particular you need to do much more > processing of a template before you can use it than you need to do an > instance. Yes, in effect you have to make a (nameless) instance and run that. > 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. there were earlier versions where instances (at least) were called as \csname rather than via a \UseInstance{xxx} syntax that could allow such characters. Also the number of parts in those names grew as features such as collections got added (and the template/instance code got re-redesigned) I agree that it should be cleaned up. Hopefully though those internal names can be changed without really affecting the main interface or packages using it. Thanks again for your detailed reading of the code. It is heartening to have someone say that it is basically a good idea, modulo some technical "features". There's always a danger that nobody likes it at all:-) David ------_=_NextPart_001_01C0906C.2A7BD480 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: More template experience

> The main advantage with this is that the use of = special
> characters inside the keyval default will no = longer mess up the parsing;
> currently

Yes this is of course a general problem with the latex = [] syntax, but
it is particularly bad here I agree, because if it = goes wrong in the
middle of that code then it _really_ goes = wrong.

There is a general rule of optional things using {} = and mandatory things
using [] but perhaps since the syntax for template = declarations are so
formalised anyway, the rules can be different here. = Frank? Chris?

> The difference between a template and an instance = could be explained
> better.

ah documentation. Yes that could be improved.

> in particular you need to do much more
> processing of a template before you can use it = than you need to do an
> instance.

Yes, in effect you have to make a (nameless) instance = and run that.

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

there were earlier versions where instances (at least) = were called as
\csname rather than via a \UseInstance{xxx} syntax = that could allow
such characters.

Also the number of parts in those names grew as = features such as
collections got added (and the template/instance code = got re-redesigned)

I agree that it should be cleaned up. Hopefully though = those internal
names can be changed without really affecting the = main interface
or packages using it.

Thanks again for your detailed reading of the code. It = is heartening
to have someone say that it is basically a good idea, = modulo some
technical "features". There's always a = danger that nobody likes
it at all:-)

David

------_=_NextPart_001_01C0906C.2A7BD480--