Ermitejo - エスペラント語日本語翻訳

先日リリースした文章内辞書引き機能について、訳語は単語辞書引き結果をそのまま結合しただけであるということを文章内単語訳機能の新設で既に述べました。

ここで、そのイカサマ訳語の文字列を得るサブルーチン（いわゆる関数）を、"fantaziu_sencon"と命名しています。意味をでっち上げよ、という、サブルーチン名を見たら怒り出す向きがいてもおかしくない命名です。文章内単語訳のバージョンアップは乞うご期待としておいて、今回ここで取り上げたいのは、関数名や変数名のエスペラントによる命名規則についてです。

Perlに於ける命名規則の流儀

エスペラント語日本語翻訳システムErmitejoでは、さしあたってPerlで実装しています。機能要件を満たし次第、非機能要件として性能面（レスポンスタイム）の向上を行うべくCあたりに一部移植しようと思っていますが、現在のところ全てPerlで書いています。

さて、識別子は自己説明的なものを用いることがベストプラクティスとされており、ダミアン先生も『Perlベストプラクティス』（参考文献一覧）で1章分を丸ごと投じつつ、さらに事あるごとに述べておられます。

エスペラントで識別子を命名する挑戦

さてここで、「エスペラント語を扱うシステムなんだからエスペラント語で識別子を書いては如何な物か」と、やせ我慢的にプログラムコード上のデファクトスタンダード言語の英語に喧嘩を売ってみました。例えば、以下の通りです。

• 語彙辞書の保守を行うモジュールは、package Ermitejo::Leksikono::Tenado;と宣言しています。
• 発音を得るサブルーチン（関数）は、sub akiru_prononcon () { ... }と記述しています。
• laboradoという単語の辞書引き結果で、接尾辞のadの意味はデータ構造上で$vorto->{morfemo}[0]{sufiksoj}[0]{senco}[0]に格納されています。
• 文字が母音かどうかによる分岐は、if (estas_vokalo($litero)) { ... }と記述しています。

Perl自体の予約語はソースフィルタでも使わなければ置換出来ませんのでこれは素直に諦めていますが、上記のように徹底的というか偏執的に命名規則を押し通しています。

識別子を新たに設けようとする度に、「これってエスペラントでは何て言うんだっけ」と辞書を調べるなど、自縄自縛の気があります。

エスペラントで命名する上での留意点

基本的には英語に準じる 

仮にエスペラントで命名しても、命名規則の思想は万国共通であるわけで、基本的には英語で変数名やら関数名やらを記述する際と同様、こうしたベストプラクティスに従うことが良いでしょう。

ここでは、エスペラント書きする上での私の実例をご紹介しつつ、個人的な留意点をご紹介します。

字上符付き文字は代用表記で

字上符付き文字は禁じ手ですので、おとなしく代用表記しましょう。このシステムではx後置式としています。$antaŭa_vortoではなく、$antauxa_vortoなどという書き方です。

サブルーチンは意志法（命令法）で

冒頭の例のように、サブルーチンは意志法（命令法）とします。訳語（意味）のでっち上げを行う場合、英語でinvent_senseと書くならばfantaziu_senconと書きます。

ここで、動詞不定法によって動名詞的にfantazii_senconと書くことはしません。当該サブルーチンの呼び元は「～すること」という曖昧な書き方よりも、「～せよ」という明示的な書き方を好むためです。

また、当たり前ですが他動詞の目的語は対格とする必要があります。

変数は単に形容詞と名詞で

変数は単に形容詞と名詞で書きます。$litero, $fonemo, $afiko等です。

形容詞で分別する変数は、少々考え物です。英語と違って、$next_wordを$sekva_vortoとしても$vorto_sekvaとしても意味は通りますが、$prev_wordである$antauxa_vortoと比べた場合、文頭ですぐに比較出来るので、基本的には形容詞＋名詞の語順とすべきです。

ところが、逆にnext, prev（次・前）やleft, right（左辺・右辺）が山ほど出るようなサブルーチンの場合や、文頭がかえってsekvaだのdekstraだのと統一されてしまってかえって見難くなるので、必要に応じて名詞＋形容詞の語順も選択しています。

