関数型プログラミング言語Haskell

>695
東工大のhaskellの授業です。講義のページにも下の方に演習がありますよ

http://www.brl.ntt.co.jp/people/mizuhito/CS/

↑の12月13日のところの上級問題が解けたら凄いですね

解けない・・・

どもです。>>696-697

age

[上級問題１]（これができれば単位は差し上げます）
maximum segment sum 問題(mss)は実は線形時間アルゴリズムが存在する。その
アルゴリズムを実装し、なぜ線形時間であるか理由をしるせ。

mss :: [Int] -> Int
mss = maximum . mss' 0
where
mss' n [] = [n]
mss' n (x:xs)
| n + x < 0 = n : mss' 0 xs
| x < 0 = n : mss' (n+x) xs
| otherwise = mss' (n+x) xs

線形時間であるのは自明ってことで許して。

mss [-1,-4,-5] => 0

間違ってるやん…
出直してきます…

そもそも mss [] が 0 でいいものなのか…

宿題解かせようとしてる東工大生の陰謀に引っかかるなよ。（ﾜﾗ

mss :: [Int] -> Int
mss [] = error "mss []"
mss xs = case maximum $ mss' 0 xs of
0 -> maximum xs
n -> n
where
mss' n [] = [n]
mss' n (x:xs)
| n + x < 0 = n : mss' 0 xs
| x < 0 = n : mss' (n+x) xs
| otherwise = mss' (n+x) xs

この問題の事か・・・
たしかに線形性ってのは述べにくいよね


maximum segment sum 問題(mss)は、整数列（正とは限らない）を入力とし、その
連続する部分列で和が最大となるものをみつけて、その和を出力とする。
たとえば [2,-3,2,-1,2,3,-5,8,-9,1] の場合 [2,-1,2,3,-5,8] の和 9 が出力で
ある。このプログラムを作成せよ。

[上級問題１]
maximum segment sum 問題(mss)は実は線形時間アルゴリズムが存在する。その
アルゴリズムを実装し、なぜ線形時間であるか理由をしるせ。

[上級問題２]
2-maximum segment sum 問題(2-mss)は、整数列（正とは限らない）を入力とし、その
重なりのない高々二つの連続する部分列で、それぞれの和の和が最大となるものを
みつけて、その和を出力とする。
たとえば [2,-3,2,-1,2,3,-5,8,-9,1] の場合 [2,-1,2,3] と [8] の和 14 が出力で
ある。このプログラムを作成せよ。

[上級問題３]
2-maximum segment sum 問題(2-mss)は実は線形時間アルゴリズムが存在する。その
アルゴリズムを実装し、なぜ線形時間であるか理由をしるせ

Haskellの構文ちょっとわすれちゃったからCで許して

/* nはx[]の長さ．n > 0を仮定 */
int mss (int x[], int n) {
　　int p, q, i;

　　p = x[0];
　　for (i = 1; i < n; i++)
　　　　if (x[i] > p) p = x[i];
　　/* x[]の最大値が負の数なら，それがmss */
　　if (p < 0) return p;

　　/* x[]中には少なくとも1個正の数がある */
　　p = q = 0;
　　for (i = 0; i < n; i++) {
　　　　if ((p += x[i]) < 0) p = 0;
　　　　if (q < p) q = p;
　　}
　　return q;
}

Scheme版も書いてみました．

(define (mss xs)
　(define (pmss xs p q)
　　(if (null? xs) q
　　　　(let ((pp (+ p (car xs))))
　　　　　(pmss (cdr xs) (max pp 0) (max pp q)))))
　(let ((m (apply max xs)))
　　(if (< m 0) m
　　　　(pmss xs 0 0))))

たぶんHaskellだともっとスマートにかけると思います．
それにしても全角スペースをいれてインデントするのは面倒ですね．

線形性は自明ですが，このアルゴリズムがmssを計算していることを
示すほうが面倒といえば面倒ですね．

>>709
Schemeよりスマートに書ける言語なんてありません。

age

>>709
&nbsp;に置換してもらうほうが
こぴぺする側としてはありがたい。

自慢の関数言語で痴漢スクリプト書けばいいだろ

>>713
連続した半角スペースは消えるんじゃないの？

>>715
nbsp;は何個書いても消えないよ。

ghc、なんだかよくわかんねーけどすげーYO！

GHCはGarded Horn Clauseのことです。

Hugsの新版がリリースされました。

http://cvs.haskell.org/Hugs/pages/latest.htm

再びグラフィックライブラリが使えるようになったので
嬉しいです。

ところでHugsって、なんて読むの？
ﾊｸﾞｽﾞ？

嬉しいage

あ、石敢當さんだ！
お久しぶりです。

>>720
"ハグズ"だよ．

>723
あ、ﾊｸﾞｽﾞでいいんだ。

それにしてもライブラリがたくさん増えたなぁ。
もしやと思ってgrepかけてみたけど、Win32 OLEなライブラリは無かった。
これが有ると、世間的にもウケがいい気がするんだけど。

>>722
ご無沙汰してました。（見てはいたんですけどね）
Birdさんの本(>>277)を最初からゆっくり読むことにしていました。
exerciseは適当にやったりとばしたりして、やっと100ページくらい
読んだところです。約1/4くらいまで来ましたが、だんだん中身が
濃くなってきたので読むペースも落ちてきました。Haskellで何か
すぐに作らなきゃいけないわけじゃないので、まあのんびりいきます。

>>723
身近にHaskellをいじっている人がいないので、HaskellもHugsも
実際に発音したことないです。頭の中では「ハスケル」「ハグス」と
読んでいました。「ハグズ」と濁るのが正しいのですね。

俺は頭の中で「ハッグス」って読んでた。

俺は頭の中で、しいちゃんの「ダッコ」を思い出してた。

こんにちは。Haskell勉強中のものです。
Preludeモジュールに、digitToIntがあるのにstringToIntはないんですね。ちょと不思議。
そこで自分で作ってみました。

strToInt :: String -> Int
strToInt "" = 0
strToInt str = digitToInt (last str) + 10* strToInt (init str)

intToStr :: Int -> String
intToStr x
| x `div` 10 == 0 = [intToDigit x]
| otherwise = intToStr ( x `div` 10 ) ++ [intToDigit ( x `mod` 10 )]

こんな風になりました。もっとうまく書けるとか、美しく書けるという人はおしえてくださいな。

>728

read関数があるよ。型に制約かけないとうまく動かんけど。

Prelude>(read :: String -> Int) "1234"
1234

# Hugsはハグスって読んでた

Hugsの開発やってる人達は「ハグズ」って言ってたよ．

正直、Haskellのコードはビジュアル的に美しくないな。
Haskellコードを美しく表示/印刷するための
プリティプリンタが欲しい感じ。

>>728
strToInt "" の時に 0 を返すのはなんかなぁというのと、
効率を気にしてこう書く。

strToInt :: String -> Int
strToInt "" = error "strToInt"
strToInt ('-':cs) = negate $ strToInt cs
strToInt cs = foldl (\x c -> x*10 + digitToInt c) 0 cs

>>728

Int は Read クラスのインスタンスとしてPreludeで宣言されているので、read がつかえるよ。

Prelude> (read "1234")::Int
1234

Int は Show クラスのインスタンスとしてPreludeで宣言されているので、show がつかえるよ。

Prelude> show 1234
"1234"

