Content-Type: text/plain; charset=iso-8859-1
Mime-Version: 1.0 (Apple Message framework v1077)
References: <4B727378.8060704@morningstar2.co.uk>                      
            <20100210100943.GA3759@oberdiek.my-fqdn.de>                      
            <4B7298D6.7080206@morningstar2.co.uk>           
            <20100210145258.GA18188@oberdiek.my-fqdn.de>
            <4B72D339.5080104@morningstar2.co.uk> <4B7AA5D7.8010104@elzevir.fr>
Content-Transfer-Encoding: 8bit
Message-ID:  <1AE267EA-F412-43F4-AB00-49082CFEE062@gmail.com>
Date:         Wed, 17 Feb 2010 08:47:52 +1030
Reply-To: Mailing list for the LaTeX3 project
              <LATEX-L@listserv.uni-heidelberg.de>
Sender: Mailing list for the LaTeX3 project <LATEX-L@listserv.uni-heidelberg.de>
From: Will Robertson <wspr81@GMAIL.COM>
Subject: Re: String module
To: LATEX-L@listserv.uni-heidelberg.de
In-Reply-To:  <4B7AA5D7.8010104@elzevir.fr>
Precedence: list
Status: R

On 17/02/2010, at 12:34 AM, Manuel Pégourié-Gonnard wrote:

> By the way, I find is rather weird, that \tl_if_eq doesn't really compare token
> lists, but only their conversions as TeX strings. IMO it would be clearer to
> have a \str_if_eq::nn(TF) function in the string module, and then conversion
> functions from the tl to the str data type.
> 
> Such conversion function could also be the place to implement "string input
> methods" if they are needed. Eg, the most basic conversion function would be
> something like \edef + \detokenize, but one could imagine a conversion function
> that locally redefines \% as expanding into a catcode 12 %, etc. before
> performing the \edef, so that a user can easily input arbitrary strings.

FWIW, I'm in favour of these ideas.
Clearly up some of the edge cases with tl_replace_in (for example), which doesn't accept braces, would be helpful, I think.

-- Will