私も上記判断はあまり自信がありません。人によっては、甘んじて形容詞＋名詞の語順を貫くべきであると考えるかも知れません。

ブール変数・ブールサブルーチンはコピュラ等で 

ブール（真偽）を意図した変数やサブルーチンはコピュラ（estiの文）や、その他の動詞としています。

• my $estas_vokalo; # 母音か否か（真なら母音）
• sub estas_vokalo ();
• my $havas_afikson; # 接辞があるか（真ならあり）
• # sub havas_afikson ();

英語ではブール変数を$is_vowelや$has_affixと書きますので、これも同様の置換です。

英語は疑問文の一部を切り出したものであるという理解も可能ですが、単にvariable(letter) is vowel, variable(word) has affixの一部であるという理解の方が通りが良いので、エスペラント式の識別子も$cxu_estas_volaroや$cxu_havas_afiksonなどと疑問文とはしていません。

まして仮定法で$estus_vokaro, $havus_afiksonともしていません。if letter was vowelやif word had had affixに相当するエスペラント節はse litero estus vokaloやse vorto havus afiksonですので、コーディングするとif ($estus_vokalo) { ... }やif ($havus_afikson) { ... }となってしまい、「もしこいつが母音だったら困っちゃうんだが、そしたら母音用の処理をしてやるかぁ」という投げ槍な意図のコードになってしまいます。 

サブルーチンでも同様で、これはエスペラント文の語順を倒置しただけでコーディング出来て嬉しいです。すなわち、英語のif letter is vowelやif word has affixはエスペラントではse litero estas vokaroやse vorto havas afiksonとなり、素直にif (estas_vokaro($litero)) { ... }やらif (havas_afikson($vorto)) { ... }と通り良く書けます。

まとめ ～ お勧めは出来ません

読める人がいるのか 

エスペラントでどう書くかという点はこれまで述べたとおりですが、言明しておきますが、あまりお勧め出来ません。エスペラント話者と英語話者（なんちゃって英語話者を含む）の比から考えても、可読性にかなりの難が出て来てしまいます。

下手をしたら（話者の数としては）$mozi, $onnin, $setuziなどと日本語ローマ字表記をした恐ろしいコードよりも問題かも知れません。流石に、プログラムIDでコールするような旧態依然としたコードよりはましかなとは思っていますが。いやはや、友人に聞いても昔ながらの金融系システムではどの会社でも概ねそのようですので、これもまた恐ろしい限りです。COBOLというよりは命名規則がいただけず、取っ付きにくかったのを今でも苦々しく思っています。あまり深くは書けないのですが、流石にJavaでは旧弊が改められる傾向にあるようです。

千のコメントになって

私は定期健康診断のザル診察でも心臓の爆弾が引っ掛かった所為で、日常生活には問題ないけれども急性心不全が起こらないとも限らないと、医者に生殺し的に脅されている都合上、エスペラント語日本語翻訳システムErmitejoの開発の夢半ばで斃れた場合でも、死後にソースを一切合切公開し、開発の引き継ぎ者を募られたい旨を遺書に書いています。しかしながら公開したとしてもエスペランティスト以外だとまず辞書が必要なコードであるため、引き継いでいただける方がいらっしゃるかどうかは甚だ不安に思っています。

このため、勢い勇んでエスペラント化したコードではありますが、最近は「やっぱり素直に長い物に巻かれて英語で書いた方が良かったかも……」と、英語の専横に憤慨しつつエスペラントの地位向上に血気盛んな方からは殴られそうな弱気を吐いていたりします。

せめてもの罪滅ぼしというより、そもそも私もエスペラント上級者ではないので、自分のためにもコメントを書いています。『Perlベストプラクティス』と同等、ないし専門的なエスペラント単語の場合にはもう少し手厚く書いていますので、いざとなればコメントから変数を類推することは可能です。流石にサブルーチンやチャンクについては（英語だろうとエスペラントだろうと）しっかりと書くべきなので、これは王道通り類推可能なように書いていますので、心配はしていません。

上記を踏まえ、取り敢えずlegumin.txtには以下のように書いています。

私の遺品の前で　泣かないでください
そこにドキュメントはありません　ブログにも書いていません
千のコメントに
千のコメントになって
この膨大なソースへ
ぶちまけています