Alan
Technical Document

目次

1. 本書の目的
2. 設計方針
   1. 層状の宇宙
   2. 複雑さの制御
   3. C++, Perl の置き換え
   4. 学習曲線がリニアな言語
   5. 開発者・保守者・実行効率、の優先順位で考える
   6. Simple C++
   7. Turing から学ぶ
   8. Eiffelから学ぶ
   9. Perlから学ぶ
   10. Cobolから学ぶ
   11. シンプルに
   12. 型について
       1. 潜水服と飛行機工場
       2. 思考を妨げる型、支援する型
   13. D&E
   14. 参照一様性
3. クラス関係図
4. Tiger, Oberon-0 について
   1. 比較
   2. Oberon-0 の Item と Obj についての考察
5. 実行フロー
6. ソース中の接頭辞(prefix)
7. 組み込み型の追加
8. 今後の計画
9. リリース作業

本書の目的

設計方針

1. 層状の宇宙
2. 複雑さの制御
3. C++, Perl の置き換え
4. 学習曲線がリニアな言語
5. 開発者・保守者・実行効率、の優先順位で考える
6. Simple C++
7. Turing から学ぶ
8. Eiffelから学ぶ
9. Perlから学ぶ
10. Cobolから学ぶ
11. シンプルに
12. 型について
    1. 潜水服と飛行機工場
    2. 思考を妨げる型、支援する型
13. D&E
14. 参照一様性

設計方針

層状の宇宙

Alan及び Alan を取り巻く外環境を層の視点から分類したのが次の図だ:

人間

アプリケーション GUI, CUI

ミドルウェア・ライブラリ i/o, Math, CGI, SOAP, DB, ...

Alan VM, 仕様, parser, lexer, semantics, ...

OS

デバイスドライバ

ハードウェア

大枠として、なるべく「層全体でシンプルに」なるように 物事を決めていこうと考えている。

例えば、例外処理機構。VM の実装という点で見れば例外処理機構は 複雑になってしまうが、この機構のおかげで上位層の実装が簡単になり、 結果として「層全体でシンプルに」なると判断したため、例外処理は Alan に取り入れたのだった。

逆の例を。言語の肥大化かライブラリレベルでのサポートか、というジレンマがある。 Cobol は言語の肥大化に進んでしまった例だ。
これと対極にあると思われるのが Lisp だろう。Lisp の言語仕様は 恐ろしく小さく抽象度が高い。そして、できることはライブラリのレベルで 対応しようとしている。オブジェクト指向もライブラリレベルで いくつものオブジェクト指向ライブラリが提供されていると聞く (Shiroさん、参考にさせて頂きました)。

「シンプルに」という原則で見れば Lisp の辿った道の方が優れているようだ。

これは、下位層を単純にし・上位層でそのしわ寄せを吸収することで、 最上位層(アプリ・人間)に対しては影響を与えないようにした例だ。

「層状の宇宙」という言葉は、マイケルポランニー「暗黙知の次元」から借用した。

複雑さの制御

"複雑さは、おそらくソフトウェアの品質の唯一の最も重要な敵ではないだろうか" -- B.Meyer, OOSC1, 邦訳版 p.161

以下、TBD.

C++, Perl の置き換え

今の C++, Perl は覚えることが多く、今の私の小さい脳ではオーバフロー 気味となってしまった。 不満と見るか、修行不足と見るかは難しいが、 とりあえず、この不満を取り除き頭をすっきりさせたい、というところ。 文字通りの「俺言語」だ。でも、それでいいのだ。

学習曲線がリニアな言語

1. 初心者にとっつきやすい
   -> 最初の敷居を低く
   -> 時間軸=0 の時、レベル=0から始まる、の意。
2. 途中で急に難しくならない
   -> 反例：Cのポインタ
   -> レベルが急勾配になったり不連続にならない、の意。
3. 途中から飽和しない
   -> 反例：実用以前で機能が飽和した、オリジナルPascal
   -> 反例：いわゆる 4GL 言語。初心者向け機能が豊富だけど、 すぐ使えなくなる傾向にある。
   -> ある時期・規模を超えると、とたんに使えなくなるようなことの ないようにする、の意。
4. どこまでも上昇
   3. の裏返しだが。(しかし、そんな言語私に作れるのか?)

