./index.html ../index.html

Mindに挑戦した時の記録

後輩にひまわりはどうですかと訊かれて、答えられなかったのは少しショックだったりします。 僕はこういうものに偏見をかなり持っている方なのですが、気を取り直して、日本語でコーディングさせる以上、何がしかの文法上の工夫はあるはず、それに得られる物が無くてもネタにはなるだろう、と、処理系をダウンロードしようとひまわりのページに行ってあれこれ読んでたら、同じ日本語プログラミング言語として紹介されていたのがMindです。 ひまわりは、暗黙の変数「それ」で日本語っぽさを出していたのですが、Mindはスタック型らしい。なるほど、その方が日本語っぽいかもしれません。 コンパイラなMindと、レコード(構造体)すら作れないひまわりと、どちらが面白そうか…。 というわけで急遽変更して、Mindです。

Mindは商用なのですが、幸いにも旧バージョンのMS-DOS版が好意により無料配布されていますので、これを使わせていただく事にしましょう。

インストール

PMIND521.TXTを読んでいて思い出しました。 丁寧なドキュメントってこんな風に書くんですね！ そういえばそうでした。 MS-DOS時代ってば、丁寧なドキュメントはひたすらに丁寧でした。 当時は言語乱立でしたので、言語のマニュアルを、今のように「誰でも最低Cを知っている」ことを前提にできなかったのですね。 いい時代でした。 (僕が書いている文が如何に下手くそかわかって、精神衛生上良く無いですな)

え？インストール？ 折角丁寧なドキュメントがあるので、僕がここで丁寧に書く必要は無いんじゃ…。 書き足す事があるとすれば、OSの違いとして、INSTALL.COMが作ってくれるAUTOEXEC.ADDなるファイルを、DOSか9x系OSならAUTOEXEC.BATに書き足す、2000/XPなら、mindready.batにでもリネームして使う事にしませう。

で、HELLO.SRC…拡張子.SRCってどうよ？ また思い出しました。 DOS時代ってば、衝突なんて考えてないソフトの方が遥かに多かったですね。 とにかく、HELLO.SRCをコンパイルすると、HELLO.COMができて、動作確認終了であります。

...\MIND\SAMPLE>pmind hello.src hfile521

日本語プログラミング言語  ＰｕｒｅＭｉｎｄＰＲＯ  Version 5.21
             Copyright(C)2001 Scripts Lab. Inc.

コンパイル中 - 終了。

...\MIND\SAMPLE>hello.com
こんにちは、Ｍｉｎｄです。

DOSのままの.COMってば、Win2000でも使えるのね…。 どうせ印刷とかマウスとか不具合が出るのは目に見えてますが、言語そのものの面白い機能を探る事が目的なので、入出力なんてコンソールさえ使えればいいんです。 実用目的であれば最新版のMindはちゃんと32ビットWindows用になってますしね。 どうせ買うことは無いでしょうけれど。

マニュアルを読む

拡張子が.docだ…。

もっとも、この件に関しては、悪いのは既に広く使われていた拡張子に対して、自社製品の独自フォーマットを割り当てたMicrosoftであることは疑いようの無い事実なのです…が、テキストファイルを読む為だけにWordってのは(平気な人もいるようですが)YTさん的に我慢がならず、しかし毎回「送る」からテキストエディタってのもだるいので、しかし.docの関連付けを書き換えて既に多く存在してしまったWord文書を使い辛くする根性も無いので、こうやってだらだら文句を書きつつ、拡張子.txtにリネームします。

で、MANディレクトリには、KIHONBUN.(DOC改め)txtと、USERMAN?.(DOC改め)txtと、二組のマニュアルがあるように見えます。 KIHONBUN.txtは本の内容をテキストファイルにしたものらしく、今なら.pdfになっているのでしょうか。

…で、少し読んでみると、USERMAN?.txtは処理系そのものへの説明ですね。 僕は一応どんなファイルがあるか程度は読んでますよ…。 お、なんか対話モードもあるっぽいです。 まあ、処理系そのものが目的ではないので、こんなのは後回しでいいか。

