upTeX の \if と \ifcat

[aminophen]

\ifcat の比較対象について，気になることがあります。

\ifcat (文字1)(文字2) と書いた時，pTeX の場合は「その文字が和文ならば \kcatcode，欧文ならば \catcode」を見比べるようです。

\ifcat a漢 \message{a=漢}\fi
\ifcat aあ \message{a=あ}\fi
\ifcat a！ \message{a=！}\fi
\ifcat 漢字 \message{漢=字}\fi %=> True
\ifcat 漢あ \message{漢=あ}\fi
\ifcat 漢！ \message{漢=！}\fi
\ifcat あい \message{あ=い}\fi % => True
\ifcat あ！ \message{あ=！}\fi
\ifcat ^^41^^42 \message{^^41=^^42}\fi % => True ("A" vs. "B")

upTeX についてもほぼ同様なのですが，\kcatcode を 15 にした場合に違和感があります。

%#!uptex
\showthe\kcatcode`^^c0 % => 15
\showthe\catcode`^^c0  % => 12
\showthe\kcatcode`^^b0 % => 18
\showthe\catcode`^^b0  % => 12
\ifcat ^^b0^^c0 \message{^^b0=^^c0}\fi % => True (!?)
\bye

ここで真になるということは，両方の文字の \catcode を比べていると思われます。ここで ^^c0 は non-CJK 文字トークンなので「12」のはずですが， 一方 ^^b0 は CJK 文字トークンなので，\catcode は特に意味を持たないはずです。にもかかわらず，上記のように CJK 文字トークンから \catcode が読み出されるのは，直感に反すると思います。

[aminophen]

メーリスを見ていない方のために参考まで：

• 発端は「expl3 (regexpatch) が (u)pTeX の和文文字でエラー (issue:248)」でした。
• そこから発展して，LaTeX team の方から「ある文字トークンが和文か欧文か判定する方法」を教えて欲しいという話をいただきました。（スレッドが前後したり，転送メールが挟まったりしていて読みにくいですが，issue:248 から連番の順に沿っていけば流れは掴めると思います。）
• その判定に \kcatcode が使えるんじゃないかろうか → そういえば \ifcat はどうだったろうか… と私が調べているうちに，冒頭の疑問点に到達しました。

[t-tk]

ご指摘ありがとうございます。
ご指摘の点は深く検討して決定した「仕様」ではなく、
たまたまそうなってしまっていた類のものです。

より自然な仕様が考えられ、それに沿って実装を提案していただけるのなら取り入れたいです。

[aminophen]

すみません，最初の質問の

一方 ^^b0 は CJK 文字トークンなので，

は間違っていますね。確か ^^ab の記法は「欧文」を表す（固定）だったので，\ifcat の結果自体は自然だと見なす方が良いのかもしれません。そうすると，不自然なのは

\showthe\kcatcode`^^b0 % => 18

の行で，ここで 18 が返ってしまうのがミスリーディングだと見なすべきですかね。

edit: 一方で，この挙動には意味があるようにも思えますね。というのも「U+00B0 が欧文か和文かわからない状況下でその \kcatcode を調べたい」という時に \kcatcode`^^b0 という書き方が使えるからです。しかし，同じことは \kcatcode"B0 でもできるので，それほど重要な挙動でもないという見方もできます。

[aminophen]

https://twitter.com/zr_tex8r/status/1119966520321265664

upTeX の \if について，「文字コード256 (U+0100) の “Ā” を和文扱いにした文字トークンが，\if による比較で制御綴と同一視されてしまう」という問題があります。（∵ tex.web によると，\if は制御綴に便宜上「文字コード256」を与えるため。）

[aminophen]

たぶん，uptex-m.ch で Test if two characters match の二か所の 256 を max_cjk_val に置き換えればいいのだと思いますが，忙しいので後日（いずれにせよ TeX Live 2020 ですし。）

[t-tk]

@h-kitagawa さんの修正案 bdfba95 では ptex-base.ch の方も 256 を max_cjk_val に置き換えているようですが、pTeXの方もそれでよいのでしょうか?
あまり理解していません。

[h-kitagawa]

ptex-base.ch の方も 256 を max_cjk_val に置き換えているようですが、pTeXの方もそれでよいのでしょうか?

pTeX だと和文の文字コードが 256 になることはない（と思う）のですが，「文字コードは原理的にこの値にはなりえない」値に統一したほうがわかりやすいだろう，という考えからです．

……と思って今 XeTeX のコードを見直したら，

primitive("relax",relax,too_big_usv); {cf.\ |scan_file_name|}
primitive("par",par_end,too_big_usv); {cf.\ |scan_file_name|}

や

if eq_type(cur_cs)=undefined_cs then
  begin eq_define(cur_cs,relax,too_big_usv);
        {N.B.: The |save_stack| might change}
  end; {the control sequence will now match `\.{\\relax}'}

のように他にも 256 → too_big_usv (=0x110000) にしている箇所が見つかりました．どうやら Omega 由来のようですが，(u)pTeX でこちらも変えたほうが良いのかはよくわかりません．

[t-tk]

upTeXエンジンで問題があるがpTeXエンジンで無問題の場合、方針として

1. なるべくpTeXのソースは触らず upTeX のソースだけを修正する
2. pTeX と upTeX の差分が小さくなるように pTeXのソースに触るのも厭わない

の2つの方針が考えられると思いますが、2の方針でよいでしょうか?
今回のパッチは2で書かれていると思います。一方、2の方針では修正部分がpTeXエンジンにエンバグをもたらしてしまうリスクがわずかでも高まってしまうという負の部分もあると思います。
私はトータルで見て将来のメンテナンス性が良くなるであろう2の方針でよいと思っています。

[aminophen]

2. pTeX と upTeX の差分が小さくなるように pTeXのソースに触るのも厭わない

私もこの 2. でよいと思います。

[t-tk]

ブランチ ifcat_cs をここの master にマージしTeX Live svn にコミットしました。(r51021)
さらに修正がある場合はご遠慮無くお願いします。