Frank Mittelbach writes:
> fine, however you could take the exercise further and actually apply
> some of the functionality of L3PL. i've appended my version below

Yes, I could have done that if I knew what I was doing!

>  > %<notpackage>\RequirePackage{l3io}
> actually it works if there is a blank line after the \RequirePackage

Indeed (I checked) - very interesting!

>  > \def_new:Npn\tools/xr/loop:n#1{\ior_open:Nn\@inputcheck{#1}\scan_stop:
>  >
>  > A gotcha:  you now need the braces around #1.
>
> and no \scan_stop: :-)

Yes, that's the sort of thing that happens when you don't think
carefully about what you're doing.  I plead that I was (and still am)

>  > The \\ in both these lines was \[log in to unmask]  I wanted to change that to
>  > \tools/xr/dummy or something like that, but this doesn't work because
>  > \tools/xr/test:nnnn gets invoked when reading the .aux file, and at
>  > that stage / has catcode 12 again.  (Using a _ wouldn't work either,
>  > of course.)
>
> ???? works i'd say in my implementation

As usual you are right, and I can't even reproduce this problem.  I
think it happened when I was using the \RequirePackage, but it's not
worth tracking down further at this stage.

> ----------------- test
>
> \begin{filecontents}{l3xr}

l3xr.sty, natch . . .

> % well, that has already an interface in 2e
>
> \newcommand\externaldocument[2][]
> {
>  {
>   \makeatletter
>   \def:Npn \l_xr_prefix_tlp {#1}
>   \seq_push:Nn \l_xr_subfiles_seq {#2.aux}
>   \xr_loop:
>  }
> }
>
> \seq_new:N \l_xr_subfiles_seq

No, if you want to do it properly' you must say:

\newcommand\externaldocument[2][]
{
{
\makeatletter
\tlp_set:Nn \l_xr_prefix_tlp {#1}
\seq_push:Nn \l_xr_subfiles_seq {#2.aux}
\xr_loop:
}
}

\tlp_new:Nn \l_xr_prefix_tlp {}
\seq_new:N \l_xr_subfiles_seq

> \def_new:Npn \xr_loop:
>  {
>   \seq_pop:NN  \l_xr_subfiles_seq \l_xr_file_tlp
>   \ior_open:Nn \@inputcheck {\l_xr_file_tlp}
>   \ior_eof:NTF \@inputcheck
>     {
>      \PackageWarning{l3xr}{^^JNo~ file~ \l_xr_file_tlp^^JLABELS~ NOT~ IMPORTED.^^J}
>     }
>     {
>      \PackageInfo{l3xr}{IMPORTING~ LABELS~ FROM~ \l_xr_file_tlp}
>     }
>   \seq_empty:NF \l_xr_subfiles_seq
>                 { \xr_loop: }
> }

\seq_pop:NN is not listed in the first part of the l3seq
documentation.  It was not obvious that one is allowed/supposed to use
it.

And you to declare' this as well:

\tlp_new:N \l_xr_file_tlp {}

The rest seems OK . . . .

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.

Clearly I haven't yet got my brain around what one is supposed to do
with all of the new data types (prop, seq, tlp) - and I doubt anyone
else listening has.  Because there are no examples I have to do a lot
of mind-reading.  So I am going to study your l3xr more carefully and
have a go at a larger package.  (I've been in Melbourne since February
and I'm moving back to Canberra this week, so don't hold your breath -
but I'll do my best!)

> com'on. with a spec as is you can experiment with modules if you
> really want to as easily as with some other. just introduce / as a
> sub-module separator in the first word. you may be right that it would
> look perhaps look ugly but it would work without any problem and would
> prove either me or you wrong.
>
> so \foo_bar:nn would be module foo function bar
> and \foo/baz_bar:nn would be module foo submodule baz function bar
>
> so what? (and it doesn't look so bad actually)

I am going to think about that one for a while.

First impressions, using my example:

\tools/xr/exp_list:   becomes    \tools/xr_exp_list:

It has a certain cringe factor' about it, because xr' has somehow
moved from the name of the package to the name of the function.
To me, allowing _ within the <description> part and using it as the
separator is really ugly.

ObPolemic: But maybe the LaTeX world is too small for a hierarchical
naming scheme - even though CTAN (not to mention TDS) would suggest
otherwise.