Print

Print


Joseph Wright writes:

 > The recent question about macro names got me thinking about how
 > environments should be implemented in LaTeX3.  I think I've seen this
 > mentioned briefly somewhere, but not really worked through.
 > 
 > My thinking is that, although using \<env> ... \end<env> is convenient,
 > it is probably not the best way to (1) keep user and internal macros
 > separate and (2) to show what is going on.  I'd therefore imagine a
 > "virtual" module begin used for all of the \begin/\end names, something
 > like:
 > 
 > \envs_<env>_begin:w % Seems easiest here to use :w
 > \envs_<env>_end:
 > 
 > That means that the business with \end... is removed from command
 > creation much clearer) and that there is no possibility of accidentally
 > using an environment-starting command without \begin.

I agree that the 2.09 (and 2e) method of storing the internal form of user
level environments withing \<name> \end<name> is defective for a number of
reasons but mimicking envionments with corresponding infernal forms seems to
me is  mixing up different levels of access in the wrong manner.

First of all, who says that environments are the right user interface (as Arno
asked by suggesting an ConTeXt like approach). They may well be (I personally
rather like them as on the user inferface they allow certain type of checks
that are otherwise difficult is not impossible) but even if they are the goal
for L3 should be to completely decouple the designer and the user interface.

That means that it should be possible to produce a 2e like interface or an XML
like interface or a ConTeXt like interface from the same code provided at the
designer/functional interface.

As for the designer/functional level interface I envision something based on
template.sty (plus a more extensive/general key/val concept for setting
variable values --- the latter hasn't been written).

With xparse we have actually provided such an example interface that offers
document-level syntax  a la 2e/2.09

With a template interface on that designer level, things like "heading
commands" or "lists" etc will be built from defining instances of templates,
for example,

  \DeclareDocumentCommand{\chapter}{ s o m }
     { \UseInstance {head} {A-head-main} {#1} {#2} {#3} }

In a similar fashion 2e like environments would be supported through similar
commands such a \DeclareDocumentEnvironment.

The point here is that xparse does the translation of the user level syntax
(with optional arguments star form, envionments, ...) to an internal form that
doesn't have any optional arguments but a very precise set of arguments. Eg,
the signature of a "head" template has always three arguments, ie the first
being a boolean to decide if a toc entry is made, the second an alternate TOC
text or \NoValue and the third the  actual heading text.

This resolves two issues:

 a) a designer can replace one "head" instance with any other "head" instance
 to provide different layouts without changing the the way the document is
 interpreted.

 b) one can replace the top level syntax with something else, eg some XML
 parser or some ConTeX like syntax or ...

as long as the separation is properly done, the top-level user interface can
be  fairly freely chosen and to be honest I'm not too concerned about it.

What concerns me is the clean separation which as missing within LaTeX209/2e
as the user interface was grabbing directly through to the internal
implementation.

frank