[過去ﾛｸﾞ] 関数型プログラミング言語Haskell Part16 (978ﾚｽ)
上下前次1-新
このｽﾚｯﾄﾞは過去ﾛｸﾞ倉庫に格納されています｡
次ｽﾚ検索 歴削→次ｽﾚ 栞削→次ｽﾚ 過去ﾛｸﾞﾒﾆｭｰ
292: 2011/10/27(木)13:00 AAS
>>290
それより「発想」ってのが何かのトラウマのスイッチを押してしまったらしいよ
293(2): 2011/10/27(木)13:01 AAS
関数型言語がいつまでもキチガイ誘蛾灯みたいなポジションなのも困るね
294(1): 2011/10/27(木)13:04 AAS
電球の外に群がる事があっても、電球の中にまでは入ってこられまい。
295(1): 2011/10/27(木)13:17 AAS
大発見の相手してやんないと拗ねる奴ってどこの板にもいるけど
全部一緒なんじゃなかろうな
296: 2011/10/27(木)13:36 AAS
>>293
X: 関数型言語がいつまでもキチガイ誘蛾灯みたいなポジションなのも困るね
O: ハスケルがいつまでもキチガイ誘蛾灯みたいなポジションなのも困るね
297: 2011/10/27(木)19:14 AAS
>>293-294
文学はいいので工学の話してください
298(1): 2011/10/27(木)23:19 AAS
フーリエ変換への変なアプローチなら、できるかどうかは別としてありそうではあるけど。
299: 2011/10/27(木)23:47 AAS
>>298
「できない」アプローチが「ある」っていう概念が理解できないから説明してくれろ
300: 2011/10/28(金)00:14 AAS
>>295
＞全部一緒なんじゃなかろうな
284〜296まで一人で自演乙
でも、こんな過疎スレで一時間ちょいで十レス以上とか、
もうちょっとリアリティってヤツを考えたほうがいいね。
301(6): 2011/10/28(金)02:56 AAS
Haskellでプロトタイピングをするとき、ここから作ってく、こうやって作っておけば後からの変更に強い、
みたいな作法って持ってます？
ある組成式を受けとったら、その分子の平均質量とかマススペクトルとかを返してくれるような
プログラムを書いてみようかと思ったんだけど、まず基本となる原子のデータ型から作っていって、
data Atom = Atom { abbr::Char, abundance::Distributions }
type Distributions = [(Int,Double)]
とか定義しておいて、average :: Atom -> Doubleやspectrum :: Atom -> (Int -> Double)
みたいな関数を作り、組成式はtype Molecule = [(Atom,Int)]としてみようか、と考えています。
で、Atomを拡張してname::Stringみたいな値も格納しておこうか、と思いついたとき、
Atom型の値の中身をパターンマッチで分解している部分は全て書き直さなければならなくなります。
変更に弱いから、手探りでコーディングをしているときはパターンマッチによる分解は使うべきじゃない、ということで良いのでしょうか。
302(2): 2011/10/28(金)03:18 AAS
>>301
とりあえず、その個別の問題に対しては、
data T1 = T1 { c :: Char }
data T2 = T2 { d :: Char, s :: String}
f T1{c = 'a' } = "c is 'a'"
f T1{c = c } = "c is not 'a': " ++ show c
g T2{d = 'a' } = "d is 'a'"
g T2{d = d } = "d is not 'a': " ++ show d
以上のパターンを用いることによって対処できる
さらに、
h t2@T2{d = 'b' } = t2{d = 'c', s ="foo" }
のようにasパターンと組み合わせることものできるから、かなりの柔軟性が確保できるはず。
303: 302 2011/10/28(金)03:20 AAS
ごめん。捕捉。
T1とT2は、別の型というよりも、変更前の型と変更後の型をシミュレートしていると考えて。
だから、このコードではcとdは別の識別子だけど、変更前と変更後で同じ識別子にすることができる。
304(2): 2011/10/28(金)07:47 AAS
>>301
> Atom型の値の中身をパターンマッチで分解している部分
ここが元凶じゃないかな
Atom型の値の中身をパターンマッチで分解するのなら、
何の為に abbr 関数や abundance 関数を定義したの？
パターンマッチで分解するんじゃなく、
これらの関数を使って中身を取得すべきじゃないの？
パターンマッチだと型の構成を固めちゃうよ
ちなみに、見た目よく似た問題に Expression Problem というのがある
data X = A | B という型をパターンマッチで A B 仕分けしている関数が多くあり、
そこに新たに C という値構築子を追加したいが、修正すべき関数が多くて大変
なんとか楽にしたい、ついでにできれば再コンパイルしたくない
そういう場合なら、たとえばこことか日本語で分かりやすい
外部ﾘﾝｸ:d.hatena.ne.jp
305(1): 2011/10/28(金)08:16 AAS
>>301
普通はデータ構築子をmodule外に非公開にすることで
内部構造を隠匿する
よくあるOOP言語ではclassが抽象データ型の単位だけど
Haskellだとmoduleになる
306(1): 301 2011/10/28(金)09:25 AAS
>>302すいません、パターンマッチでの分解に、record syntaxを含めていませんでした。
haskellの入門書などではdata X = MkX Int Double Charなどとしておいて、
f (X i d c) = ...と記述することが「できる」とあったのですが、これって便利なのか？と疑問に思ったのです。
>>304確かにアクセッサ関数を定義しているので、型に何かを追加する可能性がある場合は
柔軟性を保てるのですが、例えば存在比を(Int,Double)のリストで表すよりもData.Mapで表す方がベターだと思った場合、
やっぱり変更先が多くなりそうになって嫌だなあと思った次第でして。
>>304のリンク先の方法がスマートに見えるので試してみたいと思います。
最終的には原子に限らず、平均値と分布を出せるようになりたいので、averageやspectrumをAtomだけに制限するのは良い手じゃなさそうです。
307(1): 2011/10/28(金)12:53 AAS
>>306
> 例えば存在比を(Int,Double)のリストで表すよりもData.Mapで表す方がベターだと思った場合
そういう場合は、Data.Map 型を使ったコンテナに対するアクセス関数を公開して、
そのコンテナ内部で Data.Map 型を使っていることは隠蔽しておく
>>305 も同じ様なことをアドバイスしている
こうやって、データとそのユーザとの間にインターフェースを設けるのは、
Haskell に限らず、まず間違いなく全ての言語で共通する考え方
CICP 的に言えば「抽象の壁」だ
ちなみに、>>304 の後半で紹介した Expression Problem は、
少なくとも >>301 から読み取れる問題とは別ものと思われる
（応用できるかどうかは分からないけど）
308: 2011/10/28(金)12:54 AAS
>>307
すまん
誤) CICP 的に言えば
正) SICP 的に言えば
309(1): 2011/10/28(金)18:25 AAS
ようやく少しモナドの感覚がつかめた。あれって世界を分けてて、その世界の中
で作業をしていくための工夫という感じだな。ってね。安全な作業をするには必
要なんだってのもようやくわかった。
同時に感覚的なイメージでモナドを上手に例えて伝えるようなものがあまりない
のかもとも思ったかな。水中で普通のデジカメで撮影をするには防水ケースの中
に入れて使うけど、あの防水ケースっぽい働きなんだなってね。そんなアナロジー
を想像してしまったかな。
310(1): 2011/10/28(金)19:10 AAS
>>309
> 同時に感覚的なイメージでモナドを上手に例えて伝えるようなものがあまりない
> のかもとも思ったかな。
確かにね
hage :: [Int]
hage = do
x <- [1..5]
when (x == 3) (fail "discard")
return x
こういうのだと、どの世界とどの世界に分けてるのか曖昧だし
明確に分けられたとしても、その世界に何かを閉じ込めているのとも違う気がする
311(1): 2011/10/28(金)20:14 AAS
リストモナド自体が分岐した世界を表現してるからな
312: 2011/10/28(金)20:59 AAS
>>311
いや、たがら、そのリストモナドが分けた２つの世界は何と何か
という辺りが自分では上手く説明できないなぁと
313(1): 2011/10/28(金)21:06 AAS
do内の世界はdoの流儀に従ってる。だけど、do外の世界はdo内のことには
結果を渡される以外無関係ってと事だろう？
314: 2011/10/28(金)21:31 AAS
do ってただの糖衣構文じゃん、世界の構成要素ではないでしょ
>>310 のは実質これ
hage :: [Int]
hage = [1..5] >>= \x -> when (x == 3) (fail "discard") >> return x
>>313 の言う流儀というのは、結局
Monad クラスのインスタンスの定義方法、だよね
（>>= 関数をどう定義するか、return 関数をどう定義するか、など）
でもそれは、たとえばアローでも同じ事が言えて、
proc do内の世界はproc doの流儀に従ってる・・・
つまり Arrow クラスのインスタンスの定義方法がその流儀となる
じゃあ、アローもモナドと同じように、世界を２つに分けているのかな
分けているのなら、モナドが分ける世界とアローが分ける世界は何が違う？
そこまで考えて初めて、モナドが何をどう分けているのか、
ということの理解に繋がると思う
315: 2011/10/28(金)21:46 AAS
むしろ分けてるんじゃなくて繋げてる
316: 2011/10/28(金)21:47 AAS
床下配線
317: 2011/10/29(土)00:06 AAS
いろんな意見ありがとうございます。アローのことはそもそも知らないくらい
なので、また探ってみたい。やっと面白いと思うことが増えてきた感じです。
arrowのことは他の理解を終えてから取っかかるよ。
実はRWHをようやく半分まで消化したところ
318(3): 2011/10/29(土)10:48 AAS
core言語のパーサーを作ろうとしているのですが、
他にこれは読んでおけ、このページは見ておけというものはありますか？
319: 318 2011/10/29(土)10:50 AAS
>>318
書き忘れていました
今は Haskell Platform 内のドキュメントを読んでいます
320(1): 2011/10/29(土)11:06 AAS
>>318
Haskell Report
321: 2011/10/29(土)12:31 AAS
>>320
ありがとうございます
そうですね、元の Haskell の仕様を読んでおくのは当然ですね
熟読します
上下前次1-新書関写板覧索設栞歴
あと 657 ﾚｽあります
ｽﾚ情報 赤ﾚｽ抽出 画像ﾚｽ抽出 歴の未読ｽﾚ
ぬこの手 ぬこTOP 0.011s