Am Thu, 1 Sep 2011 16:07:07 +0200 schrieb Philipp Stephani:

> 2011/9/1 Ulrike Fischer <[log in to unmask]>:
>> Am Thu, 1 Sep 2011 13:08:32 +0100 schrieb Joseph Wright:
>>
>>> On 01/09/2011 11:57, Ulrike Fischer wrote:
>>>> Is there an expl3 equivalent for a \providecommand?
>>>>
>>>> I could do
>>>>
>>>> \cs_if_free:NT \mycommand {\cs_set:Npn \mycommand {...}}
>>>>
>>>> but I don't find it very elegant to have to type \mycommand twice.
>>
>>> At the code level, the answer is 'no'. Within a module, we'd expect all
>>> functions to be well-defined: if they 'might' be needed, they should
>>> exist. (See for example the fact that a lot of internal aux functions
>>> are created simply to mark the name as taken.)
>>
>>> Now, there is the reality that LaTeX2e stuff is often not so
>>> well-designed and does sometime rely on 'might exist' functions. There,
>>> I'm afraid the construct you've pointed to is the way to go.
>>
>>
>> Well my command (it is more a variable so \tl_set would perhaps be
>> more correct) must exist and that's why I'm using \providecommand:
>> To make sure *that* is exists. I'm not relying on a "might exist"
>> command but try to ensure that it is a "does exist" command.
>>
>> The problem is that it must exist in various encoding definitions
>> files for fontenc, in the sty (chessfss) and that its "value" can be
>> set/changed by the user -- which means that I have no control over
>> the location where the default value should be set. I have to set it
>> in various places in such a way that it doesn't overwrite user
>> settings.
> 
> Wouldn't it be more appropriate to use a key-value option with default
> value then?

What would it help? I still would have the problem that this could
overwrite a setting of a user. 




-- 
Ulrike Fischer