概要

基本的には、CSELにある通り。
仕様を書くのに飽きてきたので、実装を先にするかも。
どのような仕様が良いのか、まだ皆目見えてこないので、0.0は叩き台という事で、とにかく動く状態のものを書いてみる。

仕様

utf-8の文字列とする。
基本的にはLISPのS式と同じ構造を構成する為の書式となる。
括弧(相当の文字列)以外は全て(LISPでいうところの)symbolとして扱う。文字列を示す書式は無しの方向で(「symbol->string」相当は提供するかも)。
LISPのquote、quasiquote系は今のところ無し。
不完全なリストは無し。よってドット対表現も今のところは無し。
schemeのsrfi-38の「#0#」「#0=」相当は実装する。
これらのドキュメントを「read」すると当然、cons cellによって構成された内部形式されるが、これらを「write」した際に、元の「括弧の文字の種類」や「空白文字の種類」が元通り再現されなくてはいけない。
- これは、cons cell及び空listの構造を拡張して、その拡張領域に「括弧の文字の種類」や「空白文字の種類」等を記憶しておく事で実現する。
  - srfi-38の「#0#の文字の種類」等はどうやって記憶する？あとで考える。

書式

書式の詳細な定義はサブセットによって定義されるが、基本的な構文は以下のようなものを提供する。

LISPの括弧相当。これは二種類の形式がある。
- 『対括弧』。開き括弧を示す文字列と、閉じ括弧を示す文字列のセット。
- 『囲括弧』。対括弧に似ているが、開き括弧の文字列と閉じ括弧の文字列が同一なもの。
『NIL』。LISPのNIL(空リスト)を示す文字列。尚、対括弧や囲括弧の内部が空のものも自動的にNILとして扱われる。唯一の偽値。
『srfi38』。srfi-38の「#0#」「#0=」相当。#0=の記憶範囲は一つのCSELドキュメントのみまでとする。
『空白文字』。LISPでのspaceやCRやLF等に対応。
上記以外の全ての文字列はシンボルとして扱う。

これらの呼び名も統一すべき。

これらの定義は、定義された文字列が長いものから優先的にマッチングされるものとする。

サブセット

サブセットはとりあえず「LISP互換+」「英語」「日本語」を考える。但し、実装は「LISP互換+」「日本語」の二つでやってみる(「英語」は一部の文字がLISPと相性が悪い為)。

このサブセットの仕様は、XMLのdtdのように、サブセット定義構文で定義内容を記述するようにする、将来的には(今は適当に書く)。

lisp-0.0

「(」「)」対括弧。
「[」「]」対括弧。
「{」「}」対括弧。
「"」囲括弧。
「'」囲括弧。
「#n#」「#n=」srfi38。今のところnは0～9の範囲とする。
(省略)空白文字。定義は省略するがLISPと大体同じ。

ascii-0.0

「,」空白文字。
「.」空白文字。
「!」空白文字。
「?」空白文字。
「;」空白文字。
「:」空白文字。

jp-0.0

"「" "」" 対括弧。
"『" "』" 対括弧。
"【" "】" 対括弧。
"［" "］" 対括弧。
"〔" "〕" 対括弧。
"（" "）" 対括弧。
"《" "》" 対括弧。
"〈" "〉" 対括弧。
"“" "”" 対括弧。
"｛" "｝" 対括弧。
"‘" "’" 対括弧。
"　" 空白文字。
"、" 空白文字。
"。" 空白文字。
"！" 空白文字。
"？" 空白文字。
"：" 空白文字。

実装例

あとで。

実装

あとで。

拡張

音声言語への対応

おそらくサブセットとして対応する。
- ベースはlisp-0.0互換だが、出現するシンボルを音声言語の音に対応させる。
- 音声言語は容易にエラーが発生する為、各音に対して「aの音である確率50%、eの音である確率30%、...」のような情報を持たせる。これもシンボルに含める。

問題点

ascii artを正しく扱えない。どうする？
- 将来的には正しく扱えるべき。
- schemeのように、「|」で囲んだら強制的にシンボル、という構文を用意すべき？
  - この場合、ascii art中で「|」を扱えなくなる。
- それとも、エスケープ文字を用意する？
  - こちらは万能だが、ascii artを人間が読み書きする際に問題がある。
なるべくルールが簡単になるようにしたいが、不正な括弧対応とかを考慮すると、結局、構文解析とかしなくてはいけなくなるような気がしないでもない。しかし可能なら構文解析に頼らなくてもすむ構文にしたい(読み方が一意に確定する構文にしたい)。
音声言語に展開できる必要があるが、"『』"等のよい標準的な読み方がない(毎回「かっこ」「かっことじる」と言うのは冗長すぎる)。
- 「えーっと」「です」とかにマッピングすべきか？これはこれで逆変換時に困りそうだが。
- 日本語に存在しない発音(例えば舌を鳴らすとか)をマッピングすべきか？どうも、そうするしかなさそうな気がする。
  - あとでマッピング可能なアクションを一覧にしておく事。

ある程度運用してみた結論

これは自分の手に余る作業ではないか？Larry Wallにでも助言欲しい。
- 例えば「りんご」と「林檎」はシンボルは違うが、指し示しているものは同じだ。しかしこれをクオリア的な何かとみなして同一視する操作を、どのレベルで行うべきなのか？
- 「りんご」というのは果物クラスの一種だが、ある実在の物体を指し示す代名詞かも知れない。ややっこしい。
- 人間はマッチング及び簡約によって、言語を扱っている……という認識で進めて大丈夫なのか？
これは本当に人類に扱いやすいのか？
- 人間の使う自然言語は基本的に全て音声言語がベースとなっており、音声言語は全て時間軸に沿って進行する、一次元(が基本になった)言語である。LISPはプログラミング言語であり、個々のS式は自然言語同様に、時間軸(記述時間軸？)に沿って進行するが、一つのS式をreadするのは一瞬で完了してしまう為、括弧のネストに制約が無い。しかし人類にとっては、括弧のネストが増えるにつれ次元が一つ増えるのも同然なので、要求される計算能力は大きく増加してしまう。
- 訓練すれば、そろばんを操作するみたいに熟練できるものなのか？それとも「クリスタルの夜」のファイトのように、脳改造しないと駄目なレベルなのか？
- とりあえずPCがあればエディタ等による補助が受けられるが……。
  - この方向では、未来人は常に携帯端末を持ち、そのサポートが無いと他者の発言を理解するどころか、自身の発言を構築する事すらできなくなる、という未来が見えてくるが、これはまずいだろう。
  - しかし「未来人は電子執事と電子秘書に頼って生きていく」という未来でも、やっぱり携帯端末を持っている訳で、そう考えるのなら、この方向でもいいのでは。
- 括弧のネストが駄目なら、Haskellの「$」を導入するという手もあるが？
  - これは検討する価値はある。しかしできるなら、構文自体は単純なままにしておきたいが……。
  - 言語を記述する際は時間軸に沿って記述する必要がある為(プログラムがS式を吐き出すのであれば一瞬だが、人間はそうはいかないので)、その意味で「$」の導入は良いかもしれない？
  - とは言え、Haskellの「$」は「aaa (bbb ccc (ddd eee))」が「aaa $ bbb ccc $ ddd eee」になる程度なので、省略できるのは閉じ括弧ぐらいであり、本当に導入する価値があるのかは微妙な気がする。

最終更新 : 2009/12/01 01:05:47 JST