*5ほかの例も試してみましょう。値コンストラクタの第1引数です。なんて変数はたしかにありません。型の値がくるべきだと分かります。型クラスインスタンス宣言があります。型の値を評価するとどうなるか、ちょっと見てみましょう。定義されてるように文字列が印字されます。当然ですが、これらの印字結果は、定義されてる値コンストラクタの表現とは異なりますので、これをこのままソースコード中に書いてもエラーになります。プログラムとして読み込まれるようになります。定義したりすると、同図像性がくずれてしまい、利用者が「ちょっと式を評価してみてどんな値になるか試してみよう」と思っても、よく分からない表現が印字されて困ったりすることがあります。定義しようなどと思わない方がよいでしょう。型クラスとは関係ない関数を定義するべきです。入門会のハッカソンタイムでは、このような同図像性が壊れてる部分をちまちまなおしたりしていました。上げておきましたので、よろしければご覧になってみてください。https://github.com/h-hirai/netlist-verilog*1:正確にはこれはリテラルではないと思うけど、リテラルと見なしても実用上問題なさそうに思う。*3:こわい山本さんももともとそちらの出自ですね。*4:いや、まぁ、実際は、地道にソースコードを追っかけてるわけなんですけど......。*5:ちょっと改行をいじりました。記事名に(1)とかつけて続き物を書き始めておいてなんですが、真・女神転生IVで忙しいのでしばらく続きはありません。お話するとついったなんかでは、うんうん誰もが一度は通る道だよとかなんとか生暖かい目で見られたりなんかしたりするわけですが、はい。生成するプログラムを書いたことなら、だいぶ前にあるんです。ジェネレータを書くにしても同じ方針でいくのがいいよなー、と思ったところでまず思いつきました。ライブラリを公開してるひとはひとりやふたりではありません。その中からよさげなやつを探して、そいつで定義されてる抽象構文木を文字列に変換するプログラムを書けばいいわけです。構文解析の逆変換を行うプログラムともいえます。ものが提供されていたりします。ライブラリの使い方を解説する記事、......ではないです。ここまで考えたところでもひとつ思いつきました。......ありました。