X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil] ["1615" "Thu" " 6" "April" "1995" "18:07:00" "+0000" "Frank Bennett" "fbennett@RUMPLE.SOAS.AC.UK" nil "38" "LaTeX modularity" "^Date:" nil nil "4" nil nil nil nil] nil) Received: from MZDMZA.ZDV.UNI-MAINZ.DE (vzdmzf.zdv.Uni-Mainz.DE [134.93.178.6]) by trudi.zdv.Uni-Mainz.DE (8.6.11/8.6.11) with ESMTP id TAA24432 for ; Thu, 6 Apr 1995 19:52:46 +0200 Received: from DIRECTORY-DAEMON by MZDMZA.ZDV.UNI-MAINZ.DE (PMDF V4.3-7 #4432) id <01HP143N98YO9KN32Z@MZDMZA.ZDV.UNI-MAINZ.DE>; Thu, 6 Apr 1995 19:52:28 +0100 Received: from degate.gmd.de by MZDMZA.ZDV.UNI-MAINZ.DE (PMDF V4.3-7 #4432) id <01HP143D8MPC9TDCUC@MZDMZA.ZDV.UNI-MAINZ.DE>; Thu, 6 Apr 1995 19:52:15 +0100 Received: from vm.gmd.de by degate.gmd.de (SF for OpenVMS v1.0-alpha) with SMTP id 647D1F84 ; Thu, 6 Apr 1995 19:52:20 +0100 Received: from VM.GMD.DE by vm.gmd.de (IBM VM SMTP V2R2) with BSMTP id 0631; Thu, 06 Apr 95 19:46:23 +0200 Received: from VM.GMD.DE (NJE origin LISTSERV@DEARN) by VM.GMD.DE (LMail V1.2a/1.8a) with BSMTP id 6393; Thu, 6 Apr 1995 19:45:50 +0200 In-reply-to: (message from Philip Taylor on Thu, 6 Apr 1995 18:14:33 +0100) Reply-to: Mailing list for the LaTeX3 project Message-id: <01HP143DDZLU9TDCUC@MZDMZA.ZDV.UNI-MAINZ.DE> X-Envelope-to: schoepf@goofy.zdv.uni-mainz.de MIME-version: 1.0 Content-type: TEXT/PLAIN; CHARSET=US-ASCII Content-transfer-encoding: 7BIT Date: Thu, 06 Apr 1995 18:07:00 +0000 (GMT) From: Frank Bennett Sender: Mailing list for the LaTeX3 project To: Multiple recipients of list LATEX-L Subject: LaTeX modularity Status: R X-Status: X-Keywords: X-UID: 1634 Interesting note, Philip. I couldn't say anything about the merits of a fully modular design, because I don't have anything close to a comprehensive understanding of the inner workings of either plain TeX or LaTeX. I'll leave that issue to others who have the knowledge (or at least the passion) to sustain the debate. But there is an alternative, I think. LaTeX itself can be made more flexible, so that adjusting the way an environment behaves, say, involves less in the way of original research. One gidget that I've come up with that could help 2e/3's designers in this area is an option parser that can cope with a mix of single-character option flags (as in current LaTeX) and option strings. This can be used to embed options in the environment itself, rather than as a \renewcommand's, \setlength's \setcounter's or whatever drifting around somewhere above it. This is not pure `syntactic sugar'. If options are invoked as part of an environment, we can issue error messages that are specific to that environment and --- something lacking in TeX generally --- an explanation of what the alternatives and perhaps the consequences are, to save a rummage through one of the many excellent manuals available from your local bookseller. This parsing mechanism will form part of Camel, the new all-singing all-dancing citation engine that I am developing as an offering to the LaTeX-3 project. If anyone wants a demo file, just drop a line my way. Cheers, -- Frank G Bennett, Jr Law Department, SOAS, London Tel: (071)323-6351 email: fbennett@rumple.soas.ac.uk WWW: http://rumple.soas.ac.uk/~fbennett/