User-Agent: Thunderbird 2.0.0.22 (Windows/20090605)
MIME-Version: 1.0
References: <4A8986E9.5090209@morningstar2.co.uk>           
            <3F0FECF5-03FB-44C2-99D6-07C3F6987F05@gmail.com>           
            <19083.59487.548225.750361@morse.mittelbach-online.de>           
            <4A8BF36D.6040000@morningstar2.co.uk>           
            <19083.65388.211120.732256@morse.mittelbach-online.de>           
            <4A8C1547.4030408@morningstar2.co.uk>
            <19084.8165.557822.97482@morse.mittelbach-online.de>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Message-ID:  <4A8C3026.3060800@morningstar2.co.uk>
Date:         Wed, 19 Aug 2009 18:02:30 +0100
Reply-To: Mailing list for the LaTeX3 project
              <LATEX-L@LISTSERV.UNI-HEIDELBERG.DE>
Sender: Mailing list for the LaTeX3 project <LATEX-L@LISTSERV.UNI-HEIDELBERG.DE>
From: Joseph Wright <joseph.wright@MORNINGSTAR2.CO.UK>
Subject: Re: template types
To: LATEX-L@LISTSERV.UNI-HEIDELBERG.DE
In-Reply-To:  <19084.8165.557822.97482@morse.mittelbach-online.de>
Precedence: list
Status: R

Frank Mittelbach wrote:
>  > decide, of course, but if we can get them discussed over not too long a
>  > period it would be good.  I'll perhaps come back to this issue, and some
>  > other naming ones, in another mail.
> 
> agreed. not "too long" but also not necessary incremental while we are still
> in the process of understanding/re-evaluating concepts.

Of course.  In the xparse discussion, various things were passed
back-and-forth before decisions were reached without any real code being
altered. (I should add that it's not clear that the xparse discussion is
over yet, simply that there was enough of a consensus to commit
something to code. There are still bits that may need attention, such as
the skipping-spaces question.)

> I mean, at the start of the thread you had already eliminated the "type" level
> altogether and below we start thinking about looking at the whole  concept
> from yet another light

As I said, in template-alt I've done things I understood, without
seeking to imply that other things were not needed. Even then, the main
aim was to see if my key model (as in l3keys) would work for template.
(I'd like to think that the same key defining system can be used for
both design [template] and document [l3keys] keyval input. On that, I
think the answer is yes, although there are a few things that don't
currently work properly in template-alt. They can wait, though, until it
is clear that the model I've proposed will actually be used.)

>  > My general concern is to try to get template to the point where things
>  > won't change again at the interface level. So I'm keen we agree on
>  > things like naming and argument order, as in the longer term it's
>  > important.
> 
> yes, agreed, but rather than incrementally changing things back an forth I
> would like to mentally get at the desired picture first. That still might
> involve some level of iteration if we notice that things don't seem to quite
> fit once we try them in real life

Quite true. I'm imagining that there won't be any real code written for
a while, just snippets of possible interface as I've been posting.

>  > From what you say, it sounds as if we are better looking at things a
>  > slightly different way. The key connection is between instances and
>  > types, with templates as a likely but not essential "glue". So is
>  > something like:
>  > 
>  > \DeclareInstanceType         (was \DeclareTemplateType)
>  > \DeclareTemplate             (no change)
>  > \DeclareInstanceFromTemplate (was \DeclareInstance)
>  > \UseInstance                 (no change)
>  > 
>  > any more logical?  In that way, you can imagine declaring an instance in
>  > some other way than from a template. I'm not looking for change for
>  > changes sake, but am trying to make sure that things are as clear as
>  > possible for anyone using the system.
> 
> yes that seems to be much more in line with how I'm thinking about it. let's
> keep that as a candidate and let it settle a bit (get a feel for it)

Just a first thought, based on a better understanding of the concept. As
you say, this might not be the best idea in the end.   I will probably
write myself some (private) notes on the structure now I have a better
picture of how things work, and see if anything else strikes me.
-- 
Joseph Wright