MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
References: <49758499.5080004@morningstar2.co.uk>
            <150532.45020.qm@web82002.mail.mud.yahoo.com>
            <49782F88.9090501@morningstar2.co.uk>
Message-ID:  <18808.16082.113183.345018@morse.mittelbach-online.de>
Date:         Thu, 22 Jan 2009 10:39: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: Frank Mittelbach <frank.mittelbach@LATEX-PROJECT.ORG>
Subject: Re: Key points of LaTex3
To: LATEX-L@LISTSERV.UNI-HEIDELBERG.DE
In-Reply-To:  <49782F88.9090501@morningstar2.co.uk>
Precedence: list
Status: R

 > > 1) Loosening of the 9-argument restriction on user-written macros: this
 > > is a thoroughly antequated and very limited restriction.
 > 
 > Two things here.  First, keyval-type methods already do this, and to be
 > honest a macro which needs say 15 arguments in a row seems a bit
 > daunting to me!  Second, the low level #1, #2, etc. business is from the
 > engine (no idea about LuaTeX).

it may be an antequated restriction, but we will not lift on the programming
level it nor do we think it is very limiting. As Joseph said, macros with more
than 9 positional arguments are not really sensible as a user interface anyway
in fact anything there with more than 3 or 4 arguments is questionable in my
eyes.


 > > 2) Arguments to user macros resolved by #1, #2, etc.: See 1) above.  
 > > There are many ways of refering to arguments and the
 > >  #1 #2 etc is very limiting

on the programmers level that is adequate enough (and fast). On the
designer/user level other methods are (and will be) available.

 > > 3) Arguments specified positionally only: It should be possible to 
 > > specify argument by name=value pairs.
 > 
 > Again, keyval-type methods do this, and allow you to store input as
 > named macros (which is pretty close to what you ask).  The template
 > module does some of this, although I've made the case for a more general
 > keyval module with my "keys3" attempt.

for the designer level we already have a key value interface and I'll expect a
user interface to support that kind of specification as well. As Joseph said,
we are looking at providing a more general key/val interface so something like
the template mechanism might get some changes generalizations eventually.

But agreed this is essential on those two interface levels (document designer
and document user).

frank