X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	["2072" "Tue" "30" "June" "1998" "10:01:28" "+0100" "David Carlisle" "davidc@NAG.CO.UK" nil "40" "Re: Modules" "^Date:" nil nil "6" nil nil nil nil nil]
	nil)
Received: from listserv.gmd.de (listserv.gmd.de [192.88.97.1])
	by mail.Uni-Mainz.DE (8.8.8/8.8.8) with ESMTP id KAA02064;
	Tue, 30 Jun 1998 10:55:53 +0200 (MET DST)
Received: from lsv1.listserv.gmd.de (192.88.97.2) by listserv.gmd.de (LSMTP for OpenVMS v1.1a) with SMTP id <3.10167DB7@listserv.gmd.de>; Tue, 30 Jun 1998 10:55:31 +0200
Received: from RELAY.URZ.UNI-HEIDELBERG.DE by RELAY.URZ.UNI-HEIDELBERG.DE
          (LISTSERV-TCP/IP release 1.8b) with spool id 374828 for
          LATEX-L@RELAY.URZ.UNI-HEIDELBERG.DE; Tue, 30 Jun 1998 10:55:22 +0200
Received: from nag.co.uk (andover.nag.co.uk [192.156.217.113]) by
          relay.urz.uni-heidelberg.de (8.8.8/8.8.8) with ESMTP id KAA13808 for
          <LATEX-L@RELAY.URZ.UNI-HEIDELBERG.DE>; Tue, 30 Jun 1998 10:55:11
          +0200 (MET DST)
Received: (from davidc@localhost) by nag.co.uk (8.8.7/8.8.7) id KAA02857; Tue,
          30 Jun 1998 10:01:28 +0100
References: <v03110701b1bbd09a78ca@[130.237.37.112]>
            <199806230127.LAA12452@ricetub.anu.edu.au>
            <m0ynSs5-000DLbC@bilbo.yavuz.de>
            <199806220631.QAA11602@ricetub.anu.edu.au>
            <v03110703b1b3df3f0cc6@[130.237.37.30]>
            <199806271853.UAA29351@frank.zdv.uni-mainz.de>
            <v03110701b1bbd09a78ca@[130.237.37.112]>
            <v03110700b1bc30d2e3e0@[130.237.37.112]>
Message-ID:  <199806300901.KAA02857@nag.co.uk>
Reply-To: Mailing list for the LaTeX3 project
              <LATEX-L@RELAY.URZ.UNI-HEIDELBERG.DE>
In-Reply-To:  <v03110700b1bc30d2e3e0@[130.237.37.112]> (message from Hans Aberg
              on Sun, 28 Jun 1998 20:25:50 +0200)
Date:         Tue, 30 Jun 1998 10:01:28 +0100
From: David Carlisle <davidc@NAG.CO.UK>
Sender: Mailing list for the LaTeX3 project
              <LATEX-L@RELAY.URZ.UNI-HEIDELBERG.DE>
To: Multiple recipients of list LATEX-L
              <LATEX-L@RELAY.URZ.UNI-HEIDELBERG.DE>
Subject:      Re: Modules
Status: R
X-Status: 
X-Keywords:                  
X-UID: 2612

Hans writes

> LaTeX already has several very slow commands with slow parsing, for
> example the variations of "new" with the LaTeX special style of defining
> arguments.

Having a definition command that is slower than def is acceptable.
Having a mechanism where the _use_ of commands is an order of magnitude
(or more) slower than directly calling a control sequence is not
acceptible, as long as the system is to be programmed in TeX (or a
TeX-like system such as etex or omega).

This means that while it might be useful sometimes to `parse out' the
argument specification from the command name this would only ever be
used in limited circumstances, eg to define one variant form in terms of
another if for some reason the normal `base' NNNN (or nnnn) form is for
some reason unavailable. As Javier commented the current N-n distinction
is not always perfect. The exact detail of the conventions may well need
changing, but the basic principle must be that command sequences are
accessed directly as tokens at the level we are talking about (which is
the low level programming conventions in which higher level markup can
be defined).

This does not mean that the document level markup has to be token
based. Already LaTeX has the environment constructs which are not.
\begin{enumerate} is 12 tokens rather than \begingroup\enumerate
which is two. The environment syntax can fairly easily be offered in an
alternative syntax, say <enumerate> ... </enumerate> which is about the
same in terms of speed and memory usage as \begin \end (you have to work
a bit harder to get a full XML system though:-). Having the document
level markup being something that is parsed, `by hand', using a parser
written in TeX is acceptable, but only if the result of that initial
processing is a set of command tokens that can be executed in the normal
way of command tokens directly looked up in TeX's hash table.

I mention this point (again) not to try to stifle discussion but because
I got rather lost at what level you are intending some of your module
proposals to be used.

David