acl4の開発ログ #05
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
- なんか昨日くらいからプログラミングの考え方が変わったかもしれません。
- メモリなんて必要な時に確保して放っておけばいいんです（笑）。
- ・・・いやそんなことをしたらもちろんメモリリークするわけですが、そんなのはデバッグ時に全部見えるので、設計しながら作っているときは考えなくていいじゃないかと。
- それでデバッグの時に、全部のリークが無くなるまで修正をすればいいだけなんです。
- これをするようになってからは、悩みが減ったのでプログラミングが少し楽になりました。
- なるほどなあ、こうやって私は「あまり考えないプログラマ」になっていくのか！（笑）。
- これをやるときは、一段落するごとにちゃんとデバックする必要があります。
- そうしないとリーク量がすごくなって、どのリークがどこ由来なのか推定できなくなってきます。
2026.02.10(火) #0
- 現在作っている自作のプリプロセッサが期待以上に優秀で、もう自分が普段使いしていいのではないかと思うようになりました。
- 普段使いするとなると、あれもこれもと追加したい機能が増えて、なかなか仕様が固まりません（笑）。
2026.02.10(火) #1
- 普段使いレベルにするための残作業：
- __FILE__ と __LINE__ に対応する。
- func.(...) 拡張に対応する。
- コンマが多すぎる場合には自動で消してくれる機能を入れる。
- 入力行 の #line 対応。
- 出力行 の #line 対応。
- #演算子の対応。
- 普段使いするようになったら、拡張機能は全部使いたいので、それ以降に書くソースコードは普通のCコンパイラだけでは処理できなくなります。
- その区切りをはっきりさせるためにも、 acl4 ライブラリもいったんそこで区切って、それ以降を a_Version=2 として開発することにします。
2026.02.10(火) #2
- [Q] どうしてそんなにプリプロセッサにこだわるの？
- [A] いやだって、ここでいいプリプロセッサを作っておけば、今後私が作る言語にはプリプロセッサが標準搭載になるのです。
- プリプロセッサ処理がライブラリ関数の呼び出しでできてしまうのだから、つけない理由はないのです。
- だから今ここで頑張っておけばあとで楽できそうだなーって思っているのです。
![[PukiWiki]](image/pukiwiki.png "[PukiWiki]")
