[過去ﾛｸﾞ] 関数型プログラミング言語Haskell Part16 (978ﾚｽ)
上下前次1-新
抽出解除 ﾚｽ栞
このｽﾚｯﾄﾞは過去ﾛｸﾞ倉庫に格納されています｡
次ｽﾚ検索 歴削→次ｽﾚ 栞削→次ｽﾚ 過去ﾛｸﾞﾒﾆｭｰ
21: デフォルトの名無しさん [sage] 2011/10/08(土) 09:56:34.49 AAS
さて仕切り直すか、雑談は別スレでどうぞ
Haskellを始めたのはいつからですか？
66: デフォルトの名無しさん [sage] 2011/10/10(月) 11:32:08.49 AAS
>>6464(1): デフォルトの名無しさん [sage] 2011/10/10(月) 11:30:58.71 AAS
単純に難しいから流行らない、流行らないから資産が蓄積しない、資産がないので簡易に金儲け用のソフトが書けない、だから実用性がないって言われてるだけじゃ
難しいかどうかって人それぞれなんじゃないの？
俺はCより簡単だと思ってる。
101: デフォルトの名無しさん [sage] 2011/10/12(水) 01:35:49.49 AAS
大学に入学してはどうですか?
141: デフォルトの名無しさん [sage] 2011/10/15(土) 12:33:57.49 AAS
GUI=WEBページ
234(1): デフォルトの名無しさん [sage] 2011/10/22(土) 22:25:23.49 AAS
>>231231(3): デフォルトの名無しさん [sage] 2011/10/22(土) 21:57:41.34 AAS
>>229
既にソースに書いてある。
先頭から見て行かないと判らない、というならそれはHaskellの出来の問題じゃないの？
たとえば [1..3] は 1 : (2 : (3 : [])) であり、
「リストを構成するデータ型」の値だ
そして、 : や [] はこのデータ型の「値構築子」だ（ : は中置値構築子）
last 関数は、last [] = errorEmptyList "last"; last (x:xs) = ・・・
という形のパターンマッチを行う関数だ
last [1..3] は last (1: (2 : (3 : []) なので、
(x:xs) にパターンマッチし、x=1、xs=(2 : (3 : [])) と束縛する
リストに限らず、データ型の値を作ってる値構築子の引数（この場合は 1 や 2 など）は、
このようにパターンマッチさせて値構築子を剥がす事でしか参照できない
で、リスト 1 : (2 : (3 : [])) がこのようなネスト構造を成している以上、
ネスト構造を「順に剥がしていく」ことでしか中の値は参照できない
ちなみに、f (_:_:x:_) = という関数で f [1..3] などとして一気に x=3 と束縛しようとしても、
内部で順に値構築子を剥がす処理をしてパターンにマッチするかを調べるから同じ事
これを 「Haskellの出来」 というのなら、そうだね、としか言いようがない
240: デフォルトの名無しさん [sage] 2011/10/22(土) 23:44:29.49 AAS
>>239239(1): デフォルトの名無しさん [sage] 2011/10/22(土) 23:25:42.57 AAS
>>238
うん？
ghciの話じゃないのか
ghcにO2オプション付ければ積極的に最適化されるから、
last [1..3] = 3
みたいに最適化されてんじゃないの？
少なくとも GHC 7.0.3 ではされません
307(1): デフォルトの名無しさん [sage] 2011/10/28(金) 12:53:34.49 AAS
>>306306(1): 301 [sage] 2011/10/28(金) 09:25:56.34 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だけに制限するのは良い手じゃなさそうです。
> 例えば存在比を(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 的に言えば「抽象の壁」だ
ちなみに、>>304304(2): デフォルトの名無しさん [sage] 2011/10/28(金) 07:47:46.60 AAS
>>301
> Atom型の値の中身をパターンマッチで分解している部分
ここが元凶じゃないかな
Atom型の値の中身をパターンマッチで分解するのなら、
何の為に abbr 関数や abundance 関数を定義したの？
パターンマッチで分解するんじゃなく、
これらの関数を使って中身を取得すべきじゃないの？
パターンマッチだと型の構成を固めちゃうよ
ちなみに、見た目よく似た問題に Expression Problem というのがある
data X = A | B という型をパターンマッチで A B 仕分けしている関数が多くあり、
そこに新たに C という値構築子を追加したいが、修正すべき関数が多くて大変
なんとか楽にしたい、ついでにできれば再コンパイルしたくない
そういう場合なら、たとえばこことか日本語で分かりやすい
外部ﾘﾝｸ:d.hatena.ne.jp
の後半で紹介した Expression Problem は、
少なくとも >>301 から読み取れる問題とは別ものと思われる
（応用できるかどうかは分からないけど）
318(3): デフォルトの名無しさん [sage] 2011/10/29(土) 10:48:25.49 AAS
core言語のパーサーを作ろうとしているのですが、
他にこれは読んでおけ、このページは見ておけというものはありますか？
375: デフォルトの名無しさん [sage] 2011/11/05(土) 21:24:41.49 AAS
[Word8]
393: デフォルトの名無しさん [sage] 2011/11/07(月) 01:24:33.49 AAS
迷ったら付ける
702: デフォルトの名無しさん [sage] 2011/12/13(火) 19:25:07.49 AAS
メモリを圧迫してきたら消したいとかいう要求がない限り
純粋なメモ表はトップレベルに置いとけば素直だし簡単
734(1): デフォルトの名無しさん [sage] 2011/12/18(日) 19:34:16.49 AAS
お前はスレ荒らしたりHaskell勉強は先行投資と言ってみたり
本当にいそがしいな
755(1): 712 [sage] 2011/12/19(月) 18:51:02.49 AAS
>>740740(1): デフォルトの名無しさん [sage] 2011/12/19(月) 03:22:15.55 AAS
これってコマンドプロンプト側の問題じゃなかったっけ・・・
他の言語でも似たようなことになった記憶が
申し訳ないがhaskellでの解決法は知らない
そうですか
私も心が挫けそうで、もう諦め気味です
Windows 標準搭載のコマンドプロンプト以外のコンソールでもダメだったら諦めます
800: デフォルトの名無しさん [sage] 2011/12/23(金) 18:24:52.49 AAS
コードが書いてあるあたりだけでもざっと見ればいいよ
826: デフォルトの名無しさん [sage] 2011/12/24(土) 05:44:34.49 AAS
>>804804(1): デフォルトの名無しさん [sage] 2011/12/23(金) 18:53:48.59 AAS
>>802
色んなものの「共通する性質」や「共通する関係」を抜き出し、
具体的な実態では無くその性質や関係のみで以て語るのが「抽象化」だから、
抽象化するという意味は同じ
どう抽象化するかという点で、IO型からObject型へとMonadへとで違いがでる
Haskell のモナドは (m を Monad クラスのインスタンスとして）
forall a b. m a -> (a -> m b) -> m b
forall a b. m a -> m b -> m b
a -> m a
String -> m a
という４つの「演算で抽象化」してる（うち２つだけで十分だが）
特にモナド同士の演算がまたモナドになるという性質と、
モナドの外からはモナドの具体的な実態は見えないという性質が特徴的だから、
そういう性質が活かせるところでもてはやされる
オブジェクト指向のObject型がどういう性質の抽象化なのかは忘れた
, >>807807(1): デフォルトの名無しさん [sage] 2011/12/23(金) 19:37:49.40 AAS
>>802
その例だと、内部でやってることもだいたい同じ
実際の型に応じて実装が選ばれる
実装を選ぶタイミングがコンパイル時か実行時かは違う
型クラスは ad-hoc polymorphism を使いやすくしたものでオーバーロードの親戚
OOPのほうはsubtype polymorphismといって、部分かなり違う部分がある
例えばsubtype relationが推移律をみたすみたいな強い性質がある
subtypeがあるとどうなるかは、Scalaが壮大な社会実験中
ありがとう。
でも、その理屈でIO()をモナドに抽象できるのだとすると、
「IO()で提供されていた種々の関数は全て、
モナドで提供されている演算子に置き換え可能である」
という前提条件が存在すると思うのだけど、どうだろう？
この条件が成立しないと、結局forallはIO()型の値を必要とするよね。
IO()をMonad m=>mで置き換え可能であるためには、forallを使っている
コードも含めて、IO()型に関連する「全ての関数」のモナド版を
用意してあげなくちゃいけないと思うのだけど。
916: デフォルトの名無しさん [sage] 2011/12/30(金) 17:30:27.49 AAS
むしろ馬鹿ほどmacだと思う
921: デフォルトの名無しさん [sage] 2011/12/31(土) 18:43:32.49 AAS
>>920あ、なるほど dcSetBackgroundMode か
頭文字 s とか b で探してた
（部分一致とかで検索できないと不便だなぁ）
ありがと
952(1): デフォルトの名無しさん [sage] 2012/01/02(月) 12:26:28.49 AAS
モナドは中身はともかく、どう書けるかって話だと確かに関数型捨ててるでしょ。
特にdoを使って書いてると手続き型とほとんど変わらんし、似たようなスパゲティ化もしやすいし。
957: デフォルトの名無しさん [sage] 2012/01/02(月) 13:43:07.49 AAS
クロージャーとかジェネレーターの辺りで完結するべきだった。
最近の関数型はだらだら引き伸ばしているだけ。
上下前次1-新書関写板覧索設栞歴
ｽﾚ情報 赤ﾚｽ抽出 画像ﾚｽ抽出 歴の未読ｽﾚ AAｻﾑﾈｲﾙ
ぬこの手 ぬこTOP 0.051s