ひとが一人いなくなるということ

昨年（2017年）秋から親が入院してドタバタしていました。その後年初（思えばちょうど5ヶ月前のこと）には当人が永眠してさらにドタバタ。遺産をめぐりシングル世帯同士の間で合意の上の限嗣相続みたいな手続きを行うためにまたドタバタ。ひとが一人日常生活を離脱していき、さらには特殊な状態の生活をすら終えてしまうということは、物理的にも精神的にもたいへんなイベントなのだということを痛感しました。

物理的というのはもちろん世帯のメンバーの欠員によりいろいろな作業が残されたメンバーに降り掛かってきたり、葬祭に関わるあれやこれや、国や自治体への届け出、金融機関とのやり取りが必要になったりということです。精神的というのはこれはひとによって感じ方はちがうのでしょうけれど・・・こころのなかにぽっかり穴が開くというのはなるほどこういうことかという状態のことです。

彼の亡くなる以前のことも以後のことも、ああすればよかったこうすればよかったが尽きません。ひとがその生を終えようとしつつあるときにどのようにして彼・彼女を送るべきか。今回のことと前後して読んでいた社会学的論考のなかで、その著者はいわば「死別の作法」というべきことごと（看病の仕方、告知の仕方、臨終のまさにそのときの迎え方、葬送の仕方など）が宗教的なものにせよ非宗教的なものにせよ常に型にはめられたものへと回帰していってしまうことを執拗に指摘しています。これは「自由」に関するナイーブな態度と言えるでしょう。

死別に関することに限らず、ひとの行う差異化とは完全新規で独特のやり方を発明することではなく、所与のあるカテゴリと別のあるカテゴリとを対照させることで行われるものではないでしょうか。その差異化の過程で所与のカテゴリが解体されて複数に分けられたり、統合されたり、忘れ去られたりする。あるいは誤差が生じてふいに新たなカテゴリが創始される──話はそれますが、統廃合と誤差、その結果生まれるものを独自性・創造性の発露として評価するよう要求して、個人や個人の制作物に至上の価値を与えようとする運動が芸術ということになるのではないでしょうか──したがって真の問題というのはある選択が「自由」か否かということではなく、その選択がどのような条件のもとで行われるかということでしょう。あるひとがある作法を選ぶ。別のあるひとは別のある作法を選ぶ。その選択のちがいや、選択の機会のちがいが何に由来するかを論じることでしょう。「自由」そのものをうんぬんするのは政治的ないし法律的な議論です。「ひとが何を以て自由とするか」ということこそ社会学的な議論でしょう。

自分自身の体験として親との死別の経過を思い起こすときその選択肢の問題はまだ十分に客観化されていないようです。もしもあのときああしていたら・・・しかしああする以外にどうしたらよかったろうか・・・という思考はまだその選択の由来を云々するステップには進んでいません。

死と死別の社会学―社会理論からの接近 (青弓社ライブラリー)

Java言語ではFunc<T>とFunc<T,U>は区別できない

この1年くらいの間Javaを離れてC#ばかりをコーディングしていました。戻ってきて愕然としたのは例えばFunc<T>とFunc<T,U>という型を仮定した時、Java言語においてはそれらが区別のつかない型、型名の競合を引き起こす型として捉えられてしまうということです。

これは、次の2点を考えればなんのことはない、当然の事態ではあります：

• Java言語のジェネリクスのベースにイレージャのメカニズムが存在すること、つまりコンパイル過程でリフレクションのための型のメタ情報はともかくとして型そのものからは型パラメータが消去されてしまうこと。
• C#言語におけるような型パラメータに即した型名の自動修飾──Func<T>はFunc`1となり、Func<T,U>はFunc`2となる──の仕組みはJava言語には存在しないこと。