開発者・保守者・実行効率、の優先順位で考える

Simple C++

Turingから学ぶ

Eiffel は、メイン関数の存在を批判していたが、私には いまだにその理由が分からない。オブジェクト指向と フリー関数は相反する存在なのだろうか？

個人的にはそうとは思えないのと、Turing の例もあることから、 Alan ではシンプルなケースはシンプルに、ということにしたいと 考えている。

Eiffelから学ぶ

しかし、Eiffel の仕様には不満もある。

1. rescue 句を設定できるのが関数スコープだけ (任意の end を rescue ... end に拡張できない)。
2. quasi_inverse() (OOSC1 邦訳 p.210) はまともなフローとは思えない。
3. rescue句の最後で上位に自動的に raise する仕様。 DbC に基づけばそうなるのだろう。しかし、このために ignore を 後付けで提供しているのなら、どちらが正しかったのか・・・。

   C の switch が 97%間違っている(Deep C Secrets だったか?)例は示唆的だ。 C の switch が fall-throw なのは、そちらの方がより汎用的だからだ。 しかし、そのために break 文を 97% の個所で書く必要が出てきた。 3%の利益のために、97%の個所でバグを誘発しやすくなったわけだ。

4. Eiffel は普通のエラー処理と例外処理を分けて考えていること。 従来の方法(if文によるステータスチェック)が優れているケースが多い ことを OOSC1 では論じている。ここまでは私も同意する。 しかし、エラー処理と例外処理が別のものとなるなら、 かえって複雑さが増えはしないか。

Perlから学ぶ

1. 論理式の or や and が、数学的には可換が普通だが、 Perl や C では A and B では A を先に評価し、成り立たなければ B は 評価しない、という仕様になっていること。一見、論理的透明さ・単純さとは 別の複雑な仕様のように思えるが、

   if( a!=NULL && a->f() )

   のような例を考えると、人間的には確かに Perl/C 方式の方がしっくりくる。
2. 他にもあったような・・・(今思い出せない)

認識の過程的構造というやつだろうか。

Cobolから学ぶ

でも、Cobol のプログラムはあとから読みやすい、というのが定評だ (もちろん異論もあるだろうけど)。私も、C や Perl と比べて、 Cobol の 単語指向(word-oriented)な言語の方が読みやすいと感じている。 C や Perl の記号指向(TBD-oriented)の言語は、一旦頭の中に入ってしまうと、 多くの機能を圧縮して記述できる。 １行のプログラムがそれなりの処理をしてくれるので、「俺ってスゲー」感を 満たしてくれる麻薬的な(大げさ^^;)側面があり、かなりハッカー(主に開発者)に 熱狂的に受け入れられた、と私は見る。でも、C や Perl の使用者自身が 認めているように、１年後にそのコードを見ても何をやっているのか 書いた本人にも解読不可能になってしまうのが記号指向言語の副作用か。

私は C/C++/Perl を使うが、気持ち的には「後から読みやすい単語指向言語」 の方が段々好きになってきている。

シンプルに

型について

1. 潜水服と飛行機工場
   コンパイル時に型チェックを行い、実行時に行わないことを

   潜水服を着て練習し、実際に海に潜るときに 潜水服なしで潜るようなもの

   という例え話で、型あり言語を批判した例がどこかにあった記憶がある。

   私は、これは違うと思っている。 むしろ、型チェックとは、工場で飛行機を整備するようなもの、 あるいは、オリンピックなどの試合に望む前に練習場で訓練したり何回も 失敗を繰り返したりしておくものではないか、と。

   で、いざ飛ぶときには、一緒に工場をつれて飛ぶは必要ない、 ・・・そういうものではないか、と思うのだが。

