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: Wed, 10 Feb 2010 13:21:22 +0000
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: Joseph Wright <[log in to unmask]>
Parts/Attachments: text/plain (30 lines)
Hello Lars,

> Indeed, there are several possible interpretations:
> (1) Sequences of character tokens
> (2) Sequences of character tokens with normalised catcodes
> (3) Sequences of characters from some alphabet (possibly large),
> representation not necessarily native
> (4) Sequences of LICRs.
> Which you want to use depends on what is being targeted, i.e., what
> strings are going to be used for. \write, \special, and \csname are
> probably the main consumers, and since these want (1), that's probably
> the main thing to support.

That to me is not what I was aiming at. I'm thinking about more "user 
level" strings. For things like \csname you detokenize as part of 
forming the name (using \tl_to_str:n = \detokenize). The same applies to 
\special and \write situations: these are already covered by \tl_to_str:n.

> I would suggest that core string module would primarily operate on the
> (1) kind of string, possibly requiring (2) for some operations, and
> providing the necessary conversion operation 1->2 (trusting the user to
> apply it where necessary, rather than building it into each and every
> operation just to be on the safe side).

That's very much the approach of things like stringstrings, as far as I 
understand it.
Joseph Wright