[過去ログ] 関数型プログラミング言語Haskell Part16 (978レス)
上下前次1-新
抽出解除 レス栞
このスレッドは過去ログ倉庫に格納されています。
次スレ検索 歴削→次スレ 栞削→次スレ 過去ログメニュー
304(2): デフォルトの名無しさん [sage] 2011/10/28(金) 07:47:46.60 AAS
>>301301(6): デフォルトの名無しさん [sage] 2011/10/28(金) 02:56:26.22 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型の値の中身をパターンマッチで分解している部分は全て書き直さなければならなくなります。
変更に弱いから、手探りでコーディングをしているときはパターンマッチによる分解は使うべきじゃない、ということで良いのでしょうか。
> Atom型の値の中身をパターンマッチで分解している部分
ここが元凶じゃないかな
Atom型の値の中身をパターンマッチで分解するのなら、
何の為に abbr 関数や abundance 関数を定義したの?
パターンマッチで分解するんじゃなく、
これらの関数を使って中身を取得すべきじゃないの?
パターンマッチだと型の構成を固めちゃうよ
ちなみに、見た目よく似た問題に Expression Problem というのがある
data X = A | B という型をパターンマッチで A B 仕分けしている関数が多くあり、
そこに新たに C という値構築子を追加したいが、修正すべき関数が多くて大変
なんとか楽にしたい、ついでにできれば再コンパイルしたくない
そういう場合なら、たとえばこことか日本語で分かりやすい
外部リンク:d.hatena.ne.jp
306(1): 301 [sage] 2011/10/28(金) 09:25:56.34 AAS
>>302302(2): デフォルトの名無しさん [sage] 2011/10/28(金) 03:18:36.06 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パターンと組み合わせることものできるから、かなりの柔軟性が確保できるはず。
すいません、パターンマッチでの分解に、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): デフォルトの名無しさん [sage] 2011/10/28(金) 12:53:34.49 AAS
>>306
> 例えば存在比を(Int,Double)のリストで表すよりもData.Mapで表す方がベターだと思った場合
そういう場合は、Data.Map 型を使ったコンテナに対するアクセス関数を公開して、
そのコンテナ内部で Data.Map 型を使っていることは隠蔽しておく
>>305305(1): デフォルトの名無しさん [sage] 2011/10/28(金) 08:16:42.39 AAS
>>301
普通はデータ構築子をmodule外に非公開にすることで
内部構造を隠匿する
よくあるOOP言語ではclassが抽象データ型の単位だけど
Haskellだとmoduleになる
も同じ様なことをアドバイスしている
こうやって、データとそのユーザとの間にインターフェースを設けるのは、
Haskell に限らず、まず間違いなく全ての言語で共通する考え方
CICP 的に言えば「抽象の壁」だ
ちなみに、>>304 の後半で紹介した Expression Problem は、
少なくとも >>301 から読み取れる問題とは別ものと思われる
(応用できるかどうかは分からないけど)
上下前次1-新書関写板覧索設栞歴
スレ情報 赤レス抽出 画像レス抽出 歴の未読スレ AAサムネイル
ぬこの手 ぬこTOP 0.039s