X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil] ["1760" "Tue" "30" "June" "1998" "20:16:20" "+1000" "Richard Walker" "Richard.Walker@CS.ANU.EDU.AU" nil "54" "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 MAA12802; Tue, 30 Jun 1998 12:17:09 +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 <14.74F657B5@listserv.gmd.de>; Tue, 30 Jun 1998 12:17:04 +0200 Received: from RELAY.URZ.UNI-HEIDELBERG.DE by RELAY.URZ.UNI-HEIDELBERG.DE (LISTSERV-TCP/IP release 1.8b) with spool id 374954 for LATEX-L@RELAY.URZ.UNI-HEIDELBERG.DE; Tue, 30 Jun 1998 12:16:49 +0200 Received: from ricetub.anu.edu.au (richard@ricetub.anu.edu.au [150.203.166.61]) by relay.urz.uni-heidelberg.de (8.8.8/8.8.8) with ESMTP id MAA20687 for ; Tue, 30 Jun 1998 12:16:45 +0200 (MET DST) Received: (from richard@localhost) by ricetub.anu.edu.au (8.8.2/8.8.2) id UAA18253; Tue, 30 Jun 1998 20:16:20 +1000 (EST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit References: <199806230127.LAA12452@ricetub.anu.edu.au> <199806220631.QAA11602@ricetub.anu.edu.au> <199806271853.UAA29351@frank.zdv.uni-mainz.de> <199806300901.KAA02857@nag.co.uk> X-Mailer: VM 6.29 under Emacs 19.34.1 Message-ID: <199806301016.UAA18253@ricetub.anu.edu.au> Reply-To: Mailing list for the LaTeX3 project In-Reply-To: <199806300901.KAA02857@nag.co.uk> Date: Tue, 30 Jun 1998 20:16:20 +1000 From: Richard Walker Sender: Mailing list for the LaTeX3 project To: Multiple recipients of list LATEX-L Subject: Re: Modules Status: R X-Status: X-Keywords: X-UID: 2614 David Carlisle writes: > 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. Speaking only for myself . . . Hmm . . . well, _I_ was talking about the names of `internal' macros. I wrote: > So instead of e.g. \chk_var_or_const:N we have \chk/var_or_const:N. Again: / _ : all have catcode 11. At this point I diverged from Hans a little . . . I like the <.../...> idea for the user but agree it is too inefficient (the implementation of LaTeX's environments notwithstanding). Going back to my earlier crazy ideas about short/long names I think that a package will generally use `long' names for its internals, and to refer to the internals of the base and other packages. Subject to my earlier reservations, Hans's `environments' can then be used, but I propose that they work differently. If a package splat wants to `export' a macro it must say e.g. \ProvidesPackage{splat} . . . \ExportCommand{my_macro:N}{mymacro} where \splat/my_macro:N is the internal `long' name and \mymacro is the exported name. \ExportCommand `keeps' a list of the correspondences for each package. If _in your document_ you want to `import' the short names you might say: \UseShortNames{splat} . . . \mymacro . . . Or if you only want the short names for a little while: \begin{shortnames}{splat} . . . \mymacro . . . \end{shortnames}. Both do \let\mymacro=\splat/my_macro:N. (I imagine that a part of \ExportCommand's work is to generate/update a macro \splat/do_import: (say) whose expansion is just that.) The only place you need to use \csname . . . \endcsname in this scheme is in the implementation of \ExportCommand. Comments? Richard.