「プログラミング言語を作る」を 立ち上げてはみたものの、最近何かと忙しく、更新がままならないので、 プログラミング言語関連の雑記でも書いてお茶を濁そうというのがこのページの主旨です。 現状(2005/4/11現在)で、ひとまずcrowbarは配列まで動作してるんですが、 テストと解説ページが間に合っていません。 現状で、以下のようなコードが一応動いています。 GCはmark-sweepに切り替えました。
# 配列リテラルの生成
a = {1, 2, 3, 4, 5, 6, 7, 8};
for (i = 0; i < a.size(); i = i + 1) {
print("(" + a[i] + ")");
}
print("\n");
# 本筋に関係ないが、文字列のlengthメソッド。
print("len.." + "abc".length() + "\n");
# 配列への要素の追加。
for (i = 0; i < 10; i = i + 1) {
print("a.size().." + a.size() + "\n");
a.add(i);
}
for (i = 0; i < a.size(); i = i + 1) {
print("(" + a[i] + ")");
}
print("\n");
# 掛け算99の表を作る。
a99 = new_array(9);
for (i = 0; i < 9; i = i + 1) {
a99[i] = new_array(9);
for (j = 0; j < 9; j = j + 1) {
a99[i][j] = (i+1) * (j+1);
}
}
for (i = 0; i < a99.size(); i = i + 1) {
for (j = 0; j < a99[i].size(); j = j + 1) {
print("[" + a99[i][j] + "] ");
}
print("\n");
}
さて、そんな話はひとまずどうでもよくて、 今回のネタは、この4/1に発表されたPythonのエイプリルフールネタ Stricter Whitespace Enforcementです。 ネタ元はまつもとゆきひろさんの日記 Matzにっきより。
Matzにっきの方が詳しいのでそちらから引用すると、
- インデントは厳密に空白4つ。タブ問題もこれで解決。
- 冗長な括弧は禁止(例: return (1) は駄目、return 1が有効だから)。
- 左括弧直後および右括弧直前の空白は禁止。
- 引数括弧およびインデックス参照のブラケット直前の空白は禁止。
- コンマやセミコロンの前の空白は禁止。
- コンマやセミコロンには厳密に一つだけの空白(行末を除く)。
- 行末のセミコロンは禁止(冗長だから)
- 式の中で二つ以上の連続する空白は禁止。
- 代入および比較演算子の前後には必ず空白が必要。
- 演算子の左右の空白の量は等しくなければならない。
- 式の中の空白の数に変化がある場合には演算子の優先順位を反映して いなければならない。 つまり、"1*2 + 3*4" は大丈夫だが、 "1*2 + 3 * 4" は駄目。 しかし、推奨されるのは"1*2+3*4" である。
- コロンの前の空白は禁止。
- ディクショナリリテラルではコロンの直後に厳密に一つだけの空白。 スライスのコロンの直後の空白は禁止。
- ブロックの短縮形式 ("if x: y") は廃止。改行とインデントを使うこと。
(中略)
また、Python 3.0からは縦方向の空白ルールも導入される。
- 関数定義またはメソッド定義の間には最低1行の空行。
- クラス定義間には最低2行の空白。
んで、 PyJUGのページのコメントを見ると、「4月1日なのが残念なくらいです」とか、 「エイプリルフールなら悲しいぞ・・・」とか、 本当にこういう規制をかけてほしい、という要望がPythonユーザには多いように見えます。
私自身、センス・オブ・プログラミングには、
正直言ってこんなのは慣れの問題でしかありません。
くだらない論争をしているよりは、
- 多人数で開発を行っているのであれば、 そのプロジェクトのコーディング規約に合わせる。
- 趣味でプログラムを書いているのであれば、世間に広く使われているスタイルを選び、 以後ずっとそれを使い続ける。
という方針に従うべきでしょう。
ということを書いています。 つまり、インデントとか空白の空けかたなどの瑣末なスタイルは、 所詮慣れの問題でしかないので、統一することにこそ意味がある、 というのが私のスタンスです。
じゃあ、crowbarでも、中括弧の位置とかをコンパイラが把握し、 決められたスタイルから外れていたら、 コンパイルエラー(警告ではなく)にしてしまえばいいじゃん、 という意見も当然考えられるわけです。 技術的には、これはさして難しいことではありません。 lexを使っていると難しいかもしれないけれど、 レキシカルアナライザなんぞ自作したってたいした手間がかかるわけじゃなし、 実際私は、仕事で、とある顧客のコーディング規約に従っているかどうかをチェックする プログラムを書いたことがあります(対象言語はC)。 レキシカルアナライザを自作し、トークンごとに出現位置(行番号とカラム)を保持して yaccで作った完全なCパーサでチェックをかけました。
しかし、そういう「厳密なチェック」は、 仕事で作る大規模なプロジェクトでは有効でも、 初心者が最初に作るプログラムではどうかなあ、とも思います。 たとえば、以下のようなif文について(言語はcrowbar)、
if (a == 10) {
print("aは10です\n");
}
といったことをコンパイラで強制することは確かに可能です。 でも、仕事でばりばりコーディングする人を相手にするならともかく、 プログラミング自体の初心者に、こんな瑣末なコーディング規約を、 言語と一緒に覚えてくれ、というのも無茶な話なわけで、 「crowbarでは改行や空白は基本的に意味を持たない。ただしコメントは例外ね」 という規則のほうが、ずっと覚えやすく、 初心者にとっての障壁を低くしてくれると思います。
ではどうすればよいのか。 たとえばコンパイラに-strictオプションを付けて、 それを付けたときだけ厳密なチェックを行えばよいのか。 でも、そのオプションを使うのは誰なんだろう。 初心者は一度にたくさんのことは覚えられないからOFFにするとして、 熟練者は熟練者で、 こういう瑣末なコーディングスタイルに妙なこだわりを持っている人が多そうだから、 オプションをONにしてくれない気がします。 それじゃ意味がありません。
そう考えると、面白くない結論ですが、 コンパイラはスタイルのチェックはしないようにして、 別途他のツールでチェックをかける、という、 他言語でも使われている方法が一番無難かなあ、という気がします。
言語を作るからには、言語作成者の特権として、 コーディング規約ぐらい俺に決めさせてくれよ、という思いはあるんですけどねえ… 現実には難しい気がしています。
次の雑記 | ひとつ上のページに戻る | トップページに戻る