#Schemeの場合はlambdaで書く方がわかりやすいんじゃないかと個人的には思ってる。
#私もlambdaの方がわかりやすいんですが、Haskellのポイントフリースタイルでも頭の中でlambdaに直さないとわからないので、単に慣れてないだけという可能性も排除できない。まあSchemeだと型のサポートが無いぶんきついってのはあるかも。
#私はむしろ中置記法が相性がいいんじゃないかと思ってるんですよね。
#ポイントフリーに関しては型のサポートがどの程度きいているのか自分ではよく分ってないんで。
#アプリカティブスタイルなんかはまさにそうで f <$> x <*> y <*> zってのはちょっと前置だと見た目が。。。やるならliftM3 f x y zまで持ち込まないといけなくなる。
#アプリカティブスタイルはむしろ中置+静的型のせいで表記がだらだらしてる気がするんだけどなあ。(<$> f x y z) の方がコンパクトじゃない?
#その<$>がまさにliftM3相当ですよね。
#(モナドはこの際関係なしで)
#そう。で、それでいいんじゃないかなと思うんだ、Schemeでは。
#はい、schemeだとその方が分りやすいんですよね。
#でも、これってBとかSのようなプリミティブっぽい部品ではなくて、それを結構合成したものですし、
#そうなると例えば使い勝手の良いライブラリにはliftM2,liftM3...的なものとか、そういうハイレベルAPIになってくるのかな。
#あれ、そうかSchemeの場合にはliftM2,liftM3とかって引数の数によって別途定義する必要ないのか?!
#ああ、なるほど。Schemeではプリミティブなコンビネータを積み重ねてゆくんではなくて、ハイレベルな便利コンビネータをいきなり提供するのがいい、っていう話ならそうだと思う。あと、そう、Schemeなら引数の違いは単一のAPIで吸収できる。
#ですね、やっぱり。検証してないけど直感的に。
#そういう方へAPIが進化することになるかな。
#そうかBとかSをHaskellのBやSだと思う必要はなくて複数引数対応したものだと思えば前置と相性が良くなるはずなのかな。そうなると低レベルか高レベルかはあんまり関係ないかも。
#不定数のパラメータがcomposeを流れるのが面白く感じたので試しに書いてみたコードなのです。たしかにlistを使えばいいのですけど。昨日の「モナド風」とはMaybeモナドのことなんですね。ご教示ありがとうございます。うまい表現はないかなと思っていたのです。(Haskell本は読んだのは読んだのですが身についていません。) pack$とlist-pack$の件ですが、まったくそのとおりです。なるほど。勉強になります。
#関数合成にこだわるのは、要素がパイプラインになっているように見えるからです。(例えばclojureの->や->>は並びも直感と一致しています。)
#昨日からの話を整理してみます。Gaucheでは大量のデータはポートを使うのが正道ということですね。ポートを使うのが標準なのでデータの入り口もポートでないといけない。webからのデータである場合が将来実装されるであろうopen-urlであるということですね。
#ポートをつかった処理の流れをパイプラインのように表すにはどうしたらいいのだろうかと、いま考えています。
#不定数のパラメータがcomposeに流れる件は、素朴にgeneratorを多値に拡張したときにも似たような状況がでてきます。
#(define (my-generate proc)
(define (cont) (reset
(proc (^ arg (shift k (set! cont k) (apply values arg ) )))
(set! cont null-generator)
(eof-object)
))
(^[] (cont)))
#yieldを複数のパラメータにしたらどうなるかと、試しに書いてみたわけですが・・・
#通常は多値が列挙されるけど、終端だけはeof一個という。
#generator wo
#generatorを多値に拡張するのはプランに入っていますが、終端時に返す値の個数が違う、というふうにはしないでしょう。返る値の個数が違うと多値のメリットというのがほとんど殺されてしまうので。
#「モナド風」で意図していたのはMaybeモナドに限定していません。モナドで綺麗に書けそうなパターンであるような気がする、という感覚的なものです。
#もうひとつ、0.9.3から遅延シーケンスが入ったので、ポートではなく遅延シーケンスで大量のデータを持ち回るという手もあります。効率としては ポート=ジェネレータ>遅延シーケンス>>全部文字列、って感じかと。