LATEX-L Archives

Mailing list for the LaTeX3 project

LATEX-L@LISTSERV.UNI-HEIDELBERG.DE

Options: Use Classic View

Use Monospaced Font
Show HTML Part by Default
Condense Mail Headers

Topic: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Sender: Mailing list for the LaTeX3 project <[log in to unmask]>
Date: Wed, 19 Aug 2009 11:36:31 +0100
Reply-To: Mailing list for the LaTeX3 project <[log in to unmask]>
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
In-Reply-To: <[log in to unmask]>
Content-Type: text/plain; charset=ISO-8859-1
From: Joseph Wright <[log in to unmask]>
Parts/Attachments: text/plain (95 lines)
Frank Mittelbach wrote:
> now that I missed out every on the xparse discussion due to being away (and
> not yet having been able to review it properly) I hope that to contribute at
> least to the template discussion in time.

I'd hope that the xparse discussion is logical, and that although
progress has been made nothing is regarded as set in stone just yet
(Lars is, I think, taking a detailed look at the result of the changes
at a code level, for example).

>  > The idea of template is that it lets you separate out design from code,
>  > and to pre-set various parts of the design so that they do not have to
>  > be evaluated at every use.  I'm still not clear on the
>  > \DeclareTemplateType concept, so I'll go with what I can understand. (If
>  > anyone can show where this extra division is useful, please do tell.)
> 
> I'll hope I will be able to do this (in a separate message)

I'll look forward to it: after all, you know a lot more about this than
I do!

>  > You start by declaring a template, which is a generalised form for a
>  > design function. For example, you might have a template called
>  > "division" that is a generalised chapter/section. The template has a
>  > number of keys, which will set variables later. The trunk template
>  > implementation uses a modified keyval method for setting these up, but
>  > in my template-alt version I've used the same concept as is now present
>  > in l3keys.  Something like (very simplified, of course):
>  >
>  > [...]
>  >
>  > You'll notice the number: this is used to allow the template to take a
>  > number of arguments.
> 
> One important point to note here is that a template takes a fixed (!) number
> of mandatory (!) arguments and no (!) optional ones and that tese argument are
> supposed to receive content from the input stream of the document.

Yes, I guess I should have said that. I think we are generally clear
that only document level commands can have optional arguments (see for
example the xparse discussion which resulted in "o" versus "d" as the
consensus).

>  > The next part of the process is to create an "instance". The idea here
>  > is to fix particular parameters of the template with a given name.  So
>  > pursuing the very simple example, we might have one instance for chapters:
>  > 
>  > \DeclareInstance { chapter } { division } {
>  >   font-name    = Helvetica,
>  >   font-size    = 20 pt,
>  >   ...
>  > }
>  > 
>  > and so on. The point is that the keys are set "now", so that when we use
>  > the instance there is less to do.
> 
> correct. however the parameter settings of a template (turning it into an
> instance) is not only restricted to preset values: the template implementation
> also allows for keys to be evaluated and set at run-time if needed.

Yes, again I knew that but forgot to say: a crucial point as you point out.

> The conceptual point being that template parameters are receiving values
> specified by the designer to define layout an general hehavior, while the
> mandatory arguments of a template receive document input to be processed
> according to the design. For reasons of processing speed there has been a
> decision to make the latter argument direct TeX argument (thus imposing a
> limit of 9) rather than offering a key/val interface on that level as well. In
> our opinion such an interface, if desired, should live one layer up as it
> would be a document syntax feature.

All makes sense: for the things I've imagined you can use a template for
there should not be too many document-time arguments in any case.

>  > At present, there are various bells and whistles to this in template, of
>  > which only some are implemented in template-alt as I don't follow all of
>  > them. So there are various questions:
>  >  - Does this broadly make sense to other people?
>  >  - Does the current interface provide enough flexibility?
> 
> if by current interface you mean the functionality offered by the original
> template implementation then my biased take is yes :-) if you mean a
> restricted subset of features I doubt it. That is not to say that some of the
> functionality we implemented should be done differently or should be offered
> differently so sorting this out and reevaluating them one by one is important
> as we agreed earlier

As I've pointed out in another mail, my experiments in template-alt are
not meant to imply that I'm suggesting anything can be dropped. I can
see the use of almost everything in template, although there are one or
two points I still don't get (the "type" being the one I remember: I
need to look at the code again to remember the rest).
-- 
Joseph Wright

ATOM RSS1 RSS2