References: <m2vbpt81jx.fsf@smbp.home> <m2lhqp818q.fsf@smbp.home>
            <CAHkWWc0iDjK-xOSoNoG4zLmkNaokVw5UwKmBrXQzfgvXkraPVA@mail.gmail.com>
            <53F667E1.8080909@morningstar2.co.uk>
User-Agent: SquirrelMail/1.4.21
MIME-Version: 1.0
Content-Type: text/plain;charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Message-ID:  <a2dd3125f58ad369f6f7482acd8acb67.squirrel@webmail.seanallred.com>
Date:         Fri, 22 Aug 2014 12:19:38 -0700
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: Sean Allred <tex@SEANALLRED.COM>
Subject: Re: Thoughts on xtemplate
To: LATEX-L@LISTSERV.UNI-HEIDELBERG.DE
In-Reply-To:  <53F667E1.8080909@morningstar2.co.uk>
Precedence: list
Envelope-To: <rainer.schoepf@GMX.NET>
Status: R

> One thing I think to consider is the lesson of LaTeX(2e) in that a small
> number of positional-based mandatory arguments work well as a user.
> That's something I'd certainly expect to see in any new code too.

I agree wholeheartedly; as you mentioned in your post on TeX.SX,
*nobody* wants to write anything like

    \UseInstance{sectioning}{latex2e}
                {<full-name>}{<TOC name>}{<header name>}...

even on the design levels.  This is why I am very supportive of the
key--value syntax:

    \UseInstance{sectioning}{latex2e}
      {
        full-name   = #1,
        toc-name    = \IfValueTF{#1}{#1}{#2},
        header-name = \IfValueTF{#1}{#1}{#2},
        ...
      }

as it is much clearer.  I've seen many, many packages that use KV-based
interfaces for setup, and I think that this is similar.  As long as it
remains on the design level (the 'setup' level, if you will), it should
be fine.

> Almost certainly the number of truly *required* arguments will
> remain small, and while the case that a design should not be limited
> by TeX is quite true, and the same time a design interface that
> fundamentally fails to translate to a TeX-based user layer is a
> problem too.

And I don't mean to advocate that these objects should be able to have
many (9+) mandatory arguments; I'm far more concerned with the
homelessness for optional ones.  The support for many mandatory
arguments is a side-effect that good interface designers will know to
avoid except where it may be appropriate (I can't think of any, but in
the interest of my own ignorance).  If there is a cleaner way to provide
this support for optional arguments, that's perhaps just as
good.

All the best,
Sean

I still like the idea of a purely KV 'backend' from as a language thing.

-- 
Sean Allred