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
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:
Subject:
MIME-Version:
1.0
Content-Transfer-Encoding:
7bit
In-Reply-To:
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

ATOM RSS1 RSS2