08/02/17 00:07:34
参照透明性ってデバッグの容易さの点で重要と聞いてるけど。
825:799
08/02/17 00:08:33
>>814
う～ん…。これは正しいのでしょうか？
あくまでも、Haskellは参照透明であって、
そうでないプログラムは邪悪という事ですよね。
826:デフォルトの名無しさん
08/02/17 00:11:43
>>823
参照透明だったら関数の返値をキャッシュできるよ
827:799
08/02/17 00:14:55
>>826
コンパイラの話ですよね…。
828:799
08/02/17 00:16:41
>>824
Haskellのデバッグってむしろ大変そうですけど…。
829:デフォルトの名無しさん
08/02/17 00:18:15
>>827
完全にキャッシュできればプログラマはわざわざメモ化とかのテクニックを使ってプログラミングする必要がなくなる。
・・・とは言うものの、GHCでは完全にキャッシュしているわけではない。
830:デフォルトの名無しさん
08/02/17 00:19:45
>>828
Cのデバッグで一番骨が折れるのが型によるバグ。
Haskellはコンパイルさえ通れば型に関しては完全に矛盾がない。
831:デフォルトの名無しさん
08/02/17 00:20:48
>>823
だから、参照透明性はそんなに重大な特徴じゃないんだって
（利点が無いわけじゃない。コンパイラによる最適化がやりやすい。コードが読みやすい。リファクタリングしやすいetc）
逆に、「参照透明でないこと」(破壊的代入や副作用を認める)にも大して優位性は無いんだ
Haskellにはもっと重要な特徴がたくさんある
動作オブジェクトを利用した入出力とか、代数的データ型＋パターン照合とか、型クラスとか、遅延評価とか
832:797
08/02/17 00:25:59
>>830
Haskell の型はステキだと思いますよw
でも、traceとか「デバッグ」は大変そう…。
833:デフォルトの名無しさん
08/02/17 00:29:07
>>831
>参照透明性はそんなに重大な特徴じゃない
そうですよね…。
でも、なんか、かたくなに参照透明性を守ろうとして
余計わかり難くなってる気がするんですよね。
全面的な参照透明性を捨てた方が、
すっきりするのではないでしょうか…？
834:799
08/02/17 00:29:52
↑>>833 は 799です
835:デフォルトの名無しさん
08/02/17 00:30:17
第15回 Haskellでのデバッグのコツをつかむ
URLﾘﾝｸ(itpro.nikkeibp.co.jp)
836:デフォルトの名無しさん
08/02/17 00:30:34
traceってどういうのを指してるか分からんけど、printfデバッグの類は普通にできる
ただ、HaskellがCよりデバッグしにくいのは事実だと思う
gdbに匹敵する使いやすさのデバッガがまだ無いからだが
>>833
>でも、なんか、かたくなに参照透明性を守ろうとして
>余計わかり難くなってる気がするんですよね。
どの辺でそう感じた？
837:799
08/02/17 00:31:00
ああっ！
>>832 も799です。
838:799
08/02/17 00:35:00
>>836
> printfデバッグの類は普通にできる
そうなんですか？
なんかprintfいれるとバグが再現しないとか多そうですが…。
> どの辺でそう感じた？
IOモナドww
参照透明性を捨てれば
もっとステキな実装がありそうじゃないですか？
839:デフォルトの名無しさん
08/02/17 00:38:46
参照透明性を確保するために導入したんだから
本末転倒だじょ
840:デフォルトの名無しさん
08/02/17 00:41:05
俺はIOモナド大好きなのでその気持ちは良く分からん
例え参照透明性を捨ててもIOモナドは使いたい
841:799
08/02/17 00:41:50
>>839
ん？
いや、だから、参照透明性に固執するから、
IOモナドなんて理解しにくい方法で実装してるんでしょ？
842:デフォルトの名無しさん
08/02/17 00:43:33
参照透明性を実現する完全に純粋な関数型言語を作るのが
Haskell の１つの目標だったんじゃないのか？
843:デフォルトの名無しさん
08/02/17 00:50:41
IOモナド、というかIO動作の考え方は多少とっつきにくいけど、分かってしまえば簡単なことだし、
副作用を使った入出力よりずっとまともだと思う
それから、遅延評価の言語で素朴に副作用を使うと実行順が制御困難になるけど、
IO動作ならこの問題がない
>>842
だろうな
でも言語のユーザーにとってはそんな目標はどうでも良い
844:デフォルトの名無しさん
08/02/17 00:51:38
参照透明性が要らないというなら OCaml とか他の言語使えばいい。
それだけだと思うぜ。
845:デフォルトの名無しさん
08/02/17 01:00:20
>>844
その議論はおかしい
Haskellの特徴は参照透明性だけじゃない
デフォルトの遅延評価も型クラスもIOモナドも$演算子もOCamlには無い
参照透明性なんてどうでも良いという奴にでも、Haskellを使う理由はいくらでもある
846:デフォルトの名無しさん
08/02/17 01:09:14
じゃあ、参照透明性の無いHaskell に相当する言語を作ったらいいんじゃね。
847:799
08/02/17 01:12:57
>>840
そうなんですか…。
結局、慣れの問題なんでしょうかねぇ…。
848:デフォルトの名無しさん
08/02/17 01:15:01
Haskell では参照透明性をくずすものは trace のみなんだっけ？
849:799
08/02/17 01:15:23
>>846
まさに、そう、思うんですよw
そんな言語があれば、
確実にブレイクするのではないでしょうか？
誰か作って！私はもちろん……ﾑﾘ!
850:デフォルトの名無しさん
08/02/17 01:26:25
>>848
unsafePerformIOってのがある
>>849
単に参照透明性のないHaskellならunsafePerformIOを言語の一部として認めれば良いんだけど、
IOモナドを排除するのは難しいと思う
>>843で書いたけど、普通の言語にあるような副作用による入出力は、遅延評価と相性が悪い
実行順を分かり易く制御するには、結局、IOモナドか、Cleanの一意型か、
それに代わる何か新しいメカニズムが必要になる
851:799
08/02/17 01:39:54
>>850
な～るほど！
ひょっとしてunsafePerformIOを使いまくって
>>814 の言う邪悪なIOライブラリを作れば、
Haskellのままでもいいかもしれませんねw
852:デフォルトの名無しさん
08/02/17 01:41:59
もう屁みたいな例をたくさんあげられるのはウンザリだよ。
こうしよう、C（ほかの言語でもいい）からHaskellに乗り換えるために十分な
説得力を持つ実務的な例を１つだけあげてくれ。
853:デフォルトの名無しさん
08/02/17 01:55:30
darcs
854:799
08/02/17 01:55:42
>>852
「実務的」というかどうかはしらないけど、
コンパイラ的な処理には向いてるらしい…。
再帰下降構文解析
URLﾘﾝｸ(ja.wikipedia.org)
HaskellやMLなどの関数型言語での再帰下降構文解析の実装は特に簡単である。
出典: フリー百科事典『ウィキペディア（Wikipedia）』
855:デフォルトの名無しさん
08/02/17 02:00:39
> HaskellやMLなどの関数型言語での再帰下降構文解析の実装は特に簡単である。
っていうのはウソっていうのはどっかでみたなｗ
856:デフォルトの名無しさん
08/02/17 02:06:37
>>854
実際、言語処理系には向いてる。
構文解析だけじゃなく、コンパイル過程での構文木の操作とかに
代数的データ型とパターンマッチがぴったりハマってかなり綺麗に書ける
（MLも同様。代数的データ型じゃなくてバリアントという名前だけど）。
言語処理系は、基本的にツリーの変形みたいな
I/Oを伴わない数学的な処理が多いから、という理由づけもできるかな。
857:799
08/02/17 02:08:10
Haskellというか、関数型言語の魅力としては、
>>803 のリンク先を読めばかなり納得できると思う。
858:デフォルトの名無しさん
08/02/17 02:16:57
>>848
いいえ
859:デフォルトの名無しさん
08/02/17 02:23:46
Haskellの言語仕様にunsafeとかFFIとかってあったっけ？
GHCの仕様じゃないの
860:デフォルトの名無しさん
08/02/17 02:27:47
>>859
FFIはHaskell 98への追補
URLﾘﾝｸ(www.cse.unsw.edu.au)
unsafePerformIOも入ってる
861:デフォルトの名無しさん
08/02/17 02:29:45
じゃあ、Haskellは純潔を失ったというわけだ
862:デフォルトの名無しさん
08/02/17 08:36:34
ハードリアルタイムアプリはHaskellでは無理
863:デフォルトの名無しさん
08/02/17 09:30:28
実時間要求とメモリを直接利用するアプリケーション以外はHaskellでおｋ
864:デフォルトの名無しさん
08/02/17 11:58:51
>>863
できるだろ
URLﾘﾝｸ(www.haskell.org)
865:デフォルトの名無しさん
08/02/17 12:01:27
仮想メモリとかOS必須じゃｎ
866:デフォルトの名無しさん
08/02/17 18:47:44
Haskell (International Computer Science Series) (ペーパーバック)
Simon Thompson (著)
# ペーパーバック: 528ページ
# 出版社: Addison Wesley; 3Rev Ed版 (2008/9/15)
# 言語 英語, 英語, 英語
# ISBN-10: 0201882957
# ISBN-13: 978-0201882957
# 発売日： 2008/9/15
今度こそ発売?
867:デフォルトの名無しさん
08/02/18 18:08:34
参照透明性を保証しないと、グラフ簡約が使えなくね？
868:デフォルトの名無しさん
08/02/18 18:18:32
使えなくはないと思うが、何で？
869:デフォルトの名無しさん
08/02/18 20:15:31
>>642
データ構造とアルゴリズムをまとめるだけなら、それこそ関数型言語の得意分野だし、
手続き型の世界でも、メッセージメタファって何それ、なgeneric programmingが幅を利かせている。
その分なおさら、状態と手続きをまとめるSmalltalk的なオブジェクト指向が
影響力を増しているように思う。
>>654のAlan Kayの言葉は、実行順序への依存性が下がること
(これはメッセージメタファ、イベント駆動から自然に出てくる)と、
参照透明という意味で状態を全く持たないことを(故意に？)混同している。
870:デフォルトの名無しさん
08/02/19 02:47:18
ハードウェアリアルタイム処理って言葉にすれば
Haskellはかなりいけそうな感触なんだけどなぁ
871:デフォルトの名無しさん
08/02/19 10:02:24
>>868
形式的な表現が同じでも、値が同じことの保証がなくなるから。
872:デフォルトの名無しさん
08/02/19 10:36:55
>>871
副作用を入れるなら当然それは覚悟の上じゃないのか
873:デフォルトの名無しさん
08/02/19 12:45:42
>>872
副作用を入れてもいいのは、値がユニット型の関数だけにしないと破綻するだろ。
874:デフォルトの名無しさん
08/03/09 07:06:26
↓この暗号が解けたら初心者卒業と言えるでしょうか？
main = getArgs >>= putStr . flip id "\n" . foldr (.) id . map (showHex . read)
URLﾘﾝｸ(haskell.g.hatena.ne.jp) を少し改変
875:デフォルトの名無しさん
08/03/09 10:02:11
>>874
暗号に見えていたのが、何の変哲もないプログラムとして認識できるようになったら卒業だな。
876:874
08/03/09 19:04:29
>>875
そうですか…
1日がかりで解けたので初心者卒業かと思ったのですが…orz
何の変哲もないプログラムに見えるように精進しますw
877:デフォルトの名無しさん
08/03/09 23:43:38
何の変哲もないように見える必要はないと思うが解くのに１日がかりはまだ初級者の域か。
878:デフォルトの名無しさん
08/03/13 21:20:39
悩むところが見当たらん
おれはもうだめだ
879:デフォルトの名無しさん
08/03/13 21:26:04
flip id "\n"が悩むところじゃないか？
なぜ($"\n")と書かないんだろう
880:デフォルトの名無しさん
08/03/14 13:47:26
Prelude> ($ "789") $ ($ (($ "456") $ ($ "123") $ (++))) $ (++)
"123456789"
スタックマシンみたいだ(w
881:デフォルトの名無しさん
08/03/18 18:48:31
便利だなこれ
\a -> hoge a 4 ()
flip (flip hoge 4) ()
($ ()) . ($ 4) . hoge
882:デフォルトの名無しさん
08/03/19 16:27:19
>>881
ああ、そうやってカリー化できるんだ。目から鱗が落ちたよ。
883:デフォルトの名無しさん
08/04/12 21:48:42
引く手あまたのプログラミング言語は?
URLﾘﾝｸ(slashdot.jp)
---
Java(16479件)、C++(8080件)、C#(7780件)、JavaScript(6749件)、
Perl(5710件)、PHP(2641件)、Python(1408件)、COBOL(1207件)、
Ruby(769件)、Lisp(33件)といった感じらしい。
とりあえずJavaとC/C++/C#、あとJavaScriptを覚えれば、
当分仕事には困らないようである。COBOLのしぶとさも目立つ。
ちなみにHaskellやOCamlの求人は10以下だったそうだ。
---
884:デフォルトの名無しさん
08/04/19 00:45:19
仕事でプログラムやってるやつなんて
この板にいるの？
885:デフォルトの名無しさん
08/04/19 01:39:26
ええっ？ほとんどプログラム関連の人じゃないの？
886:デフォルトの名無しさん
08/04/19 01:41:22
プログラム関連の研究を仕事でやってる人はいるかもしれないが
887:デフォルトの名無しさん
08/04/24 00:13:42
この「板」にはいくらでもいるだろう＞仕事でプログラムやってるやつ
このスレに限れば、仕事と直で結びつきにくい言語かもしらんけど
でも仕事でプログラムやる傍ら、趣味や素養のためにHaskell弄ってる奴も珍しくはないんじゃなかろうか
888:デフォルトの名無しさん
08/05/03 18:08:15
俺は研究職だが仕事でHaskell使ってる。
889:デフォルトの名無しさん
08/05/25 22:21:03
はじめましてAranskファンクラブです。
皆さんはAranskをご存知でしょうか？
最近ネット社会において急速に発言力を増しつつある
集団です。
本家：URLﾘﾝｸ(homepage3.nifty.com)
ミラーサイト：URLﾘﾝｸ(www.geocities.jp)
日本語Blog:URLﾘﾝｸ(aransk.cocolog-nifty.com)
英語もどきBlog：URLﾘﾝｸ(d.hatena.ne.jp)ここまでがAransk Officialsです。
（上記以外にも２ちゃんねるのプログラム板にAransk専用スレが
立っていますが、これはAranskとは何のつながりもありません。）
上記の２ちゃんねる、yahoo掲示板に精力的に意見を
書き込むと同時に自らのサイトの更新も頻繁に
行っています。
驚いたことに、あらゆる場所で人気が「ありません。」
その人気の無さをこのBlogで究明してみるつもりです。
ご興味ある方は是非ご参加下さい。
890:デフォルトの名無しさん
08/05/25 22:30:18
\yってｙを含まないって意味だっけ？
891:デフォルトの名無しさん
08/05/25 23:10:13
Haskellの\はlambda
\y -> e で、yからeへの関数
892:デフォルトの名無しさん
08/06/05 18:49:53
逆ポーランド記法で日本人に優しいとか言ってみるRPHaskellとか作って
893:デフォルトの名無しさん
08/07/21 10:56:30
「初心者のためのプログラミング言語ガイド」スレに
Haskellを狂信的に勧めるやつが現れてスレがめちゃくちゃに。
894:デフォルトの名無しさん
08/07/21 19:56:00
>>893
信者と信者っぽく振る舞ってネタにしてる奴と2種類いるようだな。
895:デフォルトの名無しさん
08/09/12 21:26:02
Haskellの入門書は、ふつうのHaskellプログラミングでおｋ？
896:デフォルトの名無しさん
08/09/12 21:30:22
>>895
WEBが一番
ここが一番わかりやすいぞ
URLﾘﾝｸ(www.sampou.org)
897:デフォルトの名無しさん
08/09/12 23:45:22
>>896
マジか。本買おうかずっと迷ってたんだ。サンクス。これでやってみるよ。
LL Futureで見たんだけどHaskellって並列プログラミングの強さはどんなもんでしょう？
URLﾘﾝｸ(www.nicovideo.jp)
898:36 ◆K0BqlCB3.k
08/09/13 00:50:59
>>897
現在開発中で一部は使用可能
URLﾘﾝｸ(hackage.haskell.org)
899:デフォルトの名無しさん
08/09/13 02:18:36
Erlangにすればいいんでない?
900:デフォルトの名無しさん
08/09/17 01:21:22
>>897
本の方がわかりやすいと思うがWebの方を読んで理解できるレベルなら
それでいいと思う。お金かかんないし。