Frank Mittelbach writes:
> > 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).
> good idea, anybody willing to do this?
Hooray - you like one of my ideas :-) OK, unless someone else is
realy keen on getting some experience, I'll have a go.
> . . . actually i could have also produced
> essentially the same algorithm by not using the stack commands but
> instead using those other sequence commands.
True enough, I just wasn't sure whether you chose to implement it
differently or whether it just turned out that way.
> > . . . it might well serve as a deterrent to those who
> > come to LaTeX3 as beginners.
> i think i disagree here. what i meant is that you do need to learn
> some layer whether it'll be current latex internal commands (by looking
> at the latex source or other packages) or be something like the L3PL
> language is not much different (except for those who already mastered
> most of the mess of the current latex)
The difference will be that it's `official' and documented. Let's
hope the difference counts!
> > 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.
> i already said that this was a remark concerning latex2e --- and if
> people are willing to help updating the documentation of the .dtx
> files for 2e we are too willing to accept such help!!! just drop us a
> note and we provide you with the file of your choice (latest version
> -- sometimes fixes for the next release are already in) lock it in rcs
> and put the updated documentation with your name on back in. certainly
> we can make these sources better and it is still worth doing even
> though we are talking about a sort of paradigm change here.
A part of me really wants to do this. Another part of me says `why
bother?', when, for example, my energy would be better spent adding
the functionality of \@for and \@tfor to l3seq than to documenting
ltcntrl. I think from what you have said so far that this is your
> we don't have the intention of closing doors at this stage. but at the
> other hand we believe that there is not much gained if X suggests to
> change the syntax slightly in this direction, then we have a long
> discussion on whether or not this is how other people see this, then Y
> suggest some other twist, ... and all of this gets implemented
> straight away (by us) and changed over and over again instead of
> providing new functionality within the framework as is and change it
> completely on the surface later.
I accept this completely. I agree that the onus is on me (and others)
to `prove' me (us) `right', and that any change in the syntax has to
be done by me (us).
> i also have nothing whatsoever against the idea that somebody sits
> down and takes apart all the packages we have put together and does
> some global replace and produces a version more to his or her liking.
> we can certainly put such a version on CTAN as well.
That is a very positive statement - thank you. As I said, I don't
want to change things on a whim, but I appreciate your openness in
allowing me (and others) to put forward other ideas for
> but what i'm not going to do (me personally) is to do that type of
> work just because some people think that _ are bad or the colon should
> be a . or Modula2 type of syntax is better. that would drag on forever
> without anything gained because there are probably as many opinions on
> this subject as we had emails on it. if somebody wants to, please do
> so, but don't ask us to do it for you now.
Well, I wasn't asking you to do that. I will indeed do it myself.
I can use Emacs's regular expression search and replace as well as the
next person . . . .
> let me also say that i *DON'T* like the language as it is on many
> special points (not the last are the many _) but just like here on the
> list with perhaps 4-6 people commenting on the look of it we had
> internally also very different opinions what looks best or works
> best. and at one point we decided to stop and just pick one to
> actually get functionality provided.
If you have records of the internal discussions I'd like to see them
(if you don't mind). I'm sure some of your frustrations are because
you have to repeat arguments that have already been settled.
> you also need a higher-level interface (or set of interfaces) which
> are also official to avoid all the situations that people because of
> nothing being put into such a status hooked into any layer with
> disastrous effects when something was reprogrammed (or just fixed or
> optimized :-)
I think we all know this from experience! The hard problem will be
deciding what is important enough to become `official'. An
interesting comparison is with MacOS X and `Carbon'. The plan is to
cut the Mac's programming interface from about 8000 calls down to
a core of about 2000 calls. `Less is more', so they say.