LATEX-L Archives

Mailing list for the LaTeX3 project

LATEX-L@LISTSERV.UNI-HEIDELBERG.DE

Options: Use Classic View

Use Proportional Font
Show HTML Part by Default
Condense Mail Headers

Topic: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Sender: Mailing list for the LaTeX3 project <[log in to unmask]>
Date: Tue, 15 Apr 2014 11:41:17 +0200
Reply-To: Mailing list for the LaTeX3 project <[log in to unmask]>
Message-ID: <[log in to unmask]>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
In-Reply-To: <[log in to unmask]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
From: Frank Mittelbach <[log in to unmask]>
Parts/Attachments: text/plain (63 lines)
Am 14.04.2014 15:30, schrieb Lars Hellström:

> 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 
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 
functions are supposed to be constant so c_ should definitely implicit 
in my opinion)

also

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

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

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

cheers
frank

ATOM RSS1 RSS2