＞731
a2psの-Eオプションと--highlight-levelオプション使ってみては?
->はちゃんと→になるし、::はなぜか集合の"is an element of"の記号になるけど。
それなりに綺麗にはなるかと。
というか、GHCのサイトのリンクにプリティプリンタがあった気がする。

age

age

>>732
strToInt "----3" が3になるのは嫌だ。

>737
そうだね。俺も嫌(w

>>734
A→Bてのは、→をバイナリオペレータとした、
AからBへの関数全体の集合のことだから、
f∈A→Bは変ではないと思う。

Hugsの新版をインストールしたら、editerをいちいち閉じないと
動かなくなってしまった。これバグ？ Win98使用。

>>739
それはわかってるんだけど、他の言語でNameSpaceを指定したりするのに
::を使ったときも∈になったら鬱とか思った。というか、MLのcons operatorとか。

NameSpaceならそれなりに意味は通じないでもないが、
Consが∈はイヤすぎだな（藁

http://lc.linux.or.jp/lc2001/papers/haskell-paper.pdf
のHaskell Emacsについてどう思いますか？

ghqでインラインアセンブラのようなことは出来ますか？

GHCのversion 5.02.2がリリースされました。

---

年末年始は少し時間を取れたのでIFP本(>>277)を読み進めました。
難しくて良く分からないところなどはとりあえず飛ばして、
Monadの手前の9章まで読みました。大変勉強になります。

>>420 に「O(1) で挿入、削除を出来る queue を作れますか?」
という投稿がありましたが、O(1)で操作できるキューの実装も
出ていました。Chris Okasaki氏の考案によるものだそうです。
短いコードで、O(1)で操作できる理由も書かれているのですが、
まだ私には理解できていません。

今度はexerciseをやりながら読み返してみようと思います。

すみません。sageてしまいました。

山下さんが Why Functional Programming Matters の訳を公開してますね。
http://www.sampou.org/haskell/article/whyfp.html

『Craft of Functional〜』本を読んで、ﾓﾅﾄﾞがぼちぼち解りかけてきたが、
Stateﾓﾅﾄﾞは尚一層難しいね。

デバッガ(?)が有る事を今知ったage
http://www.cs.chalmers.se/Cs/Grundutb/Kurser/d1pt/d1pta/lecture8a.pdf

↑に出て来るcountOccurrencesって関数、ｶｺｲｲけど
自分じゃ絶対思いつけないなぁ。

関数型言語に取り組もうと思うのですが、
Haskell と ML の差(言語、勢力などあらゆる側面において)に
ついて比較していただけませんか？

歴史という意味では ML の方が長い訳だし、パフォーマンスという
意味でもコンパイラまで装備された ML のほうに分がありそうに
見えます。

しかしここのところの人気は Haskell のほうがあるように見えます。
いったいこれはどうした訳なんでしょうか？

Haskell、コンパイラあるよ

>>750
Haskellが人気有るのは2chだけのような気が……。

>750
我々に ML を貶せと仰る?

つか、そんなこと気にしてないで
さっさとどっちでもいいから取り組み始めたほうがよろしいかと。
最終的には両方やればいいし。

あと Scheme も忘れずに。

ガハハハ！　これ、すごいわ。
http://www.puchiwara.com/hacking/

イギリスでもHaskell多いよ。

実際Haskell使ってる人って見たこと無いなあ。
>>750
ML系は出力コードの質が高いのね。
あるベンチサイト見るとC++とタメ張れてる様だし。
型推論って凄いかも。

型推論と出力コードは関係ないだろ。

>>753

実は「どちらをやるか」というのをそれほど気にしているわけ
じゃあないんです。

すでに ML に惚れ込んでいて、そちらでポツポツやり
はじめたところなんですが、
歴史的経緯、その能力などから見て ML がもっとも
成功するべき関数型言語であると漠然と
感じたわけです。

ところがその後 Haskell などの新らしい関数型言語が
再生産されている、これはどうしたことなんだ？ ML に
どのような不満があるんだろう？ こういう観点なんですね。
もちろん本当に納得するには両方やってみるしかないんですが、
まあ聞いてみるか〜と。

今想像しているのは、かっては SML なんかはフリーで
なかったという、開発主導権的な問題が新言語の出生を
促したのかなあ、というものです。Haskell はマイクロソフト
なんかも入れ込んでいるようですから。

一番大きな違いは、MLは作用と副作用が明確に区別できない。
MLは遅延評価じゃない。
と言ったところでは。

そうだよね。MLは遅延評価じゃないから、純粋な宣言的プログラミングには
ならないんだよね。個人的にはMLの「中途半端さ」は悪くないと思っている。
Haskellの研究には頭が下がるけど、まだまだ当分の間、研究の域を出ない
ように思うね。その点、MLはすでに実用レベルじゃない？

# もっともMLは「型のあるScheme」に過ぎないって気もするんだけどね。

Haskellって日本じゃ2chでしか盛り上がってないね。
ユーザー少なすぎ。
2chにはたまたまエヴァンジェリストでも居たのかな？

>>759
あと、型システムがかなり違う。
Haskellの方が型クラスとかあって複雑。

>>762
でもモジュールとかインターフェイスとかはSMLの方がしっかりしてるんだ
よね．

MLは名前が･･･ｶｺﾜﾙｽｷﾞ

メーリングリストは、ML ML？

Pascal->Delphiみたいに
なんか名前考案しる！

用語が一般的すぎると検索で引っかからなくて困るよねえ。

Haskellも人名なので、関係ないページがたくさん引っ掛かるね。

>>760
実用性の面ではどっちも大差ないと思うけど。
なんかどっちも Clean とかに負けてる気もする。

>>762
型クラスって複雑か?
ML の型機構が貧弱なだけなような…。
それをファンクタとかのモジュール機構で補ってる感じ。

あ、あと実用性の面では Ocaml なんかもいい線いってる気がする。

気がするだけで実際は知らないけど…。

>>769-770
あのさ、今はMLとHaskellを比べた場合の話をしてるんだと思うが。

CLOSも、ワインのページがいっぱいひっかかる…

>771
ごめん。十分話題に沿ってるつもりなんだけど。
Clean の名をちょっと出しただけだし。
って、Ocaml もダメだってか?

>>773
それとHaskellの型クラスが複雑なのはMLと比較しての話だと思うが。

>774
俺は Haskell の型システムって結構シンプルだと思うんよ。
だから Haskell の型システムが ML に比べ複雑っていうより
ML の型システムが Haskell に比べて貧弱って云った方がしっくりくる。
って意でした。ごめん。

実際に何かを練習がてら作るとしたら何がいいでしょうか？

hugs(Hugs Version February 2001)にて
x::Integer->Integer
x 0=0
x n=n+x (n-1)
とかやって、
x 1000
くらいなら
500500
という感じで動くのですが、
x 10000
くらいになると
ERROR - Control stack overflow
とか言われてさみしいのですが、
末尾再帰って無いのですか?

x0::Integer->Integer->Integer
x0 0 b=b
x0 a b=x0 (a-1) (a+b)
x::Integer->Integer
x n=x0 n 0
とかもやってみたんですが同じでした。

>>777
> x n= n+x (n-1)
これは末尾再帰ではありません。
Version: February 2000 でも「Control stack overflow」と出ました。
その次のは、「Garbage collection fails to reclaim sufficient space」でした。こっちは処理系の問題。

>>778 February 2001だと、両方とも ERROR - Control stack overflow と言われましたです。

>>779
おかしいなぁ。
後の方はちゃんと末尾再帰になっていますよね……。
？？？

>>777
Haskellは末尾再帰を認識しないです．
もともと末尾再帰の書き変えは，スタックの消費を抑えるためにSchemeや
MLでは導入されたけれども，Haskellは評価がcall-by-nameでlazy
だから単純な末尾再帰のループへの書き変えができないんです．というのも，
1ループ毎に計算結果を確定させないといけないからで，遅延評価とはうまく
なじまないからです．

>>781
なーるほど。

>>781
末尾再帰できないのか。
とすると、１から１０万までの和はどうやって
求めればよいのか？
foldr (+) 0 [1..100000]
これもエラーだ。解法求む。

>> 781
えっ。ほんと？

ちなみに、schemeでは
(define f (lambda (n s) (if (= n 0) s (f (- n 1) (+ s n)))))
で、(f 100000 0)とすると数秒で答えが出る（DrScheme)。
末尾再帰が出来ないとなると、数値計算ではものすごい
メモリー食いなHaskell。
というか、数値計算には不向きという評価？

