Hello Manual,

Manuel Pégourié-Gonnard wrote:
> As a package author, I could be tempted to use the expl3 "toolkit" and
> "philosophy" (naming conventions) right now for my new packages, but my main
> concern is the following: is expl3 stable enough for using it in production
> packages? Though I try to keep informed, I must admit I don't feel so sure.

My interest in LaTeX3 also stems from working with it for my own
packages, so I've asked some of this myself in the past.  Perhaps the
answers have slipped through the net :-)
> 
> L3news02 states that "The expl3 code is now considered to be much more
> stable than it was before". expl3.pdf (section 6 "the *experimental*
> distribution") says "the interface will change". OTOH, source3 states that "The
> syntax conventions and functions provided are now ready for wider use." Who's
> right between expl3 and source3? (I assume source3, but...)

This probably reflects the fact that things were written at different
times.  I tried to summarise things in the "snapshot" CTAN announcement,
but didn't check everything else through (I wrote what is in source3,
but didn't update expl3: sorry).  I'll try to sort out these bits and
pieces over the next few days, and perhaps do a CTAN release once the
text makes sense.

For the record here, the idea is that expl3 is stable.  That means if
you do:

\usepackage{expl3}

what you get as a package author should not disappear in the future
(although things can be added).  The recent re-factor is the last one
for the existing code.  There are a few exceptions:
- l3precom and l3chk are not loaded with \usepackage{expl3}, and
therefore might change. (Speaking personally, I would drop both entirely.)
- Anything to do with creating a format is still "anything might happen".

If anything is *removed* from the stable expl3 (very unlikely now) there
will be something added to the file "l3obselete.txt" in the
documentation.  You'll see that it is currently empty, as the dropped
functions from TeX Live 2008 are in "l3obselete2008.txt". The idea is
that TeX Live 2009 represents a "baseline" expl3.

> Another point of concern about using expl3 is that probably we still need to use
> other l2e packages too, and then the syntax will be a mix and expl3 and l2e
> style. I wonder how to handle it (rename the functions I use with expl3-style
> names?).

There are some things that definitely need to be added: for example, I
think we need some kind of floating-point support, perhaps something for
strings, etc.  Of course, if anyone fancies writing them ... (I'm
planning to look at floating points, based on what pgf/pgfplots does, in
the autumn.)

At the same time this depends on what you want to achieve.  To see that
happens at a practical level, I'm moving my own siunitx package over to
using expl3 internally as much as possible
(http://developer.berlios.de/projects/siunitx/).  There, there is a lot
of programming and not too much interaction with other packages, so what
I've found is:

- A lot of stuff is expl3 only.
- There are places that need user functions (for example \ensuremath):
I'm just using them "as is" and will alter things if they come out
differently when a LaTeX3 kernel is written.
- For interaction with the LaTeX2e kernel (for example
\@ifpackageloaded), I'm accepting that "Latex3-on-LaTeX2e" means using
LaTeX2e functions.  So I have things like:

\msg_new:nnnn { siunitx } { incompatible-package } {%
  Package `#1' incompatible.%
}{%
  The #1 package and siunitx are incompatible.\\%
  Use the `emulate=#1' package option when loading siunitx.%
}
\cs_new_nopar:Nn \siunitx_load_check: {
  \clist_map_function:nN { SIunits, sistyle, siunits, SIstyle }
    \siunitx_load_check_aux:n
}

\cs_new_nopar:Nn \siunitx_load_check_aux:n {
  \group_begin:
    \@ifpackageloaded {#1} {
      \msg_error:nnx { siunitx } { incompatible-package } {#1}
    } {}
  \group_end:
}
\clist_map_function:nN
  { SIunits, sistyle, siunits, SIstyle, unitsdef, fancyunits }
  \siunitx_load_check_aux:n
\AtBeginDocument { \siunitx_load_check: }

which are "as much LaTeX3 as possible".  When there is a LaTeX3 kernel,
these will have to change (or more likely I'll have a single DTX with
LaTeX2e and LaTeX3 variants).

One thing I I'm going to need for siunitx is a stable xparse module.
I'm *hoping* the team can agree on finalising it soon (more on that later).

> Maybe the l3 team could publish advice on how to use expl3 in l2e packages, and
> include clear statements about which level of stability can be expected from
> which module 

I guess this should be in expl3.pdf.  I'll see that I can do.

> (I mean, are newer modules such as l3keyval and l3msg as stable as
> more basic modules).

As I wrote both of these (I assume you mean l3keys: l3keyval is the
lower-level and older stuff), I'm possibly not the best person to answer
this!  My feeling is that, as both had quite a bit of discussion before
they were added in the current state they should be as stable as
anything else in expl3.

> I you feel it's time for expl3 to be more widely used and start becoming the
> standard toolkit for LaTeX programming, maybe more communication could help.
> More generally, I feel too few people know about the current l3 achievements and
> philosophy, and this problem should be addressed. (Of course the l3 news are a
> good point in this direction.)

One thing that might be helpful is to ensure that, where possible, the
team discuss things here (i.e. in public).  I try to remember to do
that: hopefully the other team members can be encouraged to do the same.

On the xparse issue, there has been some internal discussion.  Tomorrow,
I'll try to summarise how I think things should go and send it here.

> PS: just as there are projects like texworks aiming at "lowering the barrier to
> entry" in the TeX world for complete beginners, I think it's important to lower
> the barrier to entry in the l3 world for the average (or advanced, to begin
> with) l2e package writer.

Totally agree.  The article in the latest TUGBoat is intended to do
that: some discussions with Karl Berry suggest trying to have a regular
slot in TUGBoat as at least one way to do this.
-- 
Joseph Wright