User-Agent: Thunderbird 2.0.0.19 (Windows/20081209)
MIME-Version: 1.0
References: <308a1ed10901010155r78f82ab3v11fef8d4a776813b@mail.gmail.com>      
            <E33DFD8A-AB6E-4911-873E-DE65C9E369B9@gmail.com>                   
            <308a1ed10901010725t35e1c160m6e361d43655b3cb1@mail.gmail.com>      
            <A7D70C36-6DFF-4C51-AF52-BFB9BA973078@gmail.com>           
            <495DDED6.3060504@morningstar2.co.uk>           
            <495E7DC2.7070705@morningstar2.co.uk>
            <90F3E1AC-9C87-43F7-BE5D-BBF16B4AA7B7@gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Message-ID:  <495F2159.2010507@morningstar2.co.uk>
Date:         Sat, 3 Jan 2009 08:27:05 +0000
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: A Question about the future of LaTeX3
To: LATEX-L@LISTSERV.UNI-HEIDELBERG.DE
In-Reply-To:  <90F3E1AC-9C87-43F7-BE5D-BBF16B4AA7B7@gmail.com>
Precedence: list
Status: R

Will Robertson wrote:
>> I've quickly thrown together a module which does basically this.  I've
>> called t "l3module" for want of a better name.  Source/PDF/ZIP including
>> demo available from
>> http://www.texdev.net/2009/01/02/tex-and-namespaces-continued/
> 
> That's neat!
> 
> I assume you're intended for it to be primarily used for user-space macros?

Yes, the prefix clash problem is, I think, much more unlikely (and
easier to handle using a manually-maintained database of taken values).

> What do you think of the idea to add something like this functionality
> to xparse, so that any instance of \DeclareDocumentCommand will
> automatically populate the list? On the other hand, it's nice to have an
> explicit list.

I'd thought about this, but at this stage was aiming for a quick "proof
of principal" implementation.  I wouldn't want to mess with xparse
without asking (and in any case, I can't!).

Using an explicit list is convenient for checking, but I'd agree that
perhaps a hook in \DeclareDocumentCommand would be a neater solution,
overall.  Doing that, there is a need to think about anything defined
after the end of the module (say \AtBeginDocument).  I think you'd still
want a way to explicitly reserve macro names under those circumstances.

I would imagine that if the team want to provide a "name reservation"
system, you'd probably integrate \module_details:nn with
\ProvidesExplPackage, so that you'd always have some details available.
 As you'd probably guess, I'd prefer an "internal" function name for
this, so perhaps:

\module_details:nn {module} {
  name        = xxx,
  version     = xxx,
  date        = xxx,
  e-mail      = xxx,
  description = xxx
}

with all of those values compulsory, and then the other details I've
suggested as optional.
--
Joseph Wright