>>783
foldl' (+) 0 [1..1000000]
とかじゃだめ？

>>786
foldl'うまくいった。サンキュー。
ところで、これなにもの？
Preludeの定義みてもよくわからん。

>>787
簡単に言うと、Haskellが採用している評価順序ではデメリットしか
ないような場合には評価順序を変更して効率を良くしよう、ということ
です。例えば、foldlを使って1から3までの和を求めようとすると、

foldl (+) 0 [1,2,3]
= foldl (+) (0 + 1) [2,3]
= foldl (+) ((0 + 1) + 2) [3]
= foldl (+) (((0 + 1) + 2) + 3) []
= (((0 + 1) + 2) + 3) = ...

このように、途中の加算の式をそのまま引きずっています。
そんなことをせずに、

foldl (+) 0 [1,2,3]
= foldl (+) (0 + 1) [2,3] = foldl (+) 1 [2,3]
= foldl (+) (1 + 2) [3] = fold (+) 3 [3]
= foldl (+) (3 + 3) [] = fold (+) 6 [] = 6

としたほうが、明らかに効率が良さそうです。
Preludeのfoldl'の定義で使用されている($!) :: (a -> b) -> a -> b
は、まず第2引数の簡約化を行ってから関数適用を行うので、
まさに上に書いたような状況が得られるわけです。

Haskell Reportの 「6.2 Strict Evaluation」にこのあたりのことに
関する説明が少しあります。また、IFP本(>>277)では
「7.5 Controlling space」にやや詳しい説明があります。

>>788
詳しい説明どうも。おおよそ理解できました。

末尾再帰のメカニズムと同様のように感じますが、
オレの誤解かな。

>>781-789
どうもです。

hugsだと、
x0::Integer->Integer->Integer
x0 0 b=b
x0 a b=x0 (a-1) $! (a+b)
x::Integer->Integer
x n=x0 n 0
で末尾再帰っぽくできましたが、
この場合も末尾再帰になることは
haskell的には保証されてない(=実装依存)んですか?>781

>>790
それは末尾再帰になりますよ，$!でeagerに評価させているので．

つまり，プログラムで陽に指定しない限り，schemeのように
末尾再帰を自動的に認識して，ループに書き変えたりしない，って
ことです(というかcall-by-name(need)ではそれができない)．

>>791
ありがとうございます。
これで心置きなく末尾再帰できます!

たいしたもん書いてないんでHugsでもいいかなと思ったけど、
GHC入れてみたら、かなり速かった。
Hugsみたいにstack overflowでいきなり落ちないのも良いなぁ。

>>793
設定の次第なのでは。。。

速さじゃないよ。

qsort :: Ord(a) => [a] -> [a]
qsort [] = []
qsort (x:xs) = qsort [a|a<-xs,a<=x] ++ [x] ++ qsort [a|a<-xs,a>x]

Haskellってなぜに暗号みたいなソースなんですかね。
訳のわからん記号が多すぎ。
MLの方が読みやすいよ。

モナドは難しいですね、いまだ理解の途中。
それにしても入出力とか、ちょっと何かするだけが結構面倒ですね。
末尾再帰の問題も気になるし。
MLの方が良いような気がしてきた。

そうかなあ？
記号なんてほとんど無いと思うけどなあ。
３つや４つぐらい覚えたら終わりでしょ？

>>797
暗号みたいでわからないと言われそうな書き方というのは
おそらく[a|a<-xs]集合のような書き方と、\x->x+1の
ようなラムダ式の書き方ぐらいだね。
前者は数学の集合、後者はラムダ計算を知っていれば、
すぐに理解できる書き方。
おそらく、あなたはあまり数学や計算機科学になじみが
無いのでしょう。

>>= とか $! とか :% とか $+$ とか .&. とかの事じゃないの？

[a|a<-xs] や　\x->x+1　はむしろ歓迎する。
内容じゃないです、書式が嫌なんです。

>>= とか $! とか :% とか $+$ とか .&. の類です。
アルファベットで書いてくれた方が読みやすいと思うのだが。
hoge.func と　f . g もどうかと思ったです。
なんか無理してる気がする。

なんとなく、MLのソースと見比べて美しさにかける気はしません？
（べつにMLでなくても良いですけど）

> アルファベットで書いてくれた方が読みやすいと思うのだが。
そーかなぁ?
アルファベットだらけのほうが読みにくいような…。
f . g でなく f o g とか嫌だしな…。
あと fun とか fn とかも…。
まあ、好みの問題なんでしょが…。

MLと比べると確かにHaskellの方が癖があるかも．
でもMLの単項マイナスの~もちょっと気がひけるよね．
どちらもjuxtapositionだからCみたいな手続き型より見やすいの
は確かなんだけど．

漏れも、本読んでて >@> って演算子が出て来た時は、
魚 <ﾟ)))彡 かよｦｲ、って思った。

でもそんな記号読みにくいって程たくさん使うか？

すいません、Monadについて教えて教えてください。
まだHaskell(hungs)さわって１ヶ月程度の人間なんで
2チャンネラーのみなさん、お手柔らかにお願いします。

私はMonadを使うことで一定の順序で処理を行えるものだと考えています。
　f1 >> ( f2 >> f3 )
としても f1 f2 f3の順番で処理されるということで良いでしょうか？

と言ってもMonadの関数？（ここでいうf1 f2 f3）は関数を返す関数なので
Monadは f1 f2 f3 を順番道理に処理できるよう、各関数をbindするもの
ではないかと思っています。

つづきです。

私がHaskellを触って、一番びっくりしたことは
処理系がプログラムを処理する順番が、予測できない
という点です。
(G-mashineの文章でそうなっていると書いていました)

これはHaskellの良い点だと思いますが、実際処理に順番を
つけたい時が、多いと思います。
そういう時に、Monadを使ったら良いのでしょうか？

追記:なんか日本語変ですね。

>>807
> これはHaskellの良い点だと思いますが、実際処理に順番を
> つけたい時が、多いと思います。
> そういう時に、Monadを使ったら良いのでしょうか？

Monad使うです。
木の左上から順番に番号振て逝く例が、
http://www.cs.ukc.ac.uk/people/staff/sjt/craft2e/
のpp.409あたりに載てました。
http://www.cs.ukc.ac.uk/people/staff/sjt/craft2e/Code/Chapter18.hs
Haskell厨房の僕に要約する能力は無いので、自分で本買うか、
他の人に頼むよろしあるのコトよ。

