##私はApollo/Domainで仕事してました CADとか図面管理とか・・・・ そういえば Liquid Common Lisp の入ったテープを日本Apolloの人からもらって、OOなCADのおもちゃとか作った
#ふと、「ボブの Scheme 教室」というのを思い付いた
#はい、ここに木を植えましょう～。
#「ではここのループをマクロにして消してしまいましょう。ね、簡単でしょ？」
#「再帰を自分で書く必要なんてないんです、ほら高階関数で書けた。ね、簡単でsy(ry」
#SRFI 101: Purely Functional Random-Access Pairs and Lists <http://srfi.schemers.org/srfi-101/> #これは結構使えるかも。
#OpenAL をつかえば Impromptu みたいなのができるかなぁ。音楽の基礎的な知識がないとダメかな。琉球調のメロディが乱数を使ってあんなに簡単にできるのはおもしろいですね。
#Impromptuいいですね!
#ふむ、 O(n) な操作のほとんどが O(log(n)) になるんですね > srfi-101
#ソースの先頭を見た感じだと二分木を使っているのかな
#pair 関連の手続きを全部入れ替えちゃおうぜっていう発想が面白いと思いました＞srfi-101
#R6RS だと識別子の名前は変えずに中身だけ変えるっていうのがやりやすくて面白いですよね
#過激なのだと quote や syntax を入れ替えてしまったり
#gosh> (let-values (((v* t*) (values 1 2))) t*)
*** ERROR: unbound variable: t*
Stack Trace:
_______________________________________
0 (v* t*)
At line 287 of "(stdin)"
1 (v* t*)
At line 287 of "(stdin)"
2 ((v* t*) (values 1 2))
At line 287 of "(stdin)"#あ、srfi-11 を use してなかった λ…
#(use srfi-11)
#う、かぶった
#とりあえず srfi-11 を Gauche 用に修正してたんですが、それほど弄るところないですね。
#srfi-11 → srfi-101
##(理屈は理解していない)
##テストの方も。
#ほとんど接頭辞を付けただけな感じ。
#Schemeレベルではcons, car, cdrなどを置き換えるだけでいいんだけど、他言語とのバインディングでpairをやりとりしてる場合はそれじゃ済まないのが問題っちゃ問題かな。
#あと、リスト操作プリミティブへと展開するマクロがある場合 (e.g. hygienicなmatchライブラリ)、たとえR6RSであっても、そのマクロのlibraryがsrfi-101をimportしてくれない限り、透過な置き換えはできないと思う。(クライアントサイドだけで混ぜて使うことはできない)
#そういえばそうですね > hygienic macro
#SRFI-101 で Implementations are encouraged, but not required, to support random-access pairs and lists as their primary pair and list representation. って言ってるのもそのあたりのからみでしょうか
#でもそこまでやってしまうと PLT Scheme の mcons, mcar, mcdr の世界になってしまうという
#この問題はmodularityの観点からはちょっとおもしろいな。hygienicな仕様は本来、「クライアントサイドでたとえプリミティブを置き換えてても、マクロ実装には一切影響が出ない」ということをメリットとしていたわけだ。
#でも今回のような場合、逆に影響を与えちゃいたい、他の人が見ている抽象化層の下の部分を置き換えちゃいたい、ってわけだ。
#デザインパターンで言う、 Template Method ができませんね
#うん。matchマクロについては、「cons, car, cdrといったプロトコルを守ってる操作」であれば使えるはずなのに
#マクロを書いた時点で、「システムの提供する具体的なcons, car, cdr」に実装が縛られちゃう
#こういう、置き換えるレイヤの違う抽象化をうまくサポートすることはできるんだろうか。OO的なディスパッチにしても、レイヤの数は実装時に決まっちゃうから完全に柔軟ではないように思う。
#うーん… cons, car, cdr が総称関数だとどうでしょう？
#e.g. 例えば加算を抽象化するのに、Gaucheでは'+' をgeneric functionにしちゃう方向(上位レイヤでの置き換え)と object-+ にメソッドを追加する方向 (下位レイヤでの置き換え) があるけれど、これらはシステム組み込みなので、あとでさらに下位のレイヤを追加したいとかそういうことができない。
#あーまてよ、最初からすべてが総称関数ならいいのか?
#やっぱりできるだけbindingを遅らせるというSmalltalkerが正しいのかな。
#効率を考えるとちょっと迷うところですね
#むー処理系作者じゃないので細かいトレードオフがわからない
#そこはもう、dynamic recompilationでがんばるとか。新しいメソッドが追加されるたびに最適なコードに置き換わる。
#「新しいメソッドが追加されたgfが最初に呼ばれる時」にrecompileでもいいか。
Gauche > Archives > 2009/09/17