1点目のイレージャ型のジェネリクスを採用したことの背景にある事情を考えれば、2点目もこのようにならざるをえないわけです。既存APIを維持しつつ拡張しようとすると、イレージャを採用する一方で型名の自動修飾のメカニズム（もしくはルール）は不採用とする必要があるのです。

Java SE 8の関数型インターフェースについて勉強する人はFunctionやBiFunctionやSupplierなどなどのいくつものインターフェース名を記憶させられることになります。種々の型名で区別されるインターフェースが存在することは、それらのインターフェースの目的・役割を示す点でも有意義なものではありますが、実情としては型名の競合を防ぐためにはこうするしかなかったということです。
言い方を変えると「ソースコード上、型パラメータで示される情報は同時に型名でも示さないといけない」という二重修飾の拘束がはたらいているのです。

「だからなんだ、C#だって裏側では型名の自動修飾で競合を回避したりしているではないか」と意見もありそうですが、それにしてもそうした内情をソースコードのレベルで露わにしてしまい、標準APIの「概念的重み」（≒学習コスト）も増大させてしまうのはやはり望ましいことではないでしょう。イレージャ型ジェネリクスには、型パラメータの実パラメータが異なる型を引数とするオーバーロード・メソッドが定義できないという、これも地味ですが何かしらのAPI設計をしていると結構痛い（結果として引数の型名やメソッド名にバリエーションをつくる必要が生じる）問題もあります。

いずれも「言っても仕方のないこと」ではあるのですが、C#からの帰還後にはどうにも気になってしょうがないことでもあるのです。。

Unclazz.Commons.Jsonライブラリv1.2.1リリース

昨年11月に公開したJSONパーサー（かつシリアライザ） Unclazz.Commons.Jsonライブラリ のバージョン1.2.1をリリースしました。
このリリースでは以下の2つのバグフィックスを行っています：

• Stringリテラルに含まれるCRLFなどのエスケープシーケンスを正しく処理できない問題の解消
• Stringリテラルに含まれるUnicodeエスケープシーケンス（サロゲートペア含む）をサポートできていない問題の解消

余談 - サロゲートペア問題

ところで、目的はあくまでバグフィックスだったのですが、とくに2点目のUnicodeエスケープシーケンスのサポート追加はいくつかの点で勉強になりました：

• UTF-16ではUnicodeの拡張領域に含まれる文字を表現するためサロゲートペアという4バイトを使用する（それ以外は2バイト）
• JavaやC#のようなやや旧世代の言語では文字列はUTF-16で表現されている
• これらの言語における文字型（char）はその定義からしてサロゲートペアを扱うにはキャパシティが足りない（Javaでは概念として「文字」と「コードポイント」を分けており後者はサロゲートペアを含む）
• これらの言語における文字列型（String）リテラルで拡張領域に含まれる文字をUnicodeエスケープシーケンスで表現する場合\uXXXX\uXXXX（XXXXは左ゼロ詰め4桁固定16進数値）という記法をとる
• これは「あたかも2文字であるように記述する」とも読めるが実際上その長さ（JavaではString#length、C#ではString#Length）をとると2文字分に該当する
• 「（Python3の）文字列はUnicode文字のシーケンスだ」というとき含意されているのはこうしたUTF-16に依拠する実装をとる前世代に対する優位性である

参考にした記事：

• Unicode メモ - C#練習日記 … サロゲートペアの整数値から文字（というか文字列）に変換する方法を学びました。
• CodeZine - サロゲートペア入門…サロゲートペアの概念について学びました。加えて上記記事とあわせてサロゲートペアの整数値を文字に変換する方法を学びました。
• Dive Into Python 3 日本語版 - 第2章 ネイティブデータ型…上述のPython3に関する記述から今回の問題の示唆を受けました。
• hydroculのメモ > プログラミング言語の比較 > 文字列 > Unicode拡張領域の取り扱い…Java、Python、JavaScriptなどの比較がなされていてわかりやすいです。

2016年11月の記事：

m12i.hatenablog.com