[過去ﾛｸﾞ]
関数型プログラミング言語Haskell Part16 (978ﾚｽ)
関数型プログラミング言語Haskell Part16 http://echo.5ch.net/test/read.cgi/tech/1317958045/
上
下
前次
1-
新
通常表示
512ﾊﾞｲﾄ分割
ﾚｽ栞
抽出解除
ﾚｽ栞
このｽﾚｯﾄﾞは過去ﾛｸﾞ倉庫に格納されています｡
次ｽﾚ検索
歴削→次ｽﾚ
栞削→次ｽﾚ
過去ﾛｸﾞﾒﾆｭｰ
304: デフォルトの名無しさん [sage] 2011/10/28(金) 07:47:46.60 >>301 > Atom型の値の中身をパターンマッチで分解している部分 ここが元凶じゃないかな Atom型の値の中身をパターンマッチで分解するのなら、 何の為に abbr 関数や abundance 関数を定義したの？ パターンマッチで分解するんじゃなく、 これらの関数を使って中身を取得すべきじゃないの？ パターンマッチだと型の構成を固めちゃうよ ちなみに、見た目よく似た問題に Expression Problem というのがある data X = A | B という型をパターンマッチで A B 仕分けしている関数が多くあり、 そこに新たに C という値構築子を追加したいが、修正すべき関数が多くて大変 なんとか楽にしたい、ついでにできれば再コンパイルしたくない そういう場合なら、たとえばこことか日本語で分かりやすい http://d.hatena.ne.jp/maoe/20101214/1292337923 http://echo.5ch.net/test/read.cgi/tech/1317958045/304
306: 301 [sage] 2011/10/28(金) 09:25:56.34 >>302すいません、パターンマッチでの分解に、record syntaxを含めていませんでした。 haskellの入門書などではdata X = MkX Int Double Charなどとしておいて、 f (X i d c) = ...と記述することが「できる」とあったのですが、これって便利なのか？と疑問に思ったのです。 >>304確かにアクセッサ関数を定義しているので、型に何かを追加する可能性がある場合は 柔軟性を保てるのですが、例えば存在比を(Int,Double)のリストで表すよりもData.Mapで表す方がベターだと思った場合、 やっぱり変更先が多くなりそうになって嫌だなあと思った次第でして。 >>304のリンク先の方法がスマートに見えるので試してみたいと思います。 最終的には原子に限らず、平均値と分布を出せるようになりたいので、averageやspectrumをAtomだけに制限するのは良い手じゃなさそうです。 http://echo.5ch.net/test/read.cgi/tech/1317958045/306
307: デフォルトの名無しさん [sage] 2011/10/28(金) 12:53:34.49 >>306 > 例えば存在比を(Int,Double)のリストで表すよりもData.Mapで表す方がベターだと思った場合 そういう場合は、Data.Map 型を使ったコンテナに対するアクセス関数を公開して、 そのコンテナ内部で Data.Map 型を使っていることは隠蔽しておく >>305 も同じ様なことをアドバイスしている こうやって、データとそのユーザとの間にインターフェースを設けるのは、 Haskell に限らず、まず間違いなく全ての言語で共通する考え方 CICP 的に言えば「抽象の壁」だ ちなみに、>>304 の後半で紹介した Expression Problem は、 少なくとも >>301 から読み取れる問題とは別ものと思われる （応用できるかどうかは分からないけど） http://echo.5ch.net/test/read.cgi/tech/1317958045/307
ﾒﾓ帳
(0/65535文字)
上
下
前次
1-
新
書
関
写
板
覧
索
設
栞
歴
ｽﾚ情報
赤ﾚｽ抽出
画像ﾚｽ抽出
歴の未読ｽﾚ
Google検索
Wikipedia
ぬこの手
ぬこTOP
0.031s