Content-Type: text/plain; charset=UTF-8; format=flowed; delsp=yes
Mime-Version: 1.0 (Apple Message framework v935.3)
References: <FF6259CB-F8C9-4547-A92C-41D128672DD7@gmail.com>
            <A969C9F865F27B428A8E60E39D3CED152011D9C9F6@KIELDERCMS1.open.ac.uk>,<4A96EA04.8070306@elzevir.fr>
            <A969C9F865F27B428A8E60E39D3CED152011D9C9FB@KIELDERCMS1.open.ac.uk>
Content-Transfer-Encoding: 8bit
Message-ID:  <CC3EE75D-D9B3-43DF-9DDF-114DBF452D22@gmail.com>
Date:         Fri, 28 Aug 2009 12:22:57 +0930
Reply-To: Mailing list for the LaTeX3 project
              <LATEX-L@LISTSERV.UNI-HEIDELBERG.DE>
Sender: Mailing list for the LaTeX3 project <LATEX-L@LISTSERV.UNI-HEIDELBERG.DE>
From: Will Robertson <wspr81@GMAIL.COM>
Subject: Re: [REQ] "TeX: Rejoining the mainstream" - comments requested
To: LATEX-L@LISTSERV.UNI-HEIDELBERG.DE
In-Reply-To:  <A969C9F865F27B428A8E60E39D3CED152011D9C9FB@KIELDERCMS1.open.ac.uk>
Precedence: list
Status: R

Hi Jonathan,

I'm only focussing my comments on two slides: the comparison between  
LaTeX and Python documentation, and the slide on the LaTeX3 project.

* * *

I think it's fair to say that tug.org is the place to look for LaTeX  
documentation:
   <http://www.tug.org/interest.html#doc>
I'm thinking that latex-project would do better simply linking there;  
in terms of maintenance, it's much better to have a single point of  
reference.

So rather than spending half the slides explaining what latex-project  
does inadequately, I think you would do better to explain what/how  
docs.python does and how this would be beneficial for the LaTeX  
community. And possibly whether there are tools that the LaTeX  
community could use for this task.

The problem, of course, is that Python must have several orders of  
magnitude more active developers than LaTeX, and man-power for such  
thankless tasks is extraordinarily thin on the ground for us.

*  *  *

Now onto the LaTeX3 slide. Where should I start? :)

> ▶ Started in 1993 or so (predates XML, Google, . . . )
> ▶ No-one is using LATEX3 for typesetting

LaTeX3 isn't a system to be used for typesetting. At least, not yet. A  
less contentious way to word this bullet point might be something like

"LaTeX3 is a project to continue LaTeX2e past its current status of  
maintained but not developed."

(We've discussed backwards compatibility many times before.)

"Current work of the LaTeX3 project is focussing on the transition  
package authors face in moving from LaTeX2e to the ideas of LaTeX3."

(I think that gets the gist across instead of implying that LaTeX3  
exists but no-one is using it.)


> ▶ Last year, LATEX3 source placed on SVN server, but . . .

Actually, it was 2005: <http://www.latex-project.org/site-news.html>

> ▶ They say it’s explicitly forbidden to publish LATEX3 code

I think you mean "re-distribute the source of the" rather than  
"publish". You make it sound like we're not allowing people to use the  
code (which is available on CTAN and through TeX Live/MiKTeX).

> ▶ Uses proprietary license (Debian accepted, not OSI-approved)

What do you mean by "proprietary" here? The GPL is a proprietary  
license of the FSF. The Apache Licence is a proprietary license of the  
Apache Foundation. Neither of those licences are distributed under the  
terms of themselves.

The LPPL solves a real problem in the community: what do we do when  
authors retire and their packages become no longer maintained but  
another author wishes to step in? Do you think that Karl, Robin, Jim,  
Rainer would simply allow me to update someone else's package on CTAN?

> ▶ Current activity focused new macro programming interface
>
> Here’s an example of the old and new interface:
>
>     \def\mymacro #1{\setbox #1\hbox\bgroup} % Old
>     \cs_new_nopar:Npn \hbox_set_inline_begin:N #1 { % New
>       \tex_setbox:D #1 \tex_hbox:D \c_group_begin_token }


expl3 isn't just about renaming TeX primitives for the sake of it:
  - toolbox of often-used and otherwise useful functions with  
consistent (and readable!) names
  - abstract many expansion control problems with better datatypes

As for examples, expl3 has a couple: (from LaTeX2e kernel)

From:
%        \global\expandafter\let
%              \csname\cf@encoding \string#1\expandafter\endcsname
%              \csname ?\string#1\endcsname
To:
%   \cs_gset_eq:cc
%     { \cf@encoding \token_to_str:N  #1 } { ? \token_to_str:N #1 }

From:
%   \expandafter
%     \in@
%   \csname sym#3%
%     \expandafter
%       \endcsname
%     \expandafter
%       {%
%     \group@list}%
%   \ifin@ ... \else ... \fi
To:
%   \seq_test_in:cVTF { sym #3 } \l_group_seq {...} {...}

Here's another. Consider something completely hypothetical like "if #1  
is true and #2 is false, set csname #3 to the value of csname #4" (if  
you don't think that this is realistic, feel free to come up with  
another code snippet)

\cs_set:Nn \foo_bar:nnnn {
   \bool_if:nT { #1 && !#2 }
   {
     \tl_set:cv {#3} {#4}
   }
}

Assuming #1 and #2 are booleans that you'll be able to test with \if,  
in LaTeX2e you'd end up with something like

\def\foo@bar#1#2#3#3{%
   \if #1
     \expandafter \@firstofone
   \else
     \expandafter \@gobble
   \fi
   {%
     \if #2
       \expandafter \@gobble
     \else
       \expandafter \@firstofone
     \fi
     {%
       \expandafter\def
         \csname #3\expandafter\expandafter\expandafter\endcsname
       \expandafter\expandafter\expandafter{\csname#4\endcsname}%
     }%
   }%
}

But that's not even quite right, because in the expl3 case you can  
extract the value from either a toks or a macro without changing the  
accessor function. Also, sure, you don't need to be so careful about  
the if-nesting in this case but in expl3 you get it all for free.

This is the thing about expl3: we're not really raising the bar on  
what *can* be written in TeX macros. Rather, we're making it much  
easier to do so; if you can code a simple algorithm simply, it really  
doesn't matter if you're using TeX or Lua or Python. In the past,  
however, it hasn't been as possible to code a simple algorithm simply  
in TeX macros.

> It doesn’t even get named parameters (instead of #1).

There's a lot more that qualifies for "doesn't even get" than named  
parameters. I think it's safe to say that not one macro package has  
ever failed to be completed because the author had to write ####1  
instead of #foobar.

As we've previously discussed, I believe that interfaces for keyvals  
are much more important than whether internal function parameters are  
named or numbered (since from the *user's* point of view, it doesn't  
make a shred of difference).

Sorry for the lengthy reply,
Will