a4_log05 のバックアップ(No.9) - essen-wiki

[ トップ ] [ 新規 | 一覧 | 単語検索 | 最終更新 | ヘルプ ]

acl4の開発ログ #05

(by K, 2026.02.04)

2026.02.04(水) #3

私のこの開発スタイルは「ライブラリ駆動開発」というべきものなのかもしれないです。

私が開発しているのはライブラリです。サンプルコードはもちろん作りますし、サンプルとして作ったものを使うこともありますが、しかし開発の際に心がけているのは、「今書いているこの関数を一般化することはできないか？もしできるなら、それをライブラリに加えたい」ということです。
これを続けていくことで、ライブラリはそれなりに大きくなります。これは財産で、このライブラリを使って似たようなものを早く作ることができますし、複雑なものを早く作れるようになります。
だからこそ、アプリを作ることよりもライブラリを充実させることを優先するのです。ライブラリができてしまえば、アプリはいつでもすぐに作り直せます。

このスタイルでやったら、OS自作とかも短期間でうまくできたりするのかな？？

2026.02.05(木) #0

現在、プリプロセッサを作るための部品をそろえていますが、プリプロセッサの仕様について考えています。
標準的なプリプロセッサの仕様では、「ローカルマクロ」みたいなことができません。
ローカル変数では、 int i; とやれば、それまでに宣言されていた i は隠されて、新しく宣言した i だけが使えるようになって、スコープを抜ければ以前の i にまたアクセスできるようになります。
でもプリプロセッサでは #define Macro ... としたときに、すでに Macro が定義されていれば二重定義エラーになるだけですし、 #undef すれば消えるだけです。
私はこれを二重定義エラーにはしないで、 #undef したときに元の定義に戻るようなそんなプリプロセッサにしたいです。

これをそのままやると互換性の問題が大きすぎるから #define, #undef とは違う名前にしようとは思っています。

2026.02.05(木) #1

acl4について、どういうことができるライブラリを目指すかですが、とりあえず、典型的な言語なら、インタプリタでもコンパイラでも、300行未満で書けてしまうような、そんなライブラリにしたいです。
・・・そんなことが可能なのかは全然考えていないです。ただの漠然とした目標です。
またOS自作のための支援関数も欲しいですよね。カーネルが300行未満で書けたりしたら、底抜けに楽しい気がします。
- そのためには、標準関数が使えない環境をどうするかという問題がありそうです。自前で標準関数に相当するものを用意すればいいのかな？a4_0001の代わりを作ればいけるかも？

2026.02.05(木) #2

アセンブラやリンカとかも簡単に書けるようなライブラリにしたいですし、エミュレータも簡単に書けるようにしたいです。
つまり、私の今までの集大成的なライブラリですね。これがあれば私が作りそうなものは何でも簡単にできる、と。
なんだー、このライブラリと使い方のサンプルがあれば、もう私なんていらないじゃーん。・・・まあ、そういうものを作りたいわけです。

2026.02.06(金) #0

今日はプリプロセッサ処理の、#if～#elif～#else～#endifをできるようにしたい！
あともうちょっと、というところまではできました。

2026.02.06(金) #1

よく考えてみたら、競技プログラミングの世界は、自作のライブラリを持ってくるって結構普通のことですよね！
ということは、競技プログラミング業界にライブラリ自作のノウハウがいっぱいありそうな予感！！

2026.02.06(金) #2

ちょうど今も、自分が作ったmallocのエラー検出機能に助けられた！ほんとに便利だな！！
そして、a4_0008のインライン機能も快適です。ファイルを作らなくても簡単にテストプログラムを試せる！

2026.02.06(金) #3

a4_0010 を書きました。これでプリプロセッサ処理のうち、includeとundef以外はできるようになりました。
たぶんこの調子で開発していくと、プリプロセッサ処理が一通りできるようになるのは時間の問題だと思うのですが、そうなると今後私はどんな言語を作っても、すべてプリプロセッサ処理を標準搭載できるってことですよね。これは結構うれしいです！！

2026.02.07(土) #0

手元では、include処理が動くようになりました。
実は当初の予定よりも苦戦しました。苦戦の最大の理由は、今処理している行が、どのファイルの何行目に由来しているのか、きちんと管理するようにしたからです（今までその辺の処理をさぼっていました）。

2026.02.09(月) #0

なんか昨日くらいからプログラミングの考え方が変わったかもしれません。
メモリなんて必要な時に確保して放っておけばいいんです（笑）。
・・・いやそんなことをしたらもちろんメモリリークするわけですが、そんなのはデバッグ時に全部見えるので、設計しながら作っているときは考えなくていいじゃないかと。
それでデバッグの時に、全部のリークが無くなるまで修正をすればいいだけなんです。
これをするようになってからは、悩みが減ったのでプログラミングが少し楽になりました。
なるほどなあ、こうやって私は「あまり考えないプログラマ」になっていくのか！（笑）。

これをやるときは、一段落するごとにちゃんとデバックする必要があります。
そうしないとリーク量がすごくなって、どのリークがどこ由来なのか推定できなくなってきます。