１から10万までの総和を求める問題で、($!)を使って末尾再帰と
して一応決着がついたが、どうも($!)を使って強制評価させるの
はhaskellらしくない。
そこで、haskellらしくストリームを使ってやってみた。
nat = 1 : map (+1) nat
acc = 0 : zipWith (+) nat acc
natは自然数のストリーム、accはある数までの総和の
ストリーム。
10万までの総和はacc !! 100000。しかし、ダメだった。
ERROR - Garbage collection fails to reclaim sufficient space
だって。
なんか、よい方法ない？

>>809
ghci 使ってみた？

ghcはじめて使った。

やはり、だめみたい。10万まではＯＫだけど、100万で
stack over flow

>811
訂正。名前まちがえた。オレは809だった。

１から100万までの整数の総和を求めよ。
ただし($!)やそれを含む関数を使うな。
この問題の解法だれかたのむ。
どうも気になる。

(1+100万) * 50万
で求められるんじゃないの？

ガウス少年、その手は小学生にはダメよ。

こころは、ハスケルの遅延評価の枠組みの
なかで、メモリー爆発させずに計算できるか
ということなんです。

Ｈａｓｋｅｌｌの基礎的なことを一通りわかった（つもり）になったので、
Ｈａｓｋｅｌｌのライブラリをながめてみた。
なんかＨａｓｋｅｌｌって天才向けの言語なんだろうかと思えてしまう。
よくそんなこと思いついたよなあ、ということが満載。

>>808
レスが遅れてすいません。
返事有難うございます。
うーん。
私は英語がにがてなので、紹介してくれた本は読めないかな？
もう少し独学でがんばってみます。

モナドは一応理解した。
で、おもったのだが、
モナドってどうやって使いこなせるのだろう？
ＣａｔｅｇｏｒｙＴｈｅｏｒｙの知識とかがないと、掴みきれないのだろうか。
なんか凄いとは思ったが、これを使いこなしている自分は思い浮かばないなあ。

自分でモナドを作れるくらいやりこんでおる人はここに居るのでしょうか？

モナド使うったり作るのは簡単じゃん？
モナドを理論的に解説するのは難しいけど。

>>819
モナドをつかったライブラリを・・ってことじゃないの？

モナドって何か隔靴掻痒の感があるな。
特に根拠はないけど。

>>821
いや，手続き型を先に知った人は誰でもそう感じるんじゃないかな．
わざわざ複雑なことをしたあげく，できるのが手続き型ではごく当り前のこと．

>>822
そうかなぁ?
Gentle Introduction の monad のところに載ってるやつぐらいでも
手続き型では結構大変そうな感じが…。

I/Oモナドと状態モナドを理解出来るかどうかが
入門の障壁になってるというか、λ教に入信する為の
イニシエーションという感じだね。
Cのポインタみたいに。

Haskellがメジャー言語だったら、書店には
『Haskellモナド完全制覇』とか『秘伝Haskell問答 モナド編』とか
のタイトルが並んでいそうだ。

>>824
＞『Haskellモナド完全制覇』

めっちゃ欲しいよ〜。
誰か書いて〜。

>>822
>わざわざ複雑なことをしたあげく，できるのが手続き型ではごく当り前のこと．

そう思えるのであれば、まだモナドを深く理解していないと思います。
もし単に手続き型にすぎないなら、モナドを剥き出しにする必要は無く
Ｄｏの糖衣構文で覆ったままにしておけば済むはずですし。

モナドは（私もよくわかっていないが）、それ以外に色々な使い方が可能。
よくわからないが、けっこう不思議な道具なかんじがする。

Lispの処理系の乱立に嫌気が差してきたんだけど、
Haskellの場合はまともな処理系はGHCで決まりという
ことになってるのかな？
もしそれならHaskellやってみたいし、GHCを使って
なにか使えるものを作りたい。

ああ、あれな
藤崎奈々子も使ってる。
第一位な奴な

え、藤崎奈々子がHaskelプログラマ？マジ？

>>828
それは DHC (化粧品) だろ!

モナドは、なんか犠牲にしているような気がするな。
なんというか、プログラマからみての明らかさというか
そんな感じのものを。

>>826
> もし単に手続き型にすぎないなら、モナドを剥き出しにする必要は無く
> Ｄｏの糖衣構文で覆ったままにしておけば済むはずですし。

Monadにdoのsyntax sugarがあるのは、Monadのユーザーは
普通doですべてこと足りるからでしょ。実際、入門の段階でMonadを
扱うときはdoでシーケンシャルな処理が簡単に書けますよ、っていう
例題が普通だし、それを見て手続き型を知ってる人達が、なんでそん
な難しいことをするのかと感じるのは当然でしょう。実際遅延評価のお
かげでストレートにシーケンシャルな評価をさせるのは難しくなっちゃ
ってるわけだし。結局Monadの肝は、順番に評価を実行して、それを
環境に反映させてさらに次の評価に移る、ということを(lawsに従っ
たMonadであれば)遅延評価の枠組を壊さずきちんと実現できる点に
尽きると思います。

doが(>>=)や(>>)Nおsyntax sugarになっている理由はユー
ザが独自のMonadを定義する際に、きちんとlawsに従ったものにさ
せるためですよね。doだけになっちゃたら、Monadクラスの型は定
義できなくなっちゃうじゃないですか。

>>832
モナドの処理がdoを使えば手続き型と同じ書き方になるんだなとは
思ったけど、難しいとは思わなかった。同じだと思っただけ。

継続をモナドで実装するとか、
チュートリにある、計算ステップを制限した手続き型計算とか、
ああいうのをみると凄そうだなと思うな。

コンカレントのライブラリが、あれでどうしてコンカレントになってしまうのか
不思議で眠れません

Concurrent Haskellって、マルチCPU環境だと
スレッドを意識して書かなくても勝手に
ものすごい勢いで計算出来たりするわけ？

今チュートリアル読みながらやってるけど、
なかなか難しいね。馴れが必要かも。

皆さん最初は何で勉強されました？

>>837
難しいよね。Haskellは。

>>837
東京工科大学のテキストでツカミを得てから、
この本↓を読むのが分かりやすいと思う。
http://www.cs.ukc.ac.uk/people/staff/sjt/craft2e/

手に入れやすいもう一冊の本、『〜THROUGH MULTIMEDIA』の方は
ちょと難しい。

