LATEX-L Archives

Mailing list for the LaTeX3 project


Options: Use Classic View

Use Monospaced Font
Show Text 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: Sun, 4 Dec 2011 22:43:06 +0100
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: 7bit
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 (33 lines)
Am 04.12.2011 21:16, schrieb Bruno Le Floch:

>> Yes, there are a few cases where such a convention would not be
>> sufficient, for example \prop_(g)get:NnN. As I said, this mirrors the
>> situation with TF functions, where there are a few in which the
>> documentation does have to cover more complex situations on a
>> case-by-case basis.
> Side note: \prop_gget:NnN doesn't and shouldn't exist. We may want to
> add somewhere a mention that 'pop' and 'gpop' functions always return
> their value locally.

agreed, we decided long ago that all "get" or "pop" would be local in 
their return value and only in case of "pop" the change to the 
underlying data structure could be global.

So yes that should probably better documented up front as well.

> =
> Where functions for variable manipulation can [perform assignments]
> either locally or
> globally, the latter case is indicated by the inclusion of a "g" in the
> [second part] of the function name. Thus \tl_set:Nn is a local function but
> \tl_gset:Nn acts globally. Functions of this type are always documented
> together, and the scope of action may therefore be inferred from the
> presence or absence of a "g".

sounds good to me