文法を説明しているのはKIHONBUN.txtですねえ…。 嫌だ。 リファレンスの場合は別に気にしないのですが、チュートリアルの場合、であるだ調で高圧的に書かれると、どういうわけか生理的に我慢がならんのです。 むしろ「これはこう」と体言止めで簡素に書かれる方が、下手に「～である」と付けられるよりも受け入れられるっちゅーか、同じであるだ調でも塚越さんの本は気にならないっつーか、ようするに文体そのものじゃなくて書き手が文章に込めている読者の見下し方っつーか、とにかく僕は高圧的な日本語が嫌いだ文句あるかっ。 …で、ですます調なら、多少高圧的なものを感じても、文体が文体ですので読んでてあまり怒りを感じずにすむというか…。

そういうわけで、僕は、上記サイトから一緒に落としてきたhankotxt.lzhの、範子講01.TXTに沿っていこうと思います。 こちらの方は、なんか小学生に教えるようなところからスタートしていたりするのがまどろっこしいですが、まあいいか…。 他の人はどうか知りませんが、僕の場合、文章の理解度は、文体に好感が持てるかどうかに激しく依存しますので…。

うーむ…自分でもPMIND521.TXTに感動した影響が残ってるのが自覚できますので、今日はこれ以上書かない方がいいな…。 それでは僕が範子講01.TXTを読み終わるまで、続きはお待ちくださいませ。

今日読んだ中の爆笑ポイント。

とうとう，パスワードをチェックするプログラムを作ってしまいましたね。

KIHONBUN.txt、USERMAN?.txtの両マニュアルでは、序文にて、日本語でプログラムをする事に対して、トンデモ論が展開されているのですが… それも、このセンスには敵わない。

途中で範子講01.TXTに飽きたため、色々見てます。

助詞

単語の　後に　助詞を　続けても　無視される　ようです。 一部の　組み込み　動詞の　場合は　助詞も　見るようなので　不統一と　思いました。 いっそ　Smalltalkのように　助詞を　仮引数名のように　使えないかな？ やはり　この手の　キワモノ言語は　俺なら　こうする！と　色々考えてしまうので　使うより　作る方が　面白そうです。

擬似語

意味のない言葉だそうです。 無視されたり意味がなかったり、日本語としての意味解析をせずして、なんとか日本語として見える文にしようと頑張っているのはわかりますが、プログラミング言語としては欠陥じゃ…。 やっぱ簡単にでも品詞を理解して意味解析するべきじゃないでしょうか。

コメント

※一行コメント

（範囲コメント）

型

リテラル

数値は数値。 マイナス符号あり。 32ビット。 最後にhを付けると16進数。 &ABCDEF&のように、&で挟んでも16進数。

シングルクオーテーションで括ると、C言語同様に文字コード。

ダブルクオーテーション、もしくは鍵括弧で括ると、文字列。 最大32767文字まで。 (MS-DOS版なので当然か) 文字列中の特殊文字は&で、16進数のほか、「&改行&」のような表記もあり。

単語定義

～とは　～である。
～は　～である。

制御文

おまけ(Mindとは関係無いです)

Mindをやってて、日本語OOPLを作るならこうすればいいんじゃないかなあ、みたいなものを思いついたのでついでに書いておきます。

単語の定義は、「整数Aと、整数Bを、足す」「犬Aが、鳴く」みたいに行います。 また、スタックへのプッシュは、その時使われた助詞も記憶しておきます。 で、コード中の「鳴く」に出会った時点でスタックの内容を調べ、助詞、及び、スタック中のデータの実際の型でマッチングを行い、実際に呼ばれる単語を探します。 順序は、並び順ではなく、助詞が見られます。 例えば、「1を、2と、足す」と書いた場合は、A=2, B=1として「足す」が呼ばれます。

さすれば、オーバーロードとオーバーライドを一緒に行えますし、引数の順番を気にしなくても良くなります。 また、ダブルディスパッチをサポートするのも容易です。 特に日本語の場合はオーバーロードは必須じゃないでしょうかね。 今のMindやひまわりでは、「皿を、割る」と、「10を、5で、割る」を使い分けられませんから。

スタックは、構文解析時のみ使って、型解析とか、どこでプッシュした値がどこで使われるかなどを全部静的に解決してしまうのもありですね。

そうすると引数に型を明示する必要も無いか…関数型言語みたいに、全部テンプレートな感じにできるかもしれません。 明示的にオーバーロード/オーバーライドしたいときだけ引数型を書くようにして。 皿なのか数値なのか気にすることなく割れるようになって初めて、日本語の本領発揮…かも。

ついでに、わかち書きが好きではないので、品詞解析ありの最長一致でどうにかならないかな…。 すると単語定義の際に、品詞も教えないとだめか…。