LATEX-L Archives

Mailing list for the LaTeX3 project

LATEX-L@LISTSERV.UNI-HEIDELBERG.DE

Options: Use Forum View

Use Monospaced Font
Show Text Part by Default
Condense Mail Headers

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

Print Reply
Message-ID:
Sender:
Mailing list for the LaTeX3 project <[log in to unmask]>
Subject:
From:
Bruno Le Floch <[log in to unmask]>
Date:
Tue, 16 Jul 2013 13:56:04 -0400
Content-Type:
text/plain; charset=ISO-8859-1
MIME-Version:
1.0
Reply-To:
Mailing list for the LaTeX3 project <[log in to unmask]>
Parts/Attachments:
text/plain (45 lines)
Hello Michiel,

As mentioned about the :U / :u proposal, adding an argument type is
not a light decision to take.  The :r proposal avoids one of the
problems of :U and :u, since it does not perform assignments on its
input.  Just like :x, :r only performs assignments to internal
variables.  The slight issue I see is that acting with :r several
times on the same argument gives different values, but that is not
crucial, as those different values do not play any role.

Actually, this slight issue hints at a memory leak waiting to happen:
TeX will never be able to know when all mentions of the unique name
are gone, hence that name (and the associated contents) will need to
remain forever.  This does not seem very safe.

Ignoring this for now, I think the main argument against it is that
given that it is not expandable, it can easily be emulated with
(non-expandable) functions in a two-step process: instead of \foo:r {
ab\cd }, one can have

    \tl_set:Nn \l__some_unique_name_tl { ab\cd }
    \foo:n { l__some_unique_name_tl }

or using a function to create a unique identifier,

    \unique:
    \tl_set:cn { \l_unique_tl } { ab\cd }
    \foo:V \l_unique_tl

or one could write a package providing \pointer_arg:Nn (or something similar)

     \pointer_arg:Nn \foo:n { ab\cd }

In all cases, there needs to be a way to free names once they are not
used anymore.  Also, in most cases (if not all cases) I find it better
to decide on a name of a variable in which to store the data, rather
than relying on automatic generation of variables.  If many such
variables are needed, then perhaps a property list or other structured
data structure is needed, and we can discuss that too.

Thoughts?

Regards,
Bruno

ATOM RSS1 RSS2