安敦誌


つまらない話など
by antonin
S M T W T F S
1 2 3 4 5 6
7 8 9 10 11 12 13
14 15 16 17 18 19 20
21 22 23 24 25 26 27
28 29 30 31
検索
最新の記事
サンセット・セレナード
at 2017-04-12 23:17
水分子と日本人は似ている
at 2016-06-04 01:49
ほげ
at 2015-06-05 03:46
フリーランチハンター
at 2015-04-17 01:48
アメリカのプロテスタント的な部分
at 2015-04-08 02:23
卯月惚け
at 2015-04-01 02:22
光は本当に量子なのか
at 2015-03-17 23:48
自分のアタマで考えざるを得な..
at 2015-03-06 03:57
折り合い
at 2015-03-01 00:19
C++とC#
at 2015-02-07 02:10
記事ランキング
タグ
(295)
(146)
(120)
(95)
(76)
(64)
(59)
(54)
(45)
(40)
(40)
(39)
(32)
(31)
(28)
(27)
(25)
(24)
(22)
(15)
最新のコメント
>>通りすがり ソ..
by Appleは超絶ブラック企業 at 01:30
>デスクトップ級スマート..
by 通りすがり at 03:27
7年前に書いた駄文が、今..
by antonin at 02:20
助かりました。古典文学の..
by サボり気味の学生さん at 19:45
Appleから金でも貰っ..
by デスクトップ級スマートフォン at 22:10
以前の記事

<   2012年 10月 ( 1 )   > この月の画像一覧

Brainfuckが可愛すぎて生きるのが辛い

本当につらい。具体的にどうつらいのかというと、頭が痛い。おそらく睡眠不足がいけないのだと思うが、それに加えて、起きている間は少しでも暇ができると、Brainfuck(以下BF)をいかにして多機能化するかということを考えてしまうので、脳が休まる暇がないということもあるのかもしれない。

C++やJavaなどはもうすでに十分多機能であり、BoostやOracleならいざしらず、一般のプログラマはどちらかと言うと、これ以上仕様を複雑にしないでくれという気持ちのほうが強いのではないかと思う。しかしBFはというと、色々な人々が訪れてはいるが、言語仕様も処理系も、それほど開発が進んでいないエデンの園状態がまだ残されている。そして、出発点があまりにもシンプルなため、少々手を加えてもそう簡単にはシンプルさを失わない。そういうBFは、プログラムの初心者には手強い言語かもしれないが、処理系の初心者には最高のオモチャといえる。

BFの楽しみというのは、チューリング完備な言語として最低限の機能しか持たないが、しかし抽象的で実装の難しい概念が全く入り込んでいないから、実際に動作する処理系を組んで、色々と工夫をしながらプログラムを動かしてみることができるというところにあるだろう。そして、簡単な問題が解けると、次はもう少しずつ難しい問題に手を出したくなってくる。BFの場合、言語仕様も処理系も最小構成であるので、言語仕様の拡張という方向と、処理系の拡張という方向の2つの方向に発展の余地がある。

BFを考案したMüllerさんは、Amiga OS上で98バイトのインタプリタを書いた。この原始BF処理系では、0で初期化された30000個の1バイト整数が与えられ、入出力はOSのコンソールに接続された。結果としてデータはASCII符号として扱われ、そして "Hello, World!" が書かれた。先人たちはまず、この30000バイトの上限を取っ払って、マシンが確保できるメモリの上限まで与えるような拡張を行った。リニアメモリの要素を16bitなどのint型にしてみたり、アドレスをマイナス方向にも広げたり、そういう拡張もあった。

私が最初に考えたのも処理系の拡張という方向で、FORTRAN以来の高級言語が持っている演算子が実行するような基本演算や、Cの標準ライブラリ程度のシステム操作機能を、処理系に結びついたライブラリとして実装し、BF命令単位あたりの実行複雑度密度を引き上げる方向というのもこの方向に当たる。これはこれで面白い。

ただ、そうして標準ライブラリを備えた処理系に向けてBFコードを書いているうちに、BFでコードを書くコツがだんだんとつかめてくる。そしてついに、素のBFのままでどこまで書けるんだ、というようなことに挑戦してみたいという誘惑が頭をもたげてくる。そして、そういうチューリングマシンの深みから、高級言語で見慣れた水準まで崖を這い上がるための道具を揃えたくなってくる。そういうマクロ言語によるメタBFへの拡張を試みたくなってくる。

そこで、(+ 100)や(+ 0x64)と書けば、'+' が100個並んで、これを出力すれば画面に 'd' と表示される道具を最初に考えた。どうせなら、ということで、(+ \d)と書けば(+ 100)と同じ結果になるような拡張も考えた。{=foo 100} とやっておけば、(+ foo)で(+ 100)と同じになるよう、マクロ変数も考えた。
{=$copy(N) [-(>+ N)>+<(< N)]>(> N)[-(< N)<+>(> N)]}
とやっておけば、{$copy(10)}でデータ10個分のコピーが書けるような、普通の文字列型マクロも考えた。そんな感じで、結構リッチでいい具合のマクロ言語が設計できた。

さて、ここまでは良かった。しかし、この先は結局、マクロとマクロを再帰的に入れ子にしたり、マクロ引数で条件選択して展開結果を調整したり、というようなことがしたくなる。BFは言語レベルが非常に低機能なので、そのプログラミング能力はマクロの構築能力に依存してくる。深さに制限のないネスト、定義時の解釈と展開時の解釈の選択、オプション引数による展開内容の調整、などなど、欲しくなる機能は無数に膨らむ。

そうなってくると、どこぞのLISP系言語を使って、最終的にBF文字列に展開されるマクロ系列を書けばいいんじゃないか、それどころか、S式にBFによる基本ルーチンだけを書いて、あとはそれを組み上げてLISPプログラムを組み、実行結果としてBFのコードを出力したらいいんじゃないか、自分でプリプロセッサを書いてもLISPに勝てる気がしない、なんてことも思った。で、今はとりあえずマクロ言語と処理系の仕様だけ作り上げ、実装の段になったらlibguileなんかに構文解析を丸投げしようか、なんてことを考えている。

それでも、処理系の仕様設計はそれなりに楽しい。ライブラリはなんだかんだ言いつつも結局使ってみたいので、関数コールを楽にするpush系コマンドだとか、スタックを逆ポーランド的に使える演算子コマンドだとかをリストアップし、マイナス値の関数テーブルに配置していく。BFのメモリ上に書き込まれたバイト列をBFコードとしてevalし、それを関数テーブルに登録して利用できるようにするコマンドだとか、登録した関数を別スレッドで実行するコマンドだとか、そういうものを考えている。

メモリモデルも、起動時にメモリ要素を 8, 16, 32, 64 bit int から選べるようにする。他にも、アドレスを bit 単位で移動できる 1bit モード(Bitfuck mode)や、加減算命令にキャリー付き演算を使って隣接アドレスのデータと結合するモード(gigabit mode)なんかも考えている。それぞれに、どう実装してやろうかなんてことを考えだすと楽しくて止まらず、しばらくすると頭が痛くなる。

そんなわけで、Brainfuckが可愛すぎて生きるのが辛い。というか頭が痛い。こういう遊びは25歳までに済ませておくべきだったのだが、40にもなって何をやっているんだか。
[PR]
by antonin | 2012-10-01 23:56 | Trackback | Comments(0)


フォロー中のブログ
外部リンク
外部リンク
ライフログ
ブログパーツ
Notesを使いこなす
ブログジャンル