User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101
            Thunderbird/24.4.0
MIME-Version: 1.0
References: <533473A9.3020401@residenset.net>           
            <53387AD3.4060902@morningstar2.co.uk>
            <533965E4.2060205@residenset.net>
Content-Type: text/plain; charset=ISO-8859-1
Message-ID:  <53398E5F.8020507@morningstar2.co.uk>
Date:         Mon, 31 Mar 2014 16:48:47 +0100
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: Joseph Wright <joseph.wright@MORNINGSTAR2.CO.UK>
Subject: Re: harmless package public beta
To: LATEX-L@LISTSERV.UNI-HEIDELBERG.DE
In-Reply-To:  <533965E4.2060205@residenset.net>
Precedence: list
Content-Transfer-Encoding: quoted-printable
Envelope-To: <rainer.schoepf@GMX.NET>
Status: R

On 31/03/2014 13:56, Lars Hellstr=F6m wrote:
>> I think 'mostly OK' is the verdict. I spot a few places things look
>> wrong:
>>
>>   - \harmless_appendto_toks:nn - #2 is a toks, so N-type
>=20
> I think I wanted to allow things like \toks4 as #2, even if I only use
> it with \toks@ as that argument. Hence n rather than N; in any case the
> implementation does not assume a single token.

I did wonder about this :-)

>>   - \harmless_userboolean:nTF  - #1 seems to be a single token,
>>     so again N-type
>=20
> Nope, it is explicitly stated that it also accepts a TF-style
> conditional as #1 (e.g. \IfFileExists{foobar.cfg} or \ifthenelse{<some
> test>}), so again an n.

OK, I'd not checked in detail.

>>   - \__harmless_quat_split- (etc) - all missing an arg spec, which
>>     looks w-type to me
>=20
> My thinking was that these are "constants" rather than "functions", and
> for that reason have no argspec part. Even if one considers them
> functions, they don't take any arguments, so why would they have a w?

If they are constants then  \c__harmless_ ...

>> I'd also suggest the 'sheep and goats' separation of all commands into
>> fully expandable or \protected.
>=20
> Not sure there could only be those two, but I can certainly change some
> \newcommand's into \DeclareRobustCommand's.

There are very few commands that don't seem to fall into one of the two
categories. (I've perhaps got one set for siunitx, but in a very unusual
use case.) Most commands either:

 - Should/can work inside \edef =3D> expandable
 - Don't (assignments, ...) =3D> \protected

Note this is nothing to do with \DeclareRobustCommand, as those are not
engine-robust.

>> (Note: moving the code to expl3 would require quite a bit of work, but
>> that's a different question.)
>=20
> Beyond the rote substitution of l3names for primitives and 2e core
> macros, is there something particular you think about? (I suspect the
> unimperative coding style could be one issue. ;-)

A general impression, not least in that you've coded things by hand that
would be done using expl3 kernel functions. The other very obvious one
is that we don't use toks :-) A full analysis would take some time!

I forgot one thing before: as you are using the expl3 namespace in a
deliberate way, am I OK to add "harmless" to the prefix list with a note
about the use?

>> More broadly, there are big open questions that
>> some of this is linked to. One is LICR-type input. As you'll see when =
we
>> land our 'new' case changing functions, the team feeling on input
>> methods for *new* code is to stick close to the engines rather than to
>> the LaTeX2e approach.
>=20
> You mean a token with character code 229 (U+00E5) is more canonical tha=
n
> \r{a} as encoding of that character? That's actually close to the way
> harmless would do it (under the \HighCharsUnicode setting). For
> typesetting, there is conversely \UnicodeCharUsesChar.

In that area, yes. Thinking is currently as follows: for UTF-8 work,
there are two engines which can do the job. Supporting non-UTF-8 input
for chars outside of the 8-bit range is something that 'new' code really
should avoid. That doesn't negate use of inputenc, etc., for 'real
world' cases now but does suggest that for new code we might want to
take a different take. For example, the current thinking is that for
'text level' case-changing functions we will support only 'engine
native' input, which implies that at some stage we'd want to as you say
do mappings for UTF-8 engines going in the \r{a} =3D> U+00E5 direction.
(At a user level, things like \r{a} for a 'one-off' accent remain useful
even with a UTF-8 engine.)

This clearly to be discussed further!
--=20
Joseph Wright