## LATEX-L@LISTSERV.UNI-HEIDELBERG.DE

#### View:

 Message: [ First | Previous | Next | Last ] By Topic: [ First | Previous | Next | Last ] By Author: [ First | Previous | Next | Last ] Font: Proportional Font

Subject:

Re: \begin{<env>} ... \end{<env>}

From:

Date:

Sun, 4 Jan 2009 17:11:43 +0100

Content-Type:

text/plain

Parts/Attachments:

 text/plain (75 lines)
 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 \ ... \end 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__begin:w % Seems easiest here to use :w  > \envs__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 \ \end 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