　　/　　　　　　 ／　　　　　　 |　＼　　　　　　　 ヽ
　 /i.　　　　　／　　　,,,,,;;;;=:::...、　　ヽ　　　　　　　i
　　|　　　　∠,,,　　　'''　　__　　`　　　i.　　　　　　 |
　 /|　　 i'´　　 ヽ　　　,. 'i'''''i>、　　　　!　　　　　　!
　 ! !　　 !,;i'''(''`;, :.　　 ':‐`'''´`　　　　 `i　　　　　 .|
　　 ﾄi、 .|　''''´´　　　　　　　　　　　　　;| i　　　　 !
　　　 ヽ. !　　　 .　　　　.　　　　　　　　/!;//　　　i'
　　　　 `!:.　　　 :..、.‐'' '　　　　　　　 /　//　　　i'.　 ／￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣
　　　　　ヽi.　　　　,___,、　　　　　　 ./　//　　　./.　 |
　　　　　 ﾉ| ;　　.:',.ｒ==‐`‐　　　　　/　// _　　 〈　＜　コレ、気持ちいいかも……‥‥・・・
　　　　　 ﾉノ;ヽ　ヽ:::::::'''´　　　　　　／´ ,!　　　 !　　| http://www.puchiwara.com/hacking/
　　　　　'　'´　 ＼　　　　　　　.::　 ´　　 /,、,,;　,!.　　＼＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿
　　　　　　　　　　｀ ;,、__....:::::　　　　　　 。・.,;;::::.
　　　　　　　　　　　``｀｀ヽ　　　　　　。::';=''´　｀`、
　　　　　　　　　　　　　　 ｀i　　　,,。;:':;''´　　　::..、:、
　　　　　　　　　　　　,.:::‐‐,;　.,,;:;':':'''｀　　　　　　　ヽ:、
　　　　　　　　　　,.:''´　　;:iﾚ;:''　 　　　　　　　　　　　::.
　　　　　　　　　.,i　　.:。´'':;''　　 :.　　　　　　　　　　　 :.
　　　　　　　　　i　／,:;..,:;''　　　 .:.　　　　　　　　　　　　:.
　　　　　　　　 ,ﾉ '..;:;':;''　　　　　 :.　　　　　　　　　　　　 :
　　　　　　　..:'　。;''´´　　　　　　　.　　　　　　　　　　　　:.
　　　　　　人,,:;'`'　　　　　　　　　:.:..:.　　　　　　　　　　　 :.
　　　　　ノr''￣`‐::.、　　　　　　　 . :. :　　　　　　　　　　　.i
　　　　/,:;''　　　 ﾉ　＼_　　　　　　 :. :.、　　　　　　　　　　 i
　　　 /`´　　 ／　　　　`‐::.、　　　 ｀　:.　　　　　　　　　　 :、
　　 ./　　　.／　　　　　　　　｀`‐::.._　　　:.　　　　　　　　　　i
　　 i　　　/　　　　　　　　　　　　/　`::..、ヽ　　　　　　　　　 :、
　　 !.　　/　　　　　　　　　　　　/　　　　``:.　　　　　　　　　 :、

http://research.microsoft.com/~simonmar/hws.tar.gz
マイクロソフトの次期IIS、Haskellで作るられるらしいです！！

とりあえず例題ばかりじゃつまらんだろうから一応。

>>841
これも、Concurrent Haskellなんだね。
この前見たGUI系の奴もConcurrent使ってたなぁ。

ＭＬのほうが簡単ぽいのでＭＬに浮気します・・
無念。

知らない間にＭＬスレが立ってますね。
ところで、ＭＬに比べてのＨａｓｋｅｌｌの特徴・利点欠点とはなにでしょうか。

遅延評価だろ。なんつっても。
良くも悪くも。

理想的には遅延評価によって無用な計算を避けられるはずなんだが、
現実にはHaskellはMLより効率悪い（と云われている）。

>>845
StandardMLでは遅延評価は仕様外だが、
独自に装備している処理系も多いッすよ。

遅延評価だけでは両社の差とは言いにくいと思いますが、いかが？
（私はHaskell知らず）

>>846
補足、
部分的に遅延にできる機能を、です。

遅延評価は無限データ構造を扱えるようにするためだろ？
あと関連するがノンターミネーションをなくす為。
無駄をなくすとかじゃないだろ。
理想的にも何も無駄は増えるよ。当たり前じゃん。

ちょっと奥さんこれマジよ？
こんなもん作ってるとは。

'Quake Haskell'
http://www.dtek.chalmers.se/~d95jowi/quakehaskell/index.html

>>849
これ、何語？読めません（笑
なんとなくは解るけど。

swedish?

>>850
すえーでんじゃないかな。わたしも読めません。
>>846
でもそれがデフォルトにはなっていないでしょう。
わたしはMLを知らないけど、Haskellのプログラミングは、
Schemeで「いつでもdelay/forceを使う」のと同じようなものでは？
もちろんそれとは違ってHaskellのプログラミングは「自然に」そうなるのでしょうけど。

>>848
評価する必要のない物を評価しないってことで
多少無駄が減るって話もあるかと。

>>848
ちがうと思うな．関数型言語を設計するにあたって本当に欲しいのは遅延評価
じゃなくてcall-by-nameでしょ．ただ，工夫しないでcall-by-name
にすると問題が多すぎるから，遅延評価にしているわけで．

http://www.sampou.org/haskell/article/whyfp.html
遅延評価の意義についてはここに述べられているが？

>>855
それは、遅延評価を採用するとこういう良いこともあるよ、というお話。

haskellやったからといって、すごいプログラムが書けるとかは、
全然期待してないけど、すこし数学がわかるようになる副作用を
期待している。

>>854
だからそれはノンターミネーションの話でしょう

>>858
違う。call-by-name そのままだと、同じ評価を繰り返すことになりやすい。
それを防ぐため。nonterminationとは全く別の話で、簡単に言えば無駄をな
くす、ということ。

>>859
しかし値渡しからすれば無駄でしょう

>>859
そのためのGraphだ
同じ文脈(関数内？)に現れる同じ名前のものは同じものを指すという
参照透明性を利用することで解決している。
同じ名前のものの実態は、１つに共有するようにしている

>>859
call by nameとか遅延評価とかじゃなくて、
inner-most reduction, outer-most reduction, graph reduction
で説明したほうがわかりやすいと思う。
inner-most reductionはcall by valueに相当して、strictであり、
計算上必要ない引数まで評価してしまう。
outer-most reductionとgraph reductionは遅延評価の実装で、non-strictであり、
計算上必要ない引数を評価せずにすむ。
うち、outer-most reductionはナイーブなcall by nameの実装。
graph reductionは副作用がなければcall by nameと等価だが、
同一式が無駄に複数回評価されるのを防ぐことができる。

>>862
で，結局ノンターミネーションとの関係は？

すみませんです
通りかかりです

｜call-by-name , nontermination , call-by-value
｜inner-most reduction, outer-most reduction, graph reduction

もしよろしければでいいんですが、
これらの用語についてぜんぜん初心者である私らに簡単な説明をして
頂けませんか？

>>862
遅延評価でnon-terminationを避けることができる。

call by name, call by reference
　関数fが定義されているとして、f(1+1)を計算する時に
　1+1を計算して2という値を渡すのがcall by value。
　1+1という式(名前)を渡すのがcall by name。
　call by nameは手続型言語ではAlgol、関数型言語ではMiranda, Haskelなど
　call by valueは大部分の手続型言語と関数型言語ではML, Lispが採用している。

reductionの戦略
　関数doubleがdouble(x) = x + xと定義されていて、double(1+2)を計算する時、
　double(1+1)→double(2)→2+2→4といった具合に式の内側から計算していくのがinner-most reduction。
　double(1+1)→(1+1)+(1+1)→2+(1+1)→2+2→4と、式の外側から計算していくのがouter-most reduction。
　一方、関数ifがif(true, x, y) = x, if(false, x, y) = yと定義されていて
　if(true, 1, 1+2+...+10)を計算する時には、
　inner-most reductionではif(true,1,1+2+...+10)→...→if(true,1,55)→1
　outer-most reductionではif(true,1,1+2+...+10)→1となり、余分な計算を避けることができる。
　inner-most reductionはcall by valueに相当する。
　outer-most reductionはcall by nameに相当する。
　副作用およびnon-terminationおよび計算量を除けば両者は同じ値が求まる。
graph reduction
　double(1+1)の例で見たように、outer-most reductionでは
　引数で渡ってきた式を複数回計算してしまうことが多い。
　graph reductionでは式をグラフ構造で表現し、double(1+1)は
　double(* + *)
　 | |
　 +---->1 + 1 (実際はちょっと違うけど、まあわかりやすく)
　というグラフ構造で表現される。
　ここで1+1はx+xの中で2回出現しているが同一ノードに参照されているから
　double(1+1)→(1+1)+(1+1)→2+2→4という具合に計算されていき、
　1+1は1度きり計算されるのみである。

non-termination
　このスレの文脈では、
　無限リストなど、完全に値を求めようとすると計算が終了しない式を扱う時、
　inner-most reductionでは当然、計算が終了しないことになる(non-terminationの問題)。
　outer-most reductionやgraph reductionなどにより遅延評価をおこなうことで
　無限リストなどのうち必要な部分のみを計算することで、non-terminationの問題を避けることができる。
　もちろん、遅延評価ならどんな式でも計算が終了するというわけではない。

>関数ifがif(true, x, y) = x, if(false, x, y) = yと定義されていて
>if(true, 1, 1+2+...+10)を計算する時には、
>inner-most reductionではif(true,1,1+2+...+10)→...→if(true,1,55)→1
>outer-most reductionではif(true,1,1+2+...+10)→1となり、余分な計算を避けることができる。

そんなこと言うけど
実際に実装してみたら、値渡しの方が無駄がないよ。
シンプルだし。

やっぱり、無駄なのに敢えてやる実益を考えてみるならば、
ノンターミネーションの為であり、
ひいては無限の為でしょう。

>>869
>実際に実装してみたら、値渡しの方が無駄がないよ。
>シンプルだし。

宣言的プログラミングという理想からすると、そのプログラムが
「何を求めるか」だけ宣言すればよく、「どのように求めるか」
はコンピュータに任せることができる、というのがゴールでしょ
う。多少計算に時間がかかっても「その解法が正当かどうか」を
検証する手間を省けるなら、その方が嬉しいことも少なくないだ
ろう？

>>871
それは遅延評価と関係あるのかな。
関係あるとしても導入の理由かな？
というか、それは副作用の話では？

最後までHaskellを使うとしたら、どんな処理系を使うんだろうage

>>873は>>841のことでしたsage

>>866
>>867
ありがとうございました、勉強になりました。
なんの議論かようやくわかりました。

>>873
個人的にはGHCと関連のライブラリだけでできそうな気がします。
Haskellは、いろんなモノがそろっててすごいと思った。
日本では全然マイナーだから机上の言語と思っておりました。

にしても本当なんでしょうか？
マイクロソフトがHaskellだなんて、ラティンとブッシュが手打ちしたようにも
思えるのは私だけ？

>>872
別に副作用だけの話じゃないだろ。
よーするにcall by nameだのreductionの戦略なんてのは
実装上の問題にすぎないわけで、
真に宣言的プログラミングを実現しようとすれば、
そんな事気にしなくてよいほうがいいに決まってるじゃん。
だったら、より安全かつ効率もそこそこいいgraph reductionが
現状では一番理想に近いっつーことでしょ。

>>873-875
次期IISってのはネタかと。
http://www.haskell.org/~simonmar/abstracts/web-server.html

>>876
純粋に数学的な関数を実現しようとすると参照透過性って必要にならない？
で、参照透過性って、プログラミング言語ではcall by nameがそうな
んじゃないの？だから実装の問題だけとも言えないような…

>>878
call by nameが参照透明性を保障するわけではない。
参照透明性が保障されていればcall by nameでもcall by valueでも
同じ結果が求まる(ただしnon-terminationは除く)っつーこと。

ちなみにAlgolは手続型言語だがcall by nameをサポートしていた。

>>879
じゃ参照透過性はどうやって実現するの？ 例えばHaskellでは、
何が参照透過性を実現するために必須のコンポーネントなの？

>>880
強いて言えば、もなーど。 ＃そっか、だから2chで人気なのか...

参照の透明性自体は破壊的代入などの副作用を起こすものや非決定性を
言語やライブラリから排除する事で達成できる。
でもそれじゃ外部I/Oなんかを扱うのに困っちゃうから、関数型言語では
それぞれ工夫して折り合いをつけている。
Mirandaなら無限リスト、Haskelならmonad。
っつーか、武市先生の「関数プログラミング」とか読んでみれば？

はっはっは、昨日関数プログラミングのテストだったよ。
全部解けちまったよ。はっはっは。

そらそーだよな。簡単だったもん。
「関数プログラミング」の６章までが範囲でした。
ﾄﾞｷｭｿ学生でスマソ。

>>876
現実には、遅延評価はプログラムの正当性を検証しやすくする方向に
働くとは限らないでしょう。
同じことを繰り返すが、
遅延評価とプログラムの正当性の検証しやすさは余り関係ないと思うが。
理想的ともいいきれないと思いますよ。

というか、遅延評価と正当性の関係及び
遅延評価と参照透明性の関係をいう人は、
その例を示して欲しいと思います。
特に正格評価との比較において。

>>883
じゃ，なんでHaskellは遅延評価を採用しているの？

だからノンターミネーションを防ぐ為でしょう。
何度もいいますが。

与えられたリストの長さが有限か無限かを調べる

isFinite :: [a] -> Bool

のような関数というのは簡単に作れるものなのでしょうか。
ちょっと考えてみたりライブラリを調べてみたりしてみたのですが
良く分かりません。何に使うというわけでもないのですが、
なんとなく気になっています。

Network Information: [ネットワーク情報]
a. [IPネットワークアドレス] 61.207.0.0-61.207.255.0
b. [ネットワーク名] OCN
f. [組織名] オープンコンピュータネットワーク
g. [Organization] Open Computer Network
m. [運用責任者] AY1361JP
n. [技術連絡担当者] MO081JP
n. [技術連絡担当者] KK551JP
n. [技術連絡担当者] IM657JP
p. [ネームサーバ] ns-kg001.ocn.ad.jp/61.207.56.0-61.207.255.0
p. [ネームサーバ] ns-kn001.ocn.ad.jp/61.207.56.0-61.207.255.0
p. [ネームサーバ] ns-os001.ocn.ad.jp/61.207.0.0-61.207.37.0
p. [ネームサーバ] ns-os001.ocn.ad.jp/61.207.42.0-61.207.55.0
p. [ネームサーバ] ns-tkb01.ocn.ad.jp/61.207.38.0-61.207.41.0
p. [ネームサーバ] ns-tkb02.ocn.ad.jp/61.207.38.0-61.207.41.0
p. [ネームサーバ] pns.ocn.ad.jp/61.207.0.0-61.207.37.0
p. [ネームサーバ] pns.ocn.ad.jp/61.207.42.0-61.207.55.0
y. [通知アドレス] [email protected]
[割当年月日] 2001/05/08
[返却年月日]
[最終更新] 2002/01/28 10:53:02 (JST)
[email protected]

>>888
嬉しそうだな。

>>887
なんか直観的にはできなさそうですね。
ちょっと問題を拡大して、任意の表現式のterminationを返す関数について、
任意の式のterminationを返す関数willTerminateが定義できると仮定して
対角線してみたらどうでしょうか？

>>883
>>876にはプログラムの正当性や検証の話は全然出てこないのですが。

>>891
しかし、>>871は正当性の話をしているでしょう。
それに対する応答として>>872があって、
>>876はその872の応答なのだから、
当然正当性の話でしょう。

なんか粘着君だねえ。そういう書き方されると説明したくなるなるよ。

たしかに俺の書き込みはちょっと飛躍があったかも知れない。
それで混乱させたんなら悪いと思う。

正当性について述べたのは「なぜ宣言的プログラミングが必要か」を
述べるためでであり、「なぜ遅延評価が必要か」を直接述べたわけで
はないよ。誤解させたのならすまん。

で、宣言的プログラミングには遅延評価が必要なわけだ。
いつでも遅延評価が必要なわけではないし、
遅延評価ではまずいこともある。
でも、宣言的プログラミングを実現するにあたって、
遅延評価が「不必要」ってことはない。

Haskellは宣言的プログラミングを完全にサポートしているわけではない。
しかし、そこに近づくためのひとつの実験だと、僕は考えている。
とりわけ遅延評価の重要性と問題をともに検証するための実験だと。

その点、MLはぐっと実用上の理由から設計された言語だと思うんだ。
少なくとも宣言的プログラミングを目指してはいないでしょう？

僕はこういう理解で871を書いた。
間違ったことを書いているかも知れない。
それは指摘してください。
でも、書きたかったことはこういうことです。

>>887
チューリング機械のエミュレータを関数で作る。
関数は機械の状態遷移図と初期状態を引数にとり、
１ステップおきの状態のトレースをリストで返す。
そうすれば、リストが有限であることと
初期状態から状態を遷移させ、終了状態に至ることは同じになる。
ということはもしisFiniteがあったらチューリング機械の停止性が
判定できてしまう。だが、これはできないことがわかっているので
そもそもisFiniteは書けないと思われ。

>>894
この問題ってrecursiveだけれどenumerableでない典型ですよね．

>>894
そりゃそうなんだ。
リスト操作しかできなかったら、そうやって即答できる。

でも無限リストとして定義されている、というところを触れれば判定できてしまう。
できるかねえ？
というかそこまで判定したかったら、リストを拡張してしまえば・・ってそれじゃ
リストの判定ならない？

うーんと、俺は871が
> 多少計算に時間がかかっても「その解法が正当かどうか」を
> 検証する手間を省けるなら、といっているのは、
-----------
値渡しの場合には各引数のcannonical formを求める手続きの停止性を
正当化しなければならない。
遅延評価を使えば、少なくとも各引数の停止性を正当化する必要がない分だけ
「何を求めるか」に集中することができる。
--------------------------
って事だと解釈した。
つまり、遅延評価でのプログラムの検証がどうこうということではなく、
値渡しでのプログラムでは正当化しなければならない事が増える、って事。
あってる？>871

あと、俺はHaskelなどのlazy evaluationを理想とは思っていない。
ただ、値渡しに比べればより宣言的プログラミングの理想に近いとは思う。

些細な事だが、HaskellはLが2つ。

え？
ここでの正当性の話というのは正当性のテスト又は
部分正当性の話ではないのか？
ターミネーションの話ならば、私の話とどう違うんでしょう？

>>897
>つまり、遅延評価でのプログラムの検証がどうこうということではなく、
>値渡しでのプログラムでは正当化しなければならない事が増える、って事。
>あってる？>871

うん。というか、値渡しだと、処理順序を特定することなしに
手続きの停止性は決定できないわけだから、必然的に処理順序
を特定することになる。つまり「アルゴリズム」を記述しなけ
ればいけなくなり、アルゴリズムの正当性を（言語処理系の責
任ではなく、プログラマーの責任において）保証しなければな
らなくなる。つまり、それは宣言的プログラミングではない、
ということだと。

あ、そうでもないか。言語処理系が任意のアルゴリズムの正
当性を決定できれば良いのか。できるのか？

私は、遅延評価の意義をターミネーションの為だといったものです。

>900
>> あ、そうでもないか。言語処理系が任意のアルゴリズムの正
>> 当性を決定できれば良いのか。できるのか？
それはNP完全なのでは？

ghc-5.03でたよー！
変更点をコピってきました。

・ The type system now supports arbitrary rank polymorphism,
　　given appropriate type annotations.

・ Heap profiling has had a major overhaul and now supports
　　retainer profiling and biographical profiling ala nhc98.

・ Major improvements to the native code generators.
　　You can now compile any and all code through them,
　　including the Prelude.

・ The FFI syntax has been updated to match the latest version
　　of the FFI Haskell 98 Addendum.

・ newtypes support deriving *any* class for which the underlying
　　type is also an instance.

・ Linear implicit parameters: a highly experimental feature.

>>903
訳せ〜

・・っちゅうか英語を日本語に直す作業くらい私でもできんことはないが、

1.用語を正しく訳せるかあやしい
2.変更点の持つ意義についての解説がさっぱり

ということで、どなたかお願いします。

山形浩夫が Haskell 本を2冊も買ってるよ。
http://www.post1.com/home/hiyori13/buy/buy1.html
この人あんまりプログラミングとかしない人だと思ってたのだが…
つか時期的にアレだな、このスレの影響である可能性も無くもないな。

つーか山形センセ、"L"が一つ足りません、、

>>906

山形せんせ、いきなりＨａｓｋｅｌｌではなくて、
ＭＬをＵｌｌｍａｎの翻訳本→大堀先生の本で「斜め読み」してからＨａｓｋｅｌｌにしたほうが
いいかもしれないです。

いや、Ｈａｓｋｅｌｌに敵対するつもりはないです。
がっこの先生いわく、ＭＬ（からの）方がやさしいし、関数型でのコードの書き方もわか
って挫折しにくいとか。
いきなりＨａｓｋｅｌｌでくみ出すとコードが書けないこと多しとかで。

＃わたしもこの路線でべんきょしとります。
＃こけた人はこの迂回路を試して見てください。

こらっ！山形！
プログラムのしろーとがいきなりＨａｓｋｅｌｌに取り組んでどうする！


Ｔｃｌ/Ｔｋ【＋Ｃで機能拡張】でもやっときなさい。

いや、結構マジです。
なぜなら、言語内部で戯れていただくより、
アプリケーションで世界と戯れていただきたい。
微妙に絶妙なアプリを作って我々を笑わせてください。

＃Ｔｃｌ/Ｔｋなら、山形著のプログラム解説本が拝めるかもしれないし（笑

山形！ もっとフツーの言語から勉強しろ！
elisp やって navi2ch でも改良してろや。

haskellのコンパイラってhaskell自身で書いてあるんだね。
今度ソースコードを見てみよう！

山形先生、見てますかー？

>>890,894-896
えーと、結局 isFinite のような関数を定義することはできない
ということでしょうか。

---

アマゾンで Haskell:The Craft of Functional Programming の第3版が
「近日発売」となっているのを見ました。近日とは言っても発売予定日は
7/31なのでまだまだ先だなぁと思ったのですが、よく見ると来年の7/31、
１年半も先の話でした。

いきなりＨａｓｋｅｌｌ。
その「選択」がいかにも山形っぽいと思うのは私だけでしょうか？
山形がＨａｓｋｅｌｌってプログラマーとして結実するのはいかにも無理。

あるいは・・
Ｈａｓｋｅｌｌの常識的なことをとりあえず頭にいれて、
あとは中途半端な知識でプログラミングについて書いてる弱そうな奴
を見つけては突っ込んでイビる。
結局そんなところに落ち着くのがおちのような・・


>>908
>山形著のプログラミング解説書。

「山形文体」のプログラミング書籍なんぞ読みたくない（笑

>>890
対角線論法で矛盾を導くということですか？
すみません、もうちょい詳しく教えてください。

山形さんあまりプログラミングしない人って書いたけど
一応 pc-unix 使いで、emacs 使いらしいし、
中学生のころからコンピュータに触ってたらしいし
まあ、C や elisp などなど、それなりには知ってるんじゃねぇ?
なわけで「いきなりＨａｓｋｅｌｌ」ってほどでもないんじゃないか。

でも原稿は Word で書いてそのまま送ります。

>>915
ソースは？

山形はプログラムを作るためでも、
最新のプログラミング研究への見識を深めるためでもなく、
プログラミング言語の理屈を垂れるためにＨａｓｋｅｌｌ本を読んでる
気がするのであった。

山形サイトもＨＴＭＬＬｉｎｔかけんのは良いことだと思うけど、
わざわざ「やってます！」と宣伝することもないとおもう。
Ｈａｓｋｅｌｌもおなじ予感がするのね。

まあ、このへんの大人気無さが逆に痛快さでもあって魅力なんだ
けれどね。どんどん大人気無いことをやってください。
世の中には良い意味の大人気無さが足りませんから。


ここを読んでるのかな？
ゼビウス遠藤みたいに隠すことなく出現しまくってくれると嬉しいと
思ったりして。

あんまりよくわかってない技術の理屈を垂れるような恥ずかしげなことはしないような。
Berlin の FAQ とか訳してるし
http://www2.berlin-consortium.org/wiki/html/Berlin/JapaneseFAQ.htm
なんか新しいもの好きなだけな気も。

あ、読んではいませんが、いま教えられて見に来ました。みなさまご指導どうも。

>>918
わ〜、なんだこの訳は！

ＵＮＩＸのＪＭＡＮとか、ＭＳＤＮとかがこの文体だったらいやだな（笑

http://ruitomo.com/~hiroo/bbs/kohobu.html
さすが山形先生。読むの速いね。

>>919
ホンモノかよ（笑

私はこの人のこと良くは知りませんが、何者ですかね？
色々なことをしているようですが。

＞＞９１７
ちょっと似てるけど。
僕は変にかしこぶって遠くからうだうだいうばかりで大したことしないんじゃなくて
ちゃんと自分でいろいろと実践してるところが好きだなぁ。

で、その結果つっこまれてもさらにそれをバネにして（でも彼の場合こういう泥臭い物を一切感じさせない所がまたいいのです）
さらにいろいろとやっていくとがさらに好きだったりします。


＞＞９２０
ちゃんと英文分かってないと怖くてそんな訳できないのに普通にやってのけるところがまた素敵なのＹＯ！

# ちなみに僕は別に山形ファンとかじゃないですよ。女でもないのにそんな対象にはなり得ないのです。

山形先生、haskellにもっと光を下さい。
あなたなら出来るはず。期待しています。

>>920
んーでも、コンテキストにおいて忠実な訳だから
噛み砕きすぎてると思ったら原文参照すればいい。

Haskellの話を・・・

あったよ
ttp://www-6.ibm.com/jp/developerworks/xml/020208/j_x-matters14.html

>>893
MLってのはMeta Languageの名前通り元々LCFっていう
定理証明系の証明手続きを記述するためのメタ言語として作られたんだから
宣言的な記述というのはむしろ定理の記述でやる仕事だったということかな．
今ならHOLというMLで書かれた定理証明系がその辺の雰囲気を受け継いでいます．

このスレももうすぐ1000だね。
意外に短かったね。

すみませんhaskellのチュートリアルを少し読んだだけで、
あんまりよく分かってないのに何回か書き込んでしまいました。
これからPart�Uまでにちゃんと勉強しておきます。
許してください。

Why People Aren't Using Haskell
http://www.jelovic.com/articles/why_people_arent_using_haskell.htm

何となくだが、比較の対象が違うような気がするなー
HaskellはPerlなんかと同一の方向を目指しているのか？

目指してる方向はもちろん違うだろうけど
でも、充実したライブラリがあったら Perl なんかの代わりに
結構使える気はする。

http://www.pragmaticprogrammer.com/loty/
Haskell が Language of the Year だってさ。
ごく少数の人が勝手に選んだ物らしいけど。

というネタを
http://www.math.tohoku.ac.jp/~kuroki/keijiban/a.html
で見付けた。

わお。Haskellのスレがあるよ。プログラム板に来てみてよかった。

ところで私、多重定義好きなんですけど、
Haskellの多重定義は結局typeclass方式で決まりなんすか？＞事情通

教えて君です。
どなたかParallel Haskell 略して pH というものについてご存知のかたいませんか？

また、Call-by-name(lazy?)とCall-by-need(lenient?)の違いを、知っているかたいませんか？
この２つの違いが、私には良くわかりません。
一様サーチエンジンでも調べたんですけどね。

どなかた心優しい方の返事を待っています。

>>937
Rinshiyur S. Nikhil, Arvind, Implicit Parallel Programming in pH, Morgan Kaufmann, 2001, 508p
という本が出てるそうであります。＞pH

>>937
>>867あたり見れ。
補足としては>>867の graph reduction が Call-by-need ってやつで
いわゆる lazy かと。
lenient ってのは初めて聞いた。
間違ってたら誰かつっこんで。

>>937
http://pc.2ch.net/test/read.cgi/tech/1002584344/741-748

>>938 >>939 >>940
答えてくださって有難うございます。
ヒントは頂けたので、もっと調べてみます。

.NET のことはよく知らないのですが
http://www.mondrian-script.org/
これってどうなの?

「どうなの？」と聞く前に、進んで試して報告すべし。

>>943
自分で試す気がないから「どうなの?」って訊いてるんですよ。
> What You Need
> A Windows 2000 system with .NET Release Version installed.
とか書いてあるし、正直、めんどくさいのです。
そこまで興味があるわけでもないのです。
でもちょっとは興味あるのです。

というわけで、、、どうなの?

Microsoft Visual C++ .NET Standard
これっで作ったソフトって配布OKなんでしょうか！？

そろそろ１０００レスいきそうだね。
そろそろ次スレ行きますか

950さんよろしくage

俺は>>862、>>867、>>876、>>939ではないが、
一応念の為に言っておくと、
call-by-needとgraph reductionは違う概念だ。
graph reductionというのは、グラフ書換えのことで、
計算機科学的には計算モデルの一種といってよいだろう。
それに対して、call-by-needは引数機構の概念だ。
確かにgraph reductionは、
ワークシェアリング等によって大きく特徴付けられはするものの、
それ自体ではない。
でも、>>867の文脈では間違いではない、とは思う。
ただ例えば、
>>862、>>876、>>939のように使われるとなんか意味が変るような気はする。

>>948
あ、そうやね…。
思いっきり変だわ(w

…というわけで、次スレ建てますね。少々お待ちを。

全く同じ名前で立てるのって、どうか知世

…ほんっとごめんなさい。
一応建てましたが、タイトルが同じなので、
自分の名前にパート2宣伝しておきます。鬱。
http://pc.2ch.net/test/read.cgi/tech/1013846140/

原田知世

しかもageてしまった。
風邪ひくとミス多し。鬱。

重複するスレ名あったら弾いてくれたっていいのにね。

>>955
激しく同意ではあるが
そう思ってるならageないでよ…。
いや、まあ、ミスなんでしょが…。

957

958

959

960

961

962

963

964

965

966

967

968

969

970

971

972

973

974

975

976

977

978

979

980

981

982

983 = ｸﾜｻﾝ