#右肘腱鞘炎
#テニス小僧じゃあるまいに...
#hi
##すんません。これってどういう話
#か教えてくれた人に感謝！
#おそらくshiroさんの独り言でそのあとのnobsunとの話は関係ないと思うのだけど。
#music without music って英語として意味通じるのかなぁ
##pretty printerなんだけど、ちゃんと動くlayoutを書いた後で、srfi-38記法を足そうとした時に、既に出現したオブジェクトの情報を回していかないとならなくなった。
#再帰の自分より下の呼び出しだけに影響を与えるんならひとつ引数を足して持ち回れば楽なんだけど、この場合は影響が自分の呼び出し先だけじゃなくて、おおもとのツリー全体に渡る。
#ハッシュテーブルをひとつ持ち回って破壊的に記録して行く、という手もよく使うんだけど、今回の場合、layoutはリトライがかかる可能性がある (ひとつの部分式に対して、いっぺんコンパクトなレイアウトを試してみてだめだったらよりルーズなレイアウトにする) ので、破壊的手段は使えない。
#そうなると、使えるのは「状態を引数で渡し、更新した状態を多値で返す」という方法。
#で、最初からその方針で書いてるなら良いんだけど、今回は既に動くコードがあってそれに機能をレイヤリングしたかった。なのでいちいちvaluesを足して回ってるうちに不毛な気がしてきたってわけ。
#で、結局state monadを書いちゃった。
#l.48〜58あたりですね
#そう、そこがstate monadの実装で、実際に使ってるのはl.100-180あたり。
#このアイディア(定石?)って、kahua.elemにも応用できそうな気が
#というか、これをやりたくてkahua.elemはああいう作りになっていたんだろうか
#たぶんそうなんじゃないかしらん :)
#ようやくnobsunに追いつくという事実
#しかしppなんかも書かれてて最近またずいぶん活発 > gauche
#0.9が
#出せたので、保留にしてあったところを色々書いてるって感じです。
#あと、あのppはあくまで仮です。formatとかwrite-objectの先まで再帰できないので。extended-replを組み込みにする時までにはGauche組み込みのpretty printerを用意します。
#しばらく以前からshiroさんのコメントがHaskellerになってるという事実:-)
#;; type Layouter = Integer -> (Formatted, Integer)
#とかね。
#それ、もう数年前からだよ。型が複雑になる時にメモ的に書くだけだけど。
#どうせ書くなら処理系が認識してくれれば良いのにとも思う。でも処理系がちゃんと認識してくれる書き方を決めようとするとごちゃごちゃしちゃうんだよなあ (はじめに型システムありきならいいんだけど、Schemeみたいにもともと何でもありな場合はねぇ。)
#C++ とか ActionScript3 とか型が厳格な言語を使っていると型があって便利だなぁと思うんですが、Scheme とか Lua とか型なしの言語を使っていると、型がなくて便利だなぁと思うのはなんででしょう。
#考え方のモードが違う気がする。Schemeは、粘土をこねてる感じ。Haskellは、レゴを組み立ててる感じ。
#昨日勉強会で SICP を読んでいたら、 2.5.2 節に「部品化を維持しつつ、多くの関連する型を扱うのは非常に困難であり、……」というくだりがあって、そのあたりが Scheme に型の入らない遠因なのかと妄想しました
#型についての the Right Thing がまだわからないというか
#最近また Haskell を触り始めて、型システムに感動しつつ、一方で型がうっとうしくなったりしています
Gauche > Archives > 2009/12/03