2. 思考を妨げる型、支援する型
   C++ と Perl を長年使用してきて思ったことは、 型があった方が仕事が捗ったということ。 むしろ、Perl の方が注意深く「えー、この時に使う演算子は・・・」 といった感じで余分に神経を消費してきた ^*。

   C や Pascal などのデータ型は、 関数やブロックの最初で宣言しないといけない。 そのため、文を書き下している最中に追加で変数が必要になるとソーステキスト の上の方に戻って型を宣言して、それから戻って・・・といった感じになり、 思考を中断してしまう。

   でも、(CLUを先祖とする?)C++ などのように必要なときになって宣言できる 構文では、思考の妨げにはならない。int を使うのか str を使うのか、 file を使うのかは既に決まっているわけだし、型があるため、演算子が "+" なのか "." なのか、eq なのか == なのか、ということにも 悩まなくて済む。

   そういうわけで、C++ の型は、思考のコストを下げてくれる、と思っている。

   Perlだって、int か string かの区別はないけど、スカラーか($x)、 配列か(@x)、連想配列か(%x)、の区別がある。型の区別を 変数の表記法で行っているわけで、型があると言えないこともない。

   交通ルールは、車のじゃまをしているのではなく、スムーズな交通を促すための もの(原則は)。

   いきなり金銭感覚の話になるけど、 節約のための色々なガイドラインは自由を束縛するものではなく、 むしろ無駄な出費を抑えることで、使いたいことにお金を使えるようにする ためのもの、つまり、より自由度を増してくれるものだ。

   データ型も、CLU / C++ に至って、思考を支援してくれるもの、 とは考えられないだろうか?

   C や Pascal がなぜ関数やブロックの最初に宣言しておかないといけないかと いうと、1パスでコンパイルさせるための単純化だったと予想する。 1パスでコードを生成するためには、関数の最初に、コードを生成する前に その関数で使う全てのローカル変数の領域を確保する必要があるから。 (バックパッチすれば1パスでもできるのかな?)

   * この点について、まつもとさんから " 動的言語の代表としてPerlを選ぶのはやめてほしい " とのコメントを頂きました。 まあ、私は Perl しか知らず、代表という意味で書いたわけでは ありませんので、ここはそういうことでご了承下さい。 型なし言語として Perl しかしらなかった男の不幸と思って頂ければ・・・ (^^;)。 Ruby か Python を知っていれば Alan を作ろうなどという無謀なことも 考えなかったかもしれません(自爆)。 ・・・というのは冗談 50% で、言語処理系の深奥を知るために 作っているので、まあこれはこれで良いのか、と。
   ここで突然 Perl思い出話になってしまうのだが、 Perl を使って10年近くになるのだが、特に不満というのはこれまで なかった。CPAN は素晴らしいし、ライブラリはそろっていたので。 ところが、ふと仕事で SOAP 辺りを扱う必要が出て CPAN から SOAPLite をダウンロードして使おうとしたが、分け分からなくて逆ギレしたのが、 Perl に見切りをつけたくなったきっかけだった。 ここで Python か Ruby に転向するパスもあったはずだが、 Alan という泥沼にはまってしまったのが Alan の発端であった・・・ というのは本気 50% である。

D&E

• Alan に関しては却下するもの(まだ明確に却下したものはないが)
• 特に重要視したいもの

C++ D&E を参考にした、言語開発の難易度:

相対 難易度	項目	コメント
x100	テンプレート、例外処理
x10	多重継承	"...[多重継承反対論者は]多重継承を深刻に受け取りすぎている...。 多重継承はプログラミングの万能薬ではない。 安物の薬だから万能でなくても良い。" (D&E-J p.342)
(TBD)	名前空間	まだ難易度が良く分かってないもの
1	RTTI(RunTime Type Information)	"...RTTIは例外処理やテンプレートにに比べて２桁以上簡単...であり、 継承と比べて１桁以上簡単...なのだ。" (D&E-J p.390)

参照一様性

参照一様性とは、オブジェクト x のメンバ a が関数であるか変数であるか に関わらず、同じ表記をすることを言う。例えば、Eiffel や Ruby では、 引数無し関数と変数はどちらも x.a と表す。C++/Java ではメンバ変数だと x.a で、メンバ関数だと x.a() となり、一様ではない。

Alan の参照一様性は配列にもあてはめることとする:

変数と関数の参照一様性

a

配列と関数の参照一様性

a(i)

配列を丸括弧で表現するのは Fortran の影響である (というより、配列と関数は参照時、意味論的に同一なので 同一の表現であるべき、というポリシーが最初に頭の中にあった。 そこから振り返ってみると、Fortran がその祖先であったことを改めて 再発見した、というのが真相である)。

比較

クラス関係図

(*1)

