User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101
            Thunderbird/24.4.0
MIME-Version: 1.0
References: <534BE2F5.6020603@residenset.net>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Message-ID:  <534CFEBD.9080307@latex-project.org>
Date:         Tue, 15 Apr 2014 11:41:17 +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: Frank Mittelbach <frank.mittelbach@LATEX-PROJECT.ORG>
Subject: Re: Variable functions, or function-valued variables
To: LATEX-L@LISTSERV.UNI-HEIDELBERG.DE
In-Reply-To:  <534BE2F5.6020603@residenset.net>
Precedence: list
Content-Transfer-Encoding: quoted-printable
Envelope-To: <rainer.schoepf@GMX.NET>
Status: R

Am 14.04.2014 15:30, schrieb Lars Hellstr=F6m:

> The typical example of this would be a callback function: something
> that a module calls at specified points, but which the user of that
> module is expected to define. Treating this as just a function loses
> the specification of the scope for that variable. Treating it as a
> variable of type tl loses the specification that it takes arguments.
> What I found natural is to use a name of the form
>
> \<SCOPE>_<MODULE>_<DESCRIPTION>:<ARG-SPEC>
>
> e.g.
>
> \l_harmless_callback:nn
>
> This could be interpreted both as adding a SCOPE part to function
> names (the vast majority of functions without a SCOPE are implicity
> considered to be c_ constant), or alternatively as proclaiming any
> :<ARG-SPEC> to be a valid _<TYPE> for a variable.

that's an interesting point. I'm a little torn over this to be honest.
On one hand I rather like the idea to mark functions that are supposed
to be defined/manipulated by a user of a package specifically but on the
the other hand I'm not so sure the suggested convention would work
nicely in practice as it blurs the  distinction between traditional
"data" variables a bit and I'm not sure how that would work out (though=20
that is something to  experiment with I guess).

if that suggestion is taken up then

\<SCOPE>_<MODULE>_<DESCRIPTION>:<ARG-SPEC>

with <SCOPE>_  being either l_ or g_ sounds fine (the majority of=20
functions are supposed to be constant so c_ should definitely implicit=20
in my opinion)

also

\l__<MODULE> or \g__ should never been allowed as module internal=20
functions by definition should not be a user or programmer outside the=20
package.

One question to keep in mind though is do we really would see both l_=20
and g_? r would we see many of them at all? If a package expects a=20
number of such "variable functions" to be set up before some of its=20
interfaces can be used then you have the issues of state/scope to deal=20
with and the fact that such a package could be used by several other=20
packages etc. In that case I wonder if it wouldn't be better to=20
encapsulate the setup by providing a setup function and use an internal=20
function for the "variable function" (in which case the direction would=20
then be somewhat opposite, ie we would suggest to use \l_@@ and \g_@@=20
for the variable functions and the setup function would become an=20
unchangeable constant function taking code as arguments

Speaking of "user": we are talking here "user" as in programmer of some=20
other package using the former one, not end user using document level=20
customizations. Because for those I would maintain that no expl syntax=20
should leak and any such customizable function would need to be=20
encapsulated by a proper interface - at least this is my take on this

cheers
frank