## 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: First experience with xr under L3PL

From:

Date:

Tue, 7 Jul 1998 17:55:46 +1000

Content-Type:

text/plain

Parts/Attachments:

 text/plain (102 lines)
 Frank Mittelbach writes:  > > The rest seems OK . . . .  >  > what a relieve :-) On closer inpsection you also need this somewhere: \tlp_new:Nn \l_xr_line_tlp {} So as we have seen there is a Fortran-style implicit declaration of tlp's in certain circumstances, e.g. when used as the second argument of \ior_to:NN. I'd like to suggest that the check' option used in the dtx files be changed into a package option, say checkdef' (you can think of a better name). At the moment the decision of whether or not to check arguments is made once for all time when docstrip is invoked. Clearly we are still used to using \def in the same way as Lisp's setq, i.e. as a general definition mechanism that doesn't care about what you are defining (i.e. whether it has a previous definition). The new version of xr now has three declarations' that are evaluated when the package is loaded. I can live with that; I (we) just need to remember that a new discipline is required. I expect that a syntax checker for L3PL will find uses of seq's, tlp's, etc. without corresponding declarations. Your algorithm is also subtly different. The original version is careful to process \@input's in the order in which they are encountered, but your version uses a stack. If there are no label conflicts, the net effect is the same. But if there are multiple conflicts, the original version stops at the first conflict, whereas yours might even stop at the last first and the first last! In your favour: since you use push and pop operations it's obvious that your version handles \@input's back-to-front, whereas it wasn't obvious in the original that \@input's are handled front-to-back (both versions using a breadth-first traversal).  > > Tim's questions are really quite important for the average' package  > > writer, because they will be programing in-the-small', and the xr  > > example is quite a good one for that. Even such a small package has  > > needed a total re-think and re-writing.  >  > true but is it so much different from having to hunt through the LaTeX  > source to find you way in providing packages? Well . . . it's yet another layer of knowledge that has to be mastered before you can start doing non-trivial things. Those of us who have been using TeX for ten years or more will shrug our shoulders and learn it anyway, but it might well serve as a deterrent to those who come to LaTeX3 as beginners.  > After all a lot of the documentation therein was provided by us during  > the last years before that its internal documentation was very much  > out of date (still is in some parts). If you are happy to release out-of-date and inconsistent documentation for incomplete packages then in fairness to us - your guinea pigs - _everything_ must be up for grabs. Frank wrote elsewhere:  > just to change all the files to some new convention takes some effort  > which can be better spend. at the moment at least! Perhaps (the fewer inconsistencies in the original, the easier it will be), and I am not suggesting doing it on a whim; but if you try to close doors at this stage I - and I suspect others - will stubbornly stick in our arms and legs. Even if you have already written five chapters of your next book :-)  > what i mean is, you need to have got a feeling for it but that it true  > right now as well except that right now because of nearly no  > conventions people are forced to reinvent the wheel over and over just  > because they don't know that some command or datatype or whatever  > already exist somewhere. Agreed. A good example from the internals of LaTeX is the \@for and \@tfor constructs. Unless you read the old lplain.tex or the new ltcntrl.dtx you would probably have no idea that these constructs existed. The problem here is not one of consistency, but rather (a) these constructs have never really been official' and advertised, and (b) there is still no proper documentation. \@for, \@tfor, and many other internal macros of LaTeX deserve promotion' to L3PL. Much of this reinvention will then be avoided.  > so yes you need a re-think, you probably don't need much of a  > rewriting for an existing package if you just mainly do a manual  > translation but you can gain a lot once you start replacing all you  > low-level private code by already provided solutions for many of the  > basic functionality which right now is often repeated over and over  > again in packages. It sounds as though it must be true, but let's see. As I said earlier, we will go anywhere you take us, but let's enjoy the journey and learn from it. Frank also writes:  > . . . the  > solution is that you provide a replacement book for the TeX book. So this is your next book . . . my hand is creeping up . . . pick me! :-) I would be happy to contribute a chapter or two or proof-read or . . . Eine deutsche Uebersetzung waere auch moeglich . . . :-)`