変数の各フェーズを追っていくと、変数というものが各フェーズで どのように変換されていき、最終的に実行対象となるかが見えて 分かりやすい。
構文解析時は、単なる文字列 id であり、ソース中の出現位置 pos を保持している(定義文 (例: int i;)は A_stmt の派生クラス、 式中の使用(例: ... 3 + i * j ...) は A_exp の派生クラス)。
意味解析時、アドレスを保持しており、型情報(=サイズ情報)を 参照している。
そして、実行時、int のような簡単なケースは、指定された アドレスを直接 C++ の int にキャストして実行している。また、 Alan 独自のデータ型 (str, file, rex, arrayなど)の場合は 実行時データを表現する構造体 V_type にキャストして 実行させている。実行時は変数名(id)もソース上の位置(pos)も 必要ないのだ。

(*2)

まだユーザ定義型をサポートしていないので A_type がそっけないのは これでいいのだけれども、Obj_type と Type の間の関係が イマイチはっきりしない。本来、実行時に型名など必要ないのだが、 debug 目的に追加した結果、Obj_type と重複してしまっている。 まあ、こういった未整理部分を発見するためにこうやって クラス関係図を作ったのだから目的は達せられたのだが。 さて、どう解決しよう。

Tiger, Oberon-0 について

1. 比較
2. Oberon-0 の Item と Obj についての考察

比較

以下、補足。

1. 関数は引数がない場合は括弧不要にしたい 理由:下記のようなシンプルな記述ができる:

   window.position.x

   プロパティのようなものだ。 Eiffel の参照一様性(だったか?)にも通ずるか? 確か Ruby もここら辺り注意深く設計していた記憶がある。

2. 上と同様に、手続きも括弧不要にしようか、と思ったが、v0.03 辺り？で Cライクな変数定義文法と衝突することが判明。

   a b;

   とあった場合、これが変数定義

   int i;

   なのか手続き呼出し

   put i;

   なのかは文脈自由文法の範囲では判別できない。

Oberon-0 の Item と Obj についての考察

実行フロー

ソース中の接頭辞(prefix)

組み込み型の追加

1. 必要に応じて字句解析ルーチンを alanl.l に追加。
   例: regex
2. 必要に応じて構文解析ルーチンを alany.y に追加。
   例: T_REX_LIT
3. 必要に応じて構文木を absyn.h, absyn.cpp に追加。
   例: A_exp_rex_lit()
4. データ型の実装を type/ に作成。
   ここがデータ型追加の核となる。 例: rex.cpp, rex.h
5. データ型を type/types.h, types.cpp に追加。
6. 必要に応じて意味解析ルーチン semant.cpp を変更。 例: rex.cpp, rex.h
7. 必要に応じてコード生成部 gen.cpp を変更。
8. 必要に応じて VM vm.cpp を変更。
   (rex の場合、変更部分はなかった(!))

今後の計画

• クラス（オブジェクト指向）
• 固定小数点型(number系) --ビジネス分野では必須。
• CGIライブラリ
• DBライブラリ
• 型パラメータ
• 暗黙の型変換。 char→int→real→real8, cstr→str (関数引数にて), char→str ぐらいは最低サポートしないと。
• 安全な可変長パラメータ
• パターン
• Alanチップ(冗談?本気?)

制約事項 の項参照）も参照。

リリース作業

1. ドキュメント整備
   1. ChangeLog 作成 devlocal/svn_diff.sh の出力を参考に。
   2. README の version を書き換え and/or 作成
   3. devlocal/version を書き換え
   4. install.d/install の PREFIX を書き換え
   5. doc/version, doc/footer.html を書き換え。
   6. SourceForge 向け document 作成
   7. langsmith, NetNews へのアナウンス文書も作成
2. バージョン管理
   SubVersion リポジトリに保存
3. make dist
4. Installテスト
   Install が問題なく行えるかテスト。 問題が発生すれば、前に戻ってやり直しだ。
5. パッケージの up SourceForge に up
6. Homepage への document の up
   1. cd doc; make doc_up
7. SubVersion にタグ付け
   この段階になってタグ付をしよう。タグ付はリリース直前の作業だ。 devlocal/svn_tag.sh 参考に。
8. NetNews, langsmith, などでアナウンス

Top / Technical Document