人力検索はてなの質問をキャンセルしたら内容が消えてしまったので、こちらに残しておく。
昔読んだ数学の児童書を探しています。 内容は断片的にしか覚えていません。おそらく12年以上前に図書館で読んだ本です。 小説仕立ての本であり、ワープロのフロッピーディスクに、奇妙な外字で書かれた文書が保存されていて、それはコンピューターに住む未知の生命体の残した、未知の数学に関するメッセージだったというような話だったように思います。いくつかのトピックがあったと思いますが、そのひとつとして、p進数（p-adic number）に関連するようなトピックがありました。もしかしたら、大きめの判型の本で、上下で2冊分の本だったかもしれませんが、確かではありません。 少ない情報ですが、心当たりがあるかたはよろしくお願いします。
http://q.hatena.ne.jp/1443281726
@mandel59 大森英樹先生の本ではないでしょうか。 http://t.co/CdMKvPGUmJ
— koji hasegawa (@myfavoritescene) 2015, 9月 26ありがとうございました。
この記事へのツッコミみたいなことを書くつもりだったけど、あんまり関係ない話になったので、サイドストーリーみたいにして読んでください。
前回、数学的な関数の定義の話があったけど、あれは写像の定義であって、個々の分野で「関数」と呼ばれているものと、いつでも一致するとは限らない。まあ普通は関数と言ったらほとんどの場合写像を指すので、少し違う物を指すときは、多価関数とか連続関数みたいに、別の名前を付けていることも多い。
で、プログラミングに関する文脈で「関数」と呼ばれるものが写像と一致するかといえば、もちろん一致しない。ある程度似た部分もあるけど、違う性質を持っている。この違いを、数学的にどうやって説明するかが問題になる。計算の性質を説明するための抽象モデルが抽象書換系で、ラムダ計算の意味も、抽象書換系によって定義できる。この定義の方法は、写像の定義とは大きく異なっている。
写像とラムダ項の間には、具体的にどういう違うがあるのだろうか。
一方で、写像には右一意性という性質があるが、ラムダ計算には合流性という性質があり、計算が停止する範囲では、写像とよく似た性質を持っているということが言える。
a -> bというのは、引数にa型の値をとり、b型の値を返す関数の型だ。Monad mが存在するような任意の型コンストラクタmについて、m aというのは、a型の値を生成する（Monad mの）アクションの型だ。という型の意味を理解していれば、関数(>>) :: Monad m => m a -> m b -> m bは、その型から、
Monad mが存在するような任意の型コンストラクタmについて、
m a型の値（アクション）（これをxとする）を引数にとり、m b -> m b型の値（関数）（これは(>>) xと表せる）を返す関数で、つまりその返される関数は、
m b型の値（アクション）（これをyとする）を引数にとり、m b型の値（アクション）（これは(>>) x yと表せる）を返す関数で、つまりその返されるアクションは、
b型の値を生成するアクションだということが読み取れる。
一方で、「m a型の値（アクション）xを破棄する」といったことは、型から読み取ることはできないし、事実でもない。実際、(>>) x y = (>>=) x (\z -> y)と定義でき、アクションxは破棄されない。破棄されるのはアクションxが生成する値で、それはxではなくzだ。
関数が値を返すということと、アクションが値を生成するということには大差がないように見える。実際に、多くのプログラミング言語は関数に副作用を認めていて、関数とアクションを区別しない。しかし、関数が、引数が定まれば返り値も一意に定まるという性質を持っているのに対し、アクションは、生成する値が定まるという性質を持っていないから、同列に扱おうとすると、式の値が一意に決まらなくなる、という困ったことが起きる。
そもそも、式の値はなんだろうか。（ここで書いている「手続き型プログラミング」「関数型プログラミング」という分け方は一面的なものに過ぎないから、あんまり深刻に考えないで欲しいのだけれども、）手続き型プログラミングにおいて、値というのは手続きから手続きへ渡されたり、変数に代入されたり読み出されたりするものであって、「式が値を持つ」という考えは、算術の式に対しては考えていても、プログラム一般に敷衍されるものではないように思われる。プログラムは文の集合だ。文は意味を持つが値を持たない。それが、手続き的なプログラミングにおいて一般的な考え方だ。
一方、関数型プログラミングでは、プログラムは式だ。関数型プログラミング言語の式は部分式と関数適用から構成されていて、どの部分式も値を持つ。関数型プログラミングでは、プログラムの構造を内包した値を扱うことでプログラミングするようになる。直和型の値は分岐構造を内包しているし、リスト型の値は反復構造を内包している。モナドは、手続き型言語における各種副作用を持つ、逐次構造を内包した型の集まり（型クラス）ということになる。このように複雑な値を使うことで、関数型プログラミングではプログラムの意味と式の値を同一視できるようになる。
プログラムの意味と式の値を同一視できると何が嬉しいかというと、意味を持つプログラムの断片がすべて値を持つので、プログラムを処理するプログラムが書きやすくなる。プログラムのどの断片も、関数として抽象化することができる。他の関数に渡すことが出来る。変数にプログラムを代入できる。
話をアクションに戻す。Haskellにおいては、アクションが生成する値と、アクション自体は別だ。たとえば、getChar :: IO Charは標準入力から文字を1文字読み込み、その文字に対応するChar型の値を生成するアクションなのだけれども、Haskellでは、式getCharの値は「標準入力から文字を1文字読み込み、その文字に対応するChar型の値を生成するアクション」自体であり、生成されたChar型の値ではない。アクションgetCharの生成する値を取り出して言及するには、do {z <- getChar; k z}のz、getChar >>= \z -> k zのzとでも言うしかない。
色々書いたけど、結局、値とは何かという話に合意が得られていない状況ではどうにも話が通じないという点が問題で、以前からココらへんの考え方を整理して参照透過性についてなんとか説明しようと試みたりしているのだけれども、やっぱり難しいですね。
この記事では、ES6のジェネレータを使って、Haskellのdo記法を模倣したdoM関数を定義し、ジェネレータを使ってモナドを取り扱えることを示している。しかし “The same routine can be used with other monads like the Continuation monad” という記述に反し、実はdoMと一緒に使えるモナドと、使えないモナドがある。
話を簡単にするため、以下ではECMAScriptのプロトタイプチェーン機能を使わないでプログラムを書くことにし、doMには、モナドを表現するオブジェクトを、引数として別途渡すことにする。
function doM(m, gen) { function step(x) { var y = gen.next(x); if (y.done) { return y.value; } return m.bind(y.value, step); } return step(); }
具体的に、ふたつのモナドOMとGMを定義する。OMはOptionMonadの略で、GMはGeneratorMonadの略だ。
var OM = { unit: function(x) { return {tag: "Some", value: x}; }, bind: function(n, k) { if (n.tag === "None") { return {tag: "None"}; } return k(n.value); }, }; var GM = { unit: function*(x) { yield x; }, bind: function*(g, k) { for (var i of g) { yield* k(i); } }, };
このとき、OMに対してはdoMを適用できる。
var x = doM(OM, function*() { var a = yield OM.unit(2); var b = yield OM.unit(3); return OM.unit(a * b); }()); console.log(x); // ==> Object { tag: "Some", value: 6 } var y = doM(OM, function*() { var a = yield OM.unit(2); var b = yield {tag: "None"}; return OM.unit(a * b); }()); console.log(y); // ==> Object { tag: "None" }
一方で、GMに対してdoMを使うと、例外が出てしまう。
var z = doM(GM, function*() { var a = yield function*(){ yield 2; yield 3; yield 4; }(); var b = yield function*(){ yield 5; yield 6; }(); return GeneratorMonad.unit(a * b); }()); try { for(var i of z) { console.log(i); } } catch (e) { console.log(e); // ==> TypeError: k(...) is undefined }
なぜかといえば、GM.bindは第2引数kを複数回呼び出す可能性があるからで、一方、doM内で定義されている関数stepは、ジェネレータの呼出しに副作用を使うことを前提としていて、複数回呼び出されることを考慮しない作りになっているという点が問題となっている。この問題を修正するには、途中まで実行したジェネレータを複製することができる必要があるが、ES6のジェネレータにそのような機能はないようなので、結局ジェネレータを使ってどのようなモナドにも対応したdoMを実装することはできないということになる。
比較用に、doMを使わない場合のコードも載せておく。
var w = GM.bind(function*(){ yield 2; yield 3; yield 4; }(), a => GM.bind(function*(){ yield 5; yield 6; }(), b => GM.unit(a * b))); for(var i of w) { console.log(i); }
さて、以上の議論を踏まえた上で、「世界一抽象化されたコード」というのを今から書いてみましょう。一瞬でかけます。
# nop上にあげたものがそうです。つまり、「なにもしない」というコードこそが、世界一抽象化されたコードです。
http://nekogata.hatenablog.com/entry/2015/08/05/001742
これが本当に抽象なのか? と疑問に思う人がいるのだけれども、これは確かに一種の抽象化ではあるのだ。これが抽象化だと思えないのは、このnopの例自体が、具体的にどういう抽象化を前提としているかを明示していない、抽象的な例だからだ。「抽象化」という概念それ自体が抽象的だ。関数は、機械に扱える抽象化の機構のひとつなのだけれども、だからといって関数だけが抽象化ではない。
抽象化というのは、プログラムを書くのに使える概念であるという以前に、物の考え方としての概念だという側面がある。このnopの例は、少なくとも、もはやRubyが形式化しているレベルの抽象を越えてしまっていて、それは計算機にとっては意味を持たない（具体的に計算できない）抽象化だ。Ruby処理系に# nopというコード自体を渡しても、これはコメントを含む空のプログラムだと具体的に解釈されるだけであって、全く抽象性を持たない。だけど、そういう、機械にとって意味を持たない抽象化でも、人間にとっては意味のある何かを抽象している場合がある。コメント行自体もそうだし、アルゴリズムの本などが載せている擬似コードなどは、機械が読めずとも人間が読める、抽象的なコードだ。その抽象的なコードは、人間が適宜解釈し、具体的なプログラミング言語で実装することができる。
条件分岐if C then A else Bを抽象化して、非決定性の分岐A ⊕ Bとして考える、といった話と似ている。（抽象化というより、近似と言ったほうがいいのかもしれないけど。あるいは、抽象化というのは、別の視点を変えれば、近似と見ることができる。）
普通プログラマが抽象化と言ったら、機械が扱える範囲での抽象化だけ考えているんだ、と言うかもしれないけど、どういう種類の抽象化を機械が扱えるかというのは、曖昧だ。擬似コードだって、十分に形式化されていれば、処理系を実装して実行することができる。
まとまらないけど、メモ書きだからこれで終わり。
関数型言語ではポピュラーな機能である、代数的データ型を愛してやまない人は多いだろう。しかし悲しいことに、CoffeeScriptは、代数的データ型を持っていない。今回は、オブジェクトを使って代数的データの条件分岐を表現する方法について書こうと思う。
次のコードは、数式の文字列化や評価を行うプログラムだ。
# 分岐関数 match = (x, c) -> x.apply(c) # 構築子 num = (x) -> ->@num(x) add = (x, y) -> ->@add(x, y) mul = (x, y) -> ->@mul(x, y) # 数式 1 + 2 * 3 exp = add(num(1), mul(num(2), num(3))) # 文字列化 p = (exp) -> match exp, num: (x) -> String(x) add: (x, y) -> "(" + p(x) + ")+(" + p(y) + ")" mul: (x, y) -> "(" + p(x) + ")*(" + p(y) + ")" # 評価 ev = (exp) -> match exp, num: (x) -> x add: (x, y) -> ev(x) + ev(y) mul: (x, y) -> ev(x) * ev(y) console.log p(exp) + " = " + String(ev(exp))
実行すると、次のように表示される。
(1)+((2)*(3)) = 7
構築子は、次の形をしている。
c = (x...) -> ->@c(x...)
(仮引数列) -> 式は関数を作る構文、-> 式は引数のない関数をつくる構文で、@メソッド名(実引数列)はJavaScriptのthisのメソッドを呼び出す。つまり構築子cは、this.cをx...を引数として呼ぶクロージャーを返す関数だ。
条件分岐は関数matchに、代数的データと、分岐ごとの処理を表すオブジェクトを渡して行う。
分岐関数内では、渡された代数的データ（実体はクロージャー）をオブジェクトに適用している。
match = (x, c) -> x.apply(c)
別の方法として、次のような分岐関数と構築子を使う方法が考えられる。
# 分岐関数 match = (x, c) -> c[x[0]].apply(c, x[1..]) # 数式の構築子 num = (x) -> ["num", x] add = (x, y) -> ["add", x, y] mul = (x, y) -> ["mul", x, y]
1. Apply the following patch to the Makefile:
diff --git a/Makefile b/Makefile index e912e15..1f6c71f 100644 --- a/Makefile +++ b/Makefile @@ -80,7 +80,7 @@ libs: make -C libs/objsize OCAMLOPT=$(OCAMLOPT) OCAMLC=$(OCAMLC) $(TARGET_FLAG) haxe: $(MODULES:=.$(MODULE_EXT)) - $(COMPILER) -o $(OUTPUT) $(NATIVE_LIBS) $(NATIVE_LIB_FLAG) $(LFLAGS) $(LIBS:=.$(LIB_EXT)) $(MODULES:=.$(MODULE_EXT)) + $(COMPILER) -g -o $(OUTPUT) $(NATIVE_LIBS) $(NATIVE_LIB_FLAG) $(LFLAGS) $(LIBS:=.$(LIB_EXT)) $(MODULES:=.$(MODULE_EXT)) haxelib: (cd $(CURDIR)/extra/haxelib_src && $(CURDIR)/$(OUTPUT) haxelib.hxml && nekotools boot bin/haxelib.n)
2. Build the compiler with the following command:
make BYTECODE=1
3. Execute ocamldebug:
ocamldebug ./haxe [arguments]
% ocamldebug ./haxe OCaml Debugger version 4.02.1 (ocd) break @ Main 979 Loading program... done. Breakpoint 1 at 3223236: file main.ml, line 980, characters 2-29726 (ocd) run Time: 69442 - pc: 3223236 - module Main Breakpoint: 1 980 <|b|>let usage = Printf.sprintf (ocd) n 20 Time: 69757 - pc: 3223608 - module Main 1000 Common.define_value com Define.HaxeVer (float_repres (float_of_int version /. 1000.))<|a|>; (ocd) p version version: int = 3300 (ocd) rev Time: 69442 - pc: 3223236 - module Main Breakpoint: 1 980 <|b|>let usage = Printf.sprintf (ocd) prev Time: 69441 - pc: 3198700 - module Main 637 <|b|>init ctx; (ocd)
You can even trace back to the past!
Check the debugger commands at The debugger (ocamldebug).
哲学は役に立たないのではないか、という批判はソクラテスのむかしからあるようだ。（理想国のあり方と哲学の役割──『国家』第5-7巻）そういう哲学無用論に反論する方法のひとつに、哲学の有用性を具体的に説くというものがある。
でも、哲学が役に立った例を具体的にいくら挙げたところで、“本質的に”哲学の有用性が示されたことにはならない。どれも、特定の哲学の考えが有用であったというだけで、相変わらず、何の役に立つのか分からない哲学もある。すべての哲学に、その用途をあてがうのは不可能だろう。
有用な諸科学も、源流を辿れば哲学に由来しているのだから、今の哲学もいずれ有用となるはずだとも考えられる。ソクラテスの「星を見つめる男」の比喩にしたって、天文学という一見無用に見える学問が航海術に役立つということに喩えている。アインシュタインの一般相対性理論が全地球測位システム（GPS）の構築に不可欠なのだから、理論物理学は有用であるという話と変わらない。しかし、このような考え方は、楽観的だ。
哲学も役に立っているという論で救われるのは役に立つことが明らかになっている哲学だけだし、将来役に立つという説明では、悲観的なひとを納得させられないだろう。哲学を、有用性の観点から価値付けようとする試みは、そもそも無理があると思う。ある種の哲学は実際に無用で、その前提は覆らない。
それでも、哲学には価値がある。その価値とは、希哲学 philosophy という名が示している通りの価値だ。哲学に価値をもたらしているのは、知ることへの強烈な欲求だ。人間は、食欲や睡眠欲と並んで、知ることに対して抗いがたい欲求を持っている。食事は諸活動に必要だが、同時に食事自体が楽しみだ。食事に興味を持たず、完全に単なる手段とみなし、実用性・合理性を追求する人間は、極少数派だろう。（もしいるとしたら、そいつはたぶん哲学者だ。食事する哲学者の問題 - Wikipediaそれかサンドウィッチ伯爵か。結局、どの欲求が一番強いのか、という話だ。）
肉を食らうことも本を食らうことも等しく人間的で、健康に関係し、価値のあることだけれども、役にも立たない本を食らうことに何よりも強い満足感を感じる人間というのは、やはり少数派なのだろう。
「哲学は役に立つの？」「まあ、世の中には哲学を食らう人間もいるのだ。」
これから書くのは、言葉や論理と、その意味に関する話だ。フレーゲらによる、物事を厳密に考える言葉の探求は、現代論理学や分析哲学の出発点になった。まずは、その哲学を探りながら、関数プログラミングの話でよく耳にする「参照透過性」という概念を理解することを最初の目標にしたい。
Reference (Stanford Encyclopedia of Philosophy)
普通、記号には表す対象が存在している。記号と記号が表す対象との間にある関係を、言及（reference）という。*1たとえば、「東京タワー」や「港区にある電波塔」という言葉は建造物の《日本電波塔》への言及だし、「港区」や「東京タワーのある区」という言葉は場所の《東京都港区》への言及だ、などという。*2このような、記号の意味とは言及対象のことなのだという考えは、いろいろある意味の捉え方のうちのひとつだ。（直接言及論 Direct reference theory - Wikipedia, the free encyclopedia）
Compositionality (Stanford Encyclopedia of Philosophy)
複合表現の意味がその表現の構成要素の意味のみに依拠し決定されるという原理を、意味の合成性原理（compositionality）という。意味の合成性原理は、複合表現の一部分を、同じ意味を持つ別の表現に置き換えたときも、複合表現全体の意味も変わらないということを主張している。
たとえば、次の文を考える。
1. 東京タワーの高さは東京スカイツリーの高さよりも小さい。
文1の「東京タワー」という部分を、意味が同じ「港区にある電波塔」に置換すると、文2ができる。
2. 港区にある電波塔の高さは東京スカイツリーの高さよりも小さい。
意味の合成性原理から、文1と文2は同じ意味だと主張できる。意味の合成性原理は、代入の根拠となっている。
ゴットロープ・フレーゲは、「意義と意味について」（ドイツ語原題: Über Sinn und Bedeutung）において、文の意義（Sinn）と意味（Bedeutung）の区別を主張した。*3
http://www.amazon.co.jp/%E7%8F%BE%E4%BB%A3%E5%93%B2%E5%AD%A6%E5%9F%BA%E6%9C%AC%E8%AB%96%E6%96%87%E9%9B%86%E3%80%881%E3%80%89-%E5%8F%8C%E6%9B%B8%E3%83%97%E3%83%AD%E3%83%96%E3%83%AC%E3%83%BC%E3%83%9E%E3%82%BF-G-%E3%83%95%E3%83%AC%E3%83%BC%E3%82%B2/dp/4326198761www.amazon.co.jp
意味とは言及対象だと考えると、「明けの明星は宵の明星と同じものだ」という文の意味と、「明けの明星は明けの明星と同じものだ」という文の意味は、意味の合成性原理から、同じだということになる。しかし、このふたつは本当に同じ意味なのだろうか。前者は何か新しい知識を与えてくれるのに対して、後者は単なる同語反復にすぎない。フレーゲはそのことを、異なる認識価値（Erkenntniswert）を持っていると表現した。認識価値が異なる文が、同じ意味を持っているということになるが、これはどう考えればよいのだろうか。
フレーゲは、記号に結びつくものとして意味の他に意義があると考えた。「明けの明星」と「宵の明星」は、意義は異なるが、どちらも《金星》を意味している。フレーゲは、通常の命題文の意味は真理値だと考えた。*4「明けの明星は宵の明星と同じものだ」という文と「明けの明星は明けの明星と同じものだ」という文も、意義は異なるが、どちらも《真》という対象を意味している。
フレーゲは認識価値との結びつきである意義と、言及対象との結びつきである意味の区別を主張する中で、同じ表現であっても意味が異なる場合について考えを進めており、副文の意味は真理値ではない場合があると考えている。
「コペルニクスは、惑星の軌道は円であると信じた」という真の文について、「惑星の軌道は円である」が偽だからといって、「東京タワーは東京スカイツリーより高い」という別の偽の文を代入して「コペルニクスは、東京タワーは東京スカイツリーより高いと信じた」に変えては、文の真理値が変わってしまう。フレーゲの考え方に従えば、「コペルニクスは、東京タワーは東京スカイツリーより高いと信じた」という文中の「東京タワーは東京スカイツリーより高い」の意味は、真理値ではなく思想だということになる。
このような、同じ表現でも意味が異なる場合があるという考えは、今後referential transparencyの話につながってくる。
フレーゲは、名詞句を作る副文についても考えを進める。論理的な議論をする上で、表現の意味が一意に存在するということは重要だった。言語のすべての表現について、その意味が一意に定まる性質を、言語の完全性という。
たとえば、「0/0」や「4の平方根」という表現は意味を持たなかったり、複数持っていたりするので、解析学で使われている言語は不完全だ。フレーゲは、言語の不完全性を約定（Festsetzung）によって解決しようとした。フレーゲは「発散無限級数は数0を指示するという約定」を例に挙げている。要は、どのような表現も意味が一意に定まるように、言語を設計するということだ。
この考え方はプログラミング言語ではよく見られるもので、たとえばJavaScriptでは0/0の値はNaN、Math.sqrt(4)の値は2と決まっている。プログラミング言語の意味とは式の値だと定義すれば、どのプログラムも一意に値が定まるということがプログラミング言語の完全性ということになる。*5
言葉や記号や意味について議論するのに使えそうな言葉を挙げてみる。
sense, reference, referent, denotation, connotation, extension, intension, signifier, signified, expression, representation, token, idea, image, sign, interpretant, identifier, value, entity, object.
昔から、これらの言葉を使った様々な論が出されているが、その考え方すべてを簡単にまとめることはできそうもない。似た意味で異なる言葉を使っていたり、同じ言葉が少し異なる意味で使われていたりする。おいおいこれらの言葉の関係について考察をしようと思うが、とりあえずは必要な言葉を定義することにする。
*1:referenceの訳語は悩んだ。指示、参照、言及などが候補に挙がった。どの言葉にしても日常の用語と違った意味に聞こえてしまうが、命令を印象させる指示や、物事を参考にすることを印象させる参照などよりは、より自然な表現に聞こえるだろうということで、言及を選んだ。情報科学では、referenceの訳語に参照を使う。訳語に言及を使うことは他ではあまりないが、self-referenceという用語は自己言及と訳されることが多いので、突飛な訳語というわけでもないと思う。
*2:2016年9月3日追記: 英語のreferenceはreferentの意味で使われることがある点で、日本語の「言及」と意味合いがずれているので注意がいる。「表示」と訳されるdenotationも、意味するところは「表示されるもの」なので難しいところだ。
*3:SinnもBedeutungも類義語だが、日本語ではSinnを意義、Bedeutungを意味と訳し分ける場合がある。英語ではSinnをsense、Bedeutungをreferenceと訳すことがある。
*4:命題の真理値は人間の信念に関係なく客観的に決まっているという考えが根底にある。
*5:この定義の上では、JavaScriptは完全でない。たとえば、例外を投げる場合や、無限ループが発生する場合に、式は値を持たない。完全・不完全を議論する上では、何を意味だと考えているかに注意する必要がある。
僕は、プログラムを哲学したい。その動機のひとつに、用語の統一がある。現状、プログラムにおいて使われる用語は、対象言語によって色々と異なってしまっている。たとえば、似たような概念に、あるプログラム言語ではポインターという用語を使い、別の言語ではリファレンスという用語を使うといった場合がある。インターフェースとトレイトは同じなのかどうか。クラスと型クラスはどうか。同じ概念に違う名前を付けていたり、違う概念に同じ名前を付けていたりするので、混乱が甚だしい。
このような用語の混乱の下では、その場その場でアドホックに用語を定義し直すしかないが、そうすると他の場面で使われた用語との関係性がよく分からなくなってしまう。プログラムを哲学することで、このようなバベル的混乱の状況を変えられるのではないかと思っている。
動機のもうひとつは、プログラムするという行為の実態をより明確に捉えたいということだ。今日プログラミング教育の必要性が主張されているが、プログラムを教えるとはその実何を教えることになるのかについて、意識を深めたい。「プログラムする」というのは、単に機械に指令を与えるということなのだろうか? プログラミング教育は、単に技術者不足を解消するために行うものであるべきなのだろうか? そのようなことを考えたいのだ。
歴史を辿れば、計算機科学、数学、論理学、分析哲学、言語学という諸分野は、19世紀末における現代論理学の創始というイベントで交叉する。各分野にまたがって、フレーゲ、ラッセル、クワインといった名前や、各種共通する用語を目にすることができる。
しかし、今日では各分野に分化してしまった。ちゃんと情報だとか計算機に関する哲学をやっている人間も存在しているのだろうけれども、そういう分野をフォローしている人間は、計算機を単に工学の対象として解説する読み物に比べると、哲学的観点も絡めて語っているものは少ないように思う。
この連載（になる予定）では、まず分析哲学の黎明期における関係性を探ってみたいと思う。
寿司の絵文字を比較して心を落ち着かせる | プログラミング生放送
Pile Of Poo! ウンコーな絵文字を比較してみた！ - SHII.NET(しぃねっと)
絵文字比較がブームなので、ここでは U+1F4AE WHITE FLOWER 💮 を比較してみようと思います。
Unicodeのチャートでは次のような形で載りました。Googleらの提案段階 (emoji4unicode - Emoji for Unicode: Google Emoji private use mapping data and tools - Google Project Hosting) からこのグリフのようです。
U+1F4AE には brilliant homework というコメントが付いています。
桜花のスタンプ、文字抜き。
Mozillaも絵文字を作っています。
Emoticons (Emojis) for Mozilla Firefox - Sabrina Smelko
pivanov/FirefoxOS-Colored-Emoji-Font-Tool · GitHub
Androidの絵文字も花丸です。Google日本語入力でも「はなまる」で💮が出ます。
これはなんなんですかね。
よく分かりません。
分からなすぎるのでissue投げました。U+1F4AE WHITE FLOWER fails to catch its original sense · Issue #33 · Ranks/emojione · GitHub
WHITE FLOWERをスタンプで実装しているところと花丸で実装しているところとよく分からないところがある。
絵文字は闇。
Source Han Sans （源ノ角ゴシック）バージョン1.002がリリースされました。次のページからダウンロードできます。
adobe-fonts/source-han-sans at release · GitHub
基本的にはSubsetOTFディレクトリの中のSourceHanSansJP.zipをダウンロードして使えばOKです。
SourceHanSansReadMe.pdfの中には、どれを使えばいいのか迷った人のためのフローチャートがあります。下の図は日本語訳です。
どの環境でもOKなのはSubsetOTFだけなので、DTPで使うなど、他人とデータをやりとりする必要があるならSubsetOTFを使ったほうが無難です。
以下、各コンフィギュレーションの簡単な説明です。
Appleが、ドラフト段階の絵文字修飾子を実装したiOS 8.3をリリースした。パブリック・ベータ版とは、Genericな肌色の絵文字の髪の色が、黄色に変更されている点が違う。これは、黄色がアジア人をイメージしたものだというクレームがあったので、Yellow is ethnic-neutral colorを、髪の色にも敷衍させた解決策だろう。金髪に見えなくもないが、悪くはない。少なくとも、アジア人に見えるというクレームは躱せるし、UTR #51のドラフトで推奨されている「暗い髪色」にするよりも、非現実的な髪の色にする方が、中立的に見える*1。
もうひとつ、気になっていた家族絵文字の実装の詳細が判明した*2。
The new family emojis are made from 4 emojis joined by U+200D character in #iOS and #Yosemite pic.twitter.com/o8GamFNGqQ
— Zhusee (@zhusee2) 2015, 4月 8要は、既存の絵文字をzero width joiner (U+200D)で繋げたものを、新しい絵文字と解釈して表示している。この方法ならUnicodeに新しい絵文字を追加することなく、多様な家族構成の絵文字を実装できる*3。このやり方が、Unicode標準に取り入れられるかどうかは不明だ。
あと、新しい国旗絵文字も追加されたのだが、そのためにUnicodeのRegional Indicator Symbolsの仕様の欠陥がより明らかになった。
Way too pumped about the new Swedish flag emoji 🇸🇪🇸🇪
— Danny Donahue (@danny_donahue) 2015, 4月 8スウェーデンとスペインの国名コードはそれぞれSE、ESだ。ということで、スウェーデンの国旗をふたつ並べると、SESE という文字の並びになって、スウェーデンの国旗なのか、スペインの国旗なのかが曖昧だ。Twitterは、現状スペインの国旗だけに対応するので、「S[スペインの国旗]E」というように表示してしまう。
これは酷い。どうしてこうなった。UTF-16のサロゲートペアを入れた時には、こういう曖昧なパターンが現れないように考慮していたじゃないか。なんでそれが絵文字で出来なかったんだ? まあ、今更愚痴を言ってもしょうがないのだが、このようなパターンに対処するための仕様を、Unicodeに入れる必要がある*4。
This article considers what makes Apple’s implementation of Fitzpatrick Scale Modifier problematic so that Chinese people criticize it.
(It is the abridged translation of 絵文字肌色問題 - M59のブログ.)
SankeiBiz published an article to report that Chinese people criticize Apple’s implementation of the diversified skin tone emoji. The article contains a strange sentence:
公開された6種類の肌の色が並んだ写真を見ると、黄色がアジア系人種をイメージしているのは明らかで、アップルの説明はいかにも苦しい。
アップル「黄色い顔文字」に中国で批判噴出 「あんな黄色い奴みたことない」「アジア人への偏見だ！」（1/3ページ） - 産経ニュース
Judging from the published screenshot showing six skin tones, they obviously intend to describe Asian race by yellow. The excuse by Apple is farfetched.
Here, “the excuse by Apple” refers that “the yellow shade is intended to be ethnically neutral.” (Asians angered by Apple's 'racist' yellow emoji | Daily Mail Online)
Whether you agree to the excuse or not, it lacks of reasoning. Where does the concept “yellow is ethnically neutral” come from? Is it really valid?
The concept “yellow is ethnically neutral” comes from the draft of UTR #51. It writes:
People all over the world want to have emoji that reflect more human diversity, especially for skin tone. The Unicode emoji characters for people and body parts are meant to be generic, yet following the precedents set by the original Japanese carrier images, they are often shown with a light skin tone instead of a more generic (nonhuman) appearance, such as a yellow/orange color or a silhouette.
http://www.unicode.org/draft/reports/tr51/tr51.html#Diversity
When a human emoji is not immediately followed by a emoji modifier character, it should use a generic non-realistic skin tone—such as that typically used for the smiley faces—or a silhouette. Dark hair is recommended for generic images that include hair. People of every skin tone can have black (or very dark brown) hair, so it is more neutral. One exception is PERSON WITH BLOND HAIR, which needs to have blond hair regardless of skin tone.
http://www.unicode.org/draft/reports/tr51/tr51.html#Diversity
This take up the problem that some of the current emoji have too specific appearance. Unicode just specifies to be general such as happy person raising one hand or boy emoji, but they implement happy WOMAN raising one hand or WHITE boy emoji. It is too specific.
So, Design Guidelines recommends to adopt neutral appearance regarding race, ethnicity, and gender.
Emoji of Android already switched to generic one that is cartoonish or shows the contour. For example, the old boy emoji (👦 Boy Emoji) has light skin tone, while the new one shows the yellow mascot.
The old one is specific.
The new one is generic.
In short, yellow is suitable for emoji as long as it makes the emoji generic.
The Fitzpatrick Scale Modifier in draft introduces specific emoji regarding skin tones. It is, however, hard for users to recognize that there is the distinction of generic and specific, because they are evenly presented in emoji palette or in sentences. People may receive that Apple have just added new emojis for some emojis for skin tones.
Again, let’s see Apple’s implementation.
Unlike Android, they are still human and just differ on skin tone. The leftmost one should seem to be generic, but it is just yellow.
Certainly, the figures in the draft show emoji same way:
A figure in 2.2 Diversity
It could be taken that “Ah, just turn the skin tone yellow, and it would be ok,” but this causes the mistake that yellow means Asians.
Besides it, Apple emoji has another problem. The emojis applied Fitzpatrick Type-3 modifier have blond hair against the draft’s recommendation. The draft recommends dark hair that people of every skin tone can be have. Blond is associated with Caucasoid, so Japanese and Chinese take Type-3 emoji as white people. Most of Japanese have Type-3 or Type-4 skin tone*1, but Type-3 emoji is not “Asian.” It is natural that they concludes the yellow one is for Asian.
Although there is a reason that yellow is ethnically neutral, Apple mistake the intension of yellow. Yellow does not always make emoji generic. The draft would be better to write clearly the knowledge.
Appleが、Unicode 8.0で入る見込みのFitzpatrickスケールを実装したら、デフォルトを意図していた黄色い肌色の絵文字が黄色人種だと解釈されたり、赤毛の絵文字も入れて欲しいと要望が出たりと、まあ絵文字をめぐる事態は明らかにヤバイ方向に転がりだしている。
絵文字の「肌の色」を5色から選べるようにしたアップル « WIRED.jp
黄色い肌色の絵文字の件は、SankeiBizでも記事になっている。その中に、“奇妙な”記述がある。
公開された6種類の肌の色が並んだ写真を見ると、黄色がアジア系人種をイメージしているのは明らかで、アップルの説明はいかにも苦しい。
アップル「黄色い顔文字」に中国で批判噴出 「あんな黄色い奴みたことない」「アジア人への偏見だ！」（1/3ページ） - 産経ニュース
「アップルの説明」というのは、「黄色は民族的中立(ethincally neutral)を意図したもの」というものだ。(Asians angered by Apple's 'racist' yellow emoji | Daily Mail Online) この説明で納得した人もいるだろうし、納得できないという人もいるだろう。どちらにしても、これらの記事は重要な点については伝え損ねている。それは、「黄色は民族的中立」という論がどこから出てきたのかと、その妥当性である。
Appleが「黄色は民族的中立」という説明をした根拠は、現時点でドラフトが公開されている文書、UTR #51: Unicode Emojiの、次の記述だ。
People all over the world want to have emoji that reflect more human diversity, especially for skin tone. The Unicode emoji characters for people and body parts are meant to be generic, yet following the precedents set by the original Japanese carrier images, they are often shown with a light skin tone instead of a more generic (nonhuman) appearance, such as a yellow/orange color or a silhouette.
全世界の人々が人類の多様性、特に肌の色あいについての多様性を反映した絵文字を望んでいる。Unicodeにある人々と体のパーツの絵文字は不特定的な表現であることを意図しているが、それでもオリジナルの日本のキャリアーの画像による先例の絵文字セットに従い、絵文字の肌は黄色や橙色あるいはシルエットのような、より不特定的な（人類でない）見た目ではなく、明るい色あいで表示されることがよくある。
http://www.unicode.org/draft/reports/tr51/tr51.html#Diversity
When a human emoji is not immediately followed by a emoji modifier character, it should use a generic non-realistic skin tone—such as that typically used for the smiley faces—or a silhouette. Dark hair is recommended for generic images that include hair. People of every skin tone can have black (or very dark brown) hair, so it is more neutral. One exception is PERSON WITH BLOND HAIR, which needs to have blond hair regardless of skin tone.
人間の絵文字の直後に絵文字修飾文字が続かないときは、スマイリーフェイスなどに典型的に使われているような、不特定的、非現実的な肌の色あいを使うか、シルエットを使うべきである。髪の毛を含む画像では、不特定的な画像として暗い髪色を推奨する。すべての肌の色あいの人間が黒い（あるいは濃い茶の）髪色でありうるため、それがより中立的である。例外はPERSON WITH BLOND HAIRで、この絵文字は肌の色あいに関係なくブロンドの髪であることが必要である。
http://www.unicode.org/draft/reports/tr51/tr51.html#Diversity
問題となっているのは、現行の絵文字の表現が特定的(specific)であるということだ。Unicodeの仕様では、絵文字の意味について「挙手」や「男の子」といったことしか定めていないのに、実装では「女の人の挙手」や「白人の男の子」のように、過剰に特定的な表現になっている。そこで、ドラフトの絵文字デザインガイドラインでは、用途不特定の絵文字に、人種・民族・ジェンダーに対して中立的な表現を使うよう求めている。
Androidの絵文字は、このドラフトの記述の通り、既に漫画的なキャラクターやシルエットによる不特定的な表現に移行している。例えば、男の子の絵文字(👦 Boy Emoji)は、古い絵文字では肌の色あいの薄い絵文字だったのが、新しい絵文字では人間のようではない、黄色いキャラクターによる表現になっている。不特定的な(generic)表現というのは、民族や性別を特定しないこのような表現を意味している。
Androidの古い絵文字、特定的(specific)表現
Androidの新しい絵文字、不特定的(generic)表現
（不特定的な表現の）絵文字の直後に、絵文字修飾文字を続けることで、その絵文字が特定の肌の色を持つことを指定できる。今回Appleが実装したのは、この仕様だ。このあたりは、文字コードについての技術的知識がないと理解が難しい。技術的には不特定的表現の絵文字と特定的表現の絵文字に差があっても、技術的知識のない利用者にとっては単にAppleが新しい絵文字を追加したようにしか見えないし、絵文字に不特定的な表現の絵文字と特定的な表現の絵文字があるということは意識しないだろう。このことも、問題の一因となっている。
改めて、Appleの実装を見てみよう。
Androidの実装とは違い、Appleの絵文字では、不特定的な表現であるべき一番左の絵文字は、単に肌の色を黄色に変更しただけだ。
確かにドラフトに出てくる図も、単に肌の色を黄色に変更しただけの図だ。
2.2 Diversityに出てくる図。
だからドラフト自体も色を黄色に変えればokであると言っているかのように読めるのだけれども、やはりただ色を変えるだけでは、事情を知らない人が不特定的な表現と特定的な表現の違いに気づくことを期待するのは難しく、黄色は黄色人種を特定的に表した絵文字だと解釈する人が出てきてもおかしくない。
また、左から3番目の、 FITZPATRICK TYPE-3 絵文字修飾文字を適用した絵文字は、ドラフトの「暗い髪色を推奨する」という記述に反し、ブロンドである。日本人はIIIとIVが多い(院長が語る｢皮膚｣とは ～皮膚の解剖と生理～：皮膚の色｜東京 明治通りクリニック)そうだが、日本人や中国人は、まさかこのTYPE-3が自分の民族を表す絵文字だとは考えないだろう。当然、“白人”を表す絵文字だと捉えるはず*1で、そうすると（肌の色あいの薄い）日本人や中国人を表せる絵文字はないことになってしまう。だから余計に「黄色は黄色人種」という印象を強めてしまうのである。
もうひとつ出てきた、絵文字の髪色の問題について、現行のドラフトでは「暗い髪色がより中立的である」という記述がある。この記述は妥当だろうか。
また、すべての絵文字の髪色を変更できるようにするべきだろうか。ドラフトには、髪色や目の色、体型などといった、肌の色あい以外の多様性を表す絵文字修飾文字については、Unicodeの対処する範囲外であるとし、絵文字でなく埋め込み画像を使うなどといった、長期的な解決を望んでいる。それならば、なぜ肌の色あいだけ特別扱いするのか、という点については、はっきりしない。
また、すでにブロンドを表す絵文字があるから、赤毛の絵文字も増やすべきだという議論もできる。
これらの点について、さらに議論される必要があるだろう。
Appleの説明する「黄色は民族的中立」というのは、無根拠な言い訳ではないのだけれども、その理屈をちゃんと理解すると、Appleの実装がドラフト仕様の意味を汲み取れておらず、実際酷い実装であることが分かる。また現行のドラフトも問題の解決に十分ではなく、さらなる改善が必要である。
Appleが出してきた実装にただ漠然とした不満をぶつけ、声の大きさで物事を変えようとするのでは、問題は解決しないだろう。そうではなく、本当の問題点を皆が適切に認識し、議論することができれば、問題を解決に向かわせることができるはずである。
今日は雛祭りなので、ついでに、雛人形の絵文字の話を書こう。
これは Apple Color Emoji の雛人形だ。拡大してみると、コレジャナイ感が漂う。EmojipediaやiEmojiで、他のフォントでの雛人形を確認して欲しい。
🎎 Japanese Dolls Emoji
🎎 Japanese Dolls Emoji (U+1F38E/U+E438)
Android/Hangouts, LG Emoji, Samsung Emojiは雛人形っぽい。Twitter絵文字、これは雛人形じゃないだろと感じる。
Draft Unicode Technical Report #51 Unicode Emoji のドラフトのリスト: Draft Emoji Data (Full)にも絵文字の画像が載っている。
雛人形は人間でないが、人間を象ったものだ。肌の色はどうするべきだろうか? ちなみに、ほとんどの雛人形の肌は白い。雛人形の肌は白であるべきだと、絵文字デザイナーはどのように知ればいいのだろうか? 雛人形 - Google 検索
