User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; sv-SE; rv:1.9.2.28)
            Gecko/20120306 Thunderbird/3.1.20
MIME-Version: 1.0
References: <4FCE2B42.2090006@morningstar2.co.uk>                              
            <4FCFC6D7.20806@residenset.net>           
            <4FCFD3C5.5050309@latex-project.org>           
            <4FD0630C.6040501@residenset.net>
            <4FD07A72.7060000@latex-project.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
Message-ID:  <4FD0D9BC.9030902@residenset.net>
Date:         Thu, 7 Jun 2012 18:41:32 +0200
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: =?ISO-8859-1?Q?Lars_Hellstr=F6m?= <Lars.Hellstrom@RESIDENSET.NET>
Subject: Re: Separating out 'public' and 'internal' functions/variables in LaTeX3 modules
To: LATEX-L@listserv.uni-heidelberg.de
In-Reply-To:  <4FD07A72.7060000@latex-project.org>
Precedence: list
Status: R

Frank Mittelbach skrev 2012-06-07 11.54:
> Am 07.06.2012 10:15, schrieb Lars Hellström:
>>>> Other approaches I would find preferable to %<@@=foo> is to use
>>>> %%% lines (as an homage to mft) or explicit commands in the .ins
>>>> file; after all, most source files don't contain code for
>>>> multiple l3-modules.
>>>
>>> To be honest I don't like that much but perhaps this is something
>>> one just needs getting used to.
>>
>> Note that these are "/other/ possibilities I would actually find
>> preferable to assignment-guards"; you snipped my preferred realm of
>> solution without comment.
>
> sorry that was after midnight. You mean
>
>> FWIW, an alternative way of embedding extra directives into a .dtx
>> file that I have in production is to designate a specific docstrip
>> module as containing code that is directives for the stripper. If one
>> picks the very crude syntax for "directives" that each codeline in
>> the @@ module sets the current @@ replacement then the above could
>> become
>>
>> %<@@>foo
>> %<*pkg>
>> \@@_function:nn % Will be converted to \__foo_function:nn
>> \l_@@_variable_tl % Will be converted to \l__foo_variable_tl
>> %</pkg>
>
> Maybe I still don't quite understand directives but
>
> %<@@>foo
>
> doesn't really look much different to
>
> %<@@=foo>
>
> except that I think it is less readable but mileage may vary
>
> Perhaps you can expand on that once more?

The difference is that in %<@@> the guard is just a guard, guarding some 
piece of code which may perhaps be destined for some target, whereas in 
%<@@=...> it is something different that just happens to be shoehorned into 
the same syntactic realm. If docstrip sees %<@@=foo> it will check if 
"@@=foo" is true for any output file, which it most likely not the case and 
so nothing happens, but still: an incorrect interpretation is applied to the 
material.

If docstrip sees %<@@>foo it checks whether some output file has @@ true, 
and since none has it continues to the next line. My idea is that l3docstrip 
could treat the @@ module (\Module in the sense of doc.sty) somewhat like a 
stream of commands that it will react to immediately rather than write out 
to a file. %<@@>foo is, as I wrote, a rather crude syntax to employ here; 
more flexible syntaxes could be

%<@@> \AtAtReplacement{foo}

or

%<@@> @@ = foo, sourceencoding = latin1

where the latter (contents is keyval list) illustrates having and setting 
other parameters[*] besides the @@ replacement. Of course, there's no 
particular need to call the docstrip module @@ as well in these cases.

[*] I tend to be very much back and forth regarding whether it would be 
useful to support encoding conversions as part of docstripping. It's 
probably not so much use for pure-TeX projects, but mixed language projects 
could be another matter.

In the case where I'm employing this kind of "directives module" (with 
terminal "docstrip.tcl::catalogue"), I use it as an in-.dtx catalogue of 
things that can be generated from the .dtx. The reasons this became more 
practical than using a traditional .ins file was because (i) the version 
numbers of certain generated files had to be included in the file name (/so/ 
not the (La)TeX way) and (ii) it in this case turned out that the natural 
unit for a source file corresponded to many small generated files.

Lars Hellström