関数型プログラミング言語Haskell
レス数が900を超えています。1000を超えると表示できなくなるよ。
0001デフォルトの名無しさん
NGNGHaskellを通じて、みんなで勉強しましょう。
0809デフォルトの名無しさん
NGNGして一応決着がついたが、どうも($!)を使って強制評価させるの
は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
だって。
なんか、よい方法ない？
0810デフォルトの名無しさん
NGNGghci 使ってみた？
0811810
NGNGやはり、だめみたい。10万まではＯＫだけど、100万で
stack over flow
0812デフォルトの名無しさん
NGNG訂正。名前まちがえた。オレは809だった。
１から100万までの整数の総和を求めよ。
ただし($!)やそれを含む関数を使うな。
この問題の解法だれかたのむ。
どうも気になる。
0813デフォルトの名無しさん
NGNGで求められるんじゃないの？
0814デフォルトの名無しさん
NGNGこころは、ハスケルの遅延評価の枠組みの
なかで、メモリー爆発させずに計算できるか
ということなんです。
0815デフォルトの名無しさん
NGNGＨａｓｋｅｌｌのライブラリをながめてみた。
なんかＨａｓｋｅｌｌって天才向けの言語なんだろうかと思えてしまう。
よくそんなこと思いついたよなあ、ということが満載。
0816806
NGNGレスが遅れてすいません。
返事有難うございます。
うーん。
私は英語がにがてなので、紹介してくれた本は読めないかな？
もう少し独学でがんばってみます。
0817デフォルトの名無しさん
NGNGで、おもったのだが、
モナドってどうやって使いこなせるのだろう？
ＣａｔｅｇｏｒｙＴｈｅｏｒｙの知識とかがないと、掴みきれないのだろうか。
なんか凄いとは思ったが、これを使いこなしている自分は思い浮かばないなあ。
0818デフォルトの名無しさん
NGNG0819デフォルトの名無しさん
NGNGモナドを理論的に解説するのは難しいけど。
0820デフォルトの名無しさん
NGNGモナドをつかったライブラリを・・ってことじゃないの？
0821デフォルトの名無しさん
NGNG特に根拠はないけど。
0822デフォルトの名無しさん
NGNGいや，手続き型を先に知った人は誰でもそう感じるんじゃないかな．
わざわざ複雑なことをしたあげく，できるのが手続き型ではごく当り前のこと．
0823デフォルトの名無しさん
NGNGそうかなぁ?
Gentle Introduction の monad のところに載ってるやつぐらいでも
手続き型では結構大変そうな感じが…。
0824デフォルトの名無しさん
NGNG入門の障壁になってるというか、λ教に入信する為の
イニシエーションという感じだね。
Cのポインタみたいに。
Haskellがメジャー言語だったら、書店には
『Haskellモナド完全制覇』とか『秘伝Haskell問答 モナド編』とか
のタイトルが並んでいそうだ。
0825デフォルトの名無しさん
NGNG＞『Haskellモナド完全制覇』
めっちゃ欲しいよ〜。
誰か書いて〜。
0826デフォルトの名無しさん
NGNG>わざわざ複雑なことをしたあげく，できるのが手続き型ではごく当り前のこと．
そう思えるのであれば、まだモナドを深く理解していないと思います。
もし単に手続き型にすぎないなら、モナドを剥き出しにする必要は無く
Ｄｏの糖衣構文で覆ったままにしておけば済むはずですし。
モナドは（私もよくわかっていないが）、それ以外に色々な使い方が可能。
よくわからないが、けっこう不思議な道具なかんじがする。
0827名無しさん＠お腹いっぱい。
NGNGHaskellの場合はまともな処理系はGHCで決まりという
ことになってるのかな？
もしそれならHaskellやってみたいし、GHCを使って
なにか使えるものを作りたい。
0828デフォルトの名無しさん
NGNG藤崎奈々子も使ってる。
第一位な奴な
0829デフォルトの名無しさん
NGNG0831デフォルトの名無しさん
NGNGなんというか、プログラマからみての明らかさというか
そんな感じのものを。
0832デフォルトの名無しさん
NGNG> もし単に手続き型にすぎないなら、モナドを剥き出しにする必要は無く
> Ｄｏの糖衣構文で覆ったままにしておけば済むはずですし。
Monadにdoのsyntax sugarがあるのは、Monadのユーザーは
普通doですべてこと足りるからでしょ。実際、入門の段階でMonadを
扱うときはdoでシーケンシャルな処理が簡単に書けますよ、っていう
例題が普通だし、それを見て手続き型を知ってる人達が、なんでそん
な難しいことをするのかと感じるのは当然でしょう。実際遅延評価のお
かげでストレートにシーケンシャルな評価をさせるのは難しくなっちゃ
ってるわけだし。結局Monadの肝は、順番に評価を実行して、それを
環境に反映させてさらに次の評価に移る、ということを(lawsに従っ
たMonadであれば)遅延評価の枠組を壊さずきちんと実現できる点に
尽きると思います。
doが(>>=)や(>>)Nおsyntax sugarになっている理由はユー
ザが独自のMonadを定義する際に、きちんとlawsに従ったものにさ
せるためですよね。doだけになっちゃたら、Monadクラスの型は定
義できなくなっちゃうじゃないですか。
0833デフォルトの名無しさん
NGNGモナドの処理がdoを使えば手続き型と同じ書き方になるんだなとは
思ったけど、難しいとは思わなかった。同じだと思っただけ。
0834デフォルトの名無しさん
NGNGチュートリにある、計算ステップを制限した手続き型計算とか、
ああいうのをみると凄そうだなと思うな。
0835デフォルトの名無しさん
NGNG不思議で眠れません
0836デフォルトの名無しさん
NGNGスレッドを意識して書かなくても勝手に
ものすごい勢いで計算出来たりするわけ？
0837デフォルトの名無しさん
NGNGなかなか難しいね。馴れが必要かも。
皆さん最初は何で勉強されました？
0838デフォルトの名無しさん
NGNG難しいよね。Haskellは。
0839デフォルトの名無しさん
NGNG東京工科大学のテキストでツカミを得てから、
この本↓を読むのが分かりやすいと思う。
http://www.cs.ukc.ac.uk/people/staff/sjt/craft2e/
手に入れやすいもう一冊の本、『〜THROUGH MULTIMEDIA』の方は
ちょと難しい。
0840エフェドリンながヰ
NGNG/ ／ | ＼ ヽ
/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 / / `::..、ヽ :、
!. / / ``:. :、
0841デフォルトの名無しさん
NGNGマイクロソフトの次期IIS、Haskellで作るられるらしいです！！
とりあえず例題ばかりじゃつまらんだろうから一応。
0842デフォルトの名無しさん
NGNGこれも、Concurrent Haskellなんだね。
この前見たGUI系の奴もConcurrent使ってたなぁ。
0843デフォルトの名無しさん
NGNG無念。
0844デフォルトの名無しさん
NGNGところで、ＭＬに比べてのＨａｓｋｅｌｌの特徴・利点欠点とはなにでしょうか。
0845デフォルトの名無しさん
NGNG良くも悪くも。
理想的には遅延評価によって無用な計算を避けられるはずなんだが、
現実にはHaskellはMLより効率悪い（と云われている）。
0846デフォルトの名無しさん
NGNGStandardMLでは遅延評価は仕様外だが、
独自に装備している処理系も多いッすよ。
遅延評価だけでは両社の差とは言いにくいと思いますが、いかが？
（私はHaskell知らず）
0847デフォルトの名無しさん
NGNG補足、
部分的に遅延にできる機能を、です。
0848デフォルトの名無しさん
NGNGあと関連するがノンターミネーションをなくす為。
無駄をなくすとかじゃないだろ。
理想的にも何も無駄は増えるよ。当たり前じゃん。
0849デフォルトの名無しさん
NGNGこんなもん作ってるとは。
'Quake Haskell'
http://www.dtek.chalmers.se/~d95jowi/quakehaskell/index.html
0850デフォルトの名無しさん
NGNGこれ、何語？読めません（笑
なんとなくは解るけど。
0851デフォルトの名無しさん
NGNG0852デフォルトの名無しさん
NGNGすえーでんじゃないかな。わたしも読めません。
>>846
でもそれがデフォルトにはなっていないでしょう。
わたしはMLを知らないけど、Haskellのプログラミングは、
Schemeで「いつでもdelay/forceを使う」のと同じようなものでは？
もちろんそれとは違ってHaskellのプログラミングは「自然に」そうなるのでしょうけど。
0853デフォルトの名無しさん
NGNG評価する必要のない物を評価しないってことで
多少無駄が減るって話もあるかと。
0854デフォルトの名無しさん
NGNGちがうと思うな．関数型言語を設計するにあたって本当に欲しいのは遅延評価
じゃなくてcall-by-nameでしょ．ただ，工夫しないでcall-by-name
にすると問題が多すぎるから，遅延評価にしているわけで．
0855デフォルトの名無しさん
NGNG遅延評価の意義についてはここに述べられているが？
0856デフォルトの名無しさん
NGNGそれは、遅延評価を採用するとこういう良いこともあるよ、というお話。
0857デフォルトの名無しさん
NGNG全然期待してないけど、すこし数学がわかるようになる副作用を
期待している。
0858
NGNGだからそれはノンターミネーションの話でしょう
0859デフォルトの名無しさん
NGNG違う。call-by-name そのままだと、同じ評価を繰り返すことになりやすい。
それを防ぐため。nonterminationとは全く別の話で、簡単に言えば無駄をな
くす、ということ。
0860
NGNGしかし値渡しからすれば無駄でしょう
0861デフォルトの名無しさん
NGNGそのためのGraphだ
同じ文脈(関数内？)に現れる同じ名前のものは同じものを指すという
参照透明性を利用することで解決している。
同じ名前のものの実態は、１つに共有するようにしている
0862デフォルトの名無しさん
NGNGcall 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と等価だが、
同一式が無駄に複数回評価されるのを防ぐことができる。
0863デフォルトの名無しさん
NGNGで，結局ノンターミネーションとの関係は？
0864デフォルトの名無しさん
NGNG通りかかりです
｜call-by-name , nontermination , call-by-value
｜inner-most reduction, outer-most reduction, graph reduction
もしよろしければでいいんですが、
これらの用語についてぜんぜん初心者である私らに簡単な説明をして
頂けませんか？
0865デフォルトの名無しさん
NGNG遅延評価でnon-terminationを避けることができる。
0866デフォルトの名無しさん
NGNG関数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が採用している。
0867デフォルトの名無しさん
NGNG関数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度きり計算されるのみである。
0868デフォルトの名無しさん
NGNGこのスレの文脈では、
無限リストなど、完全に値を求めようとすると計算が終了しない式を扱う時、
inner-most reductionでは当然、計算が終了しないことになる(non-terminationの問題)。
outer-most reductionやgraph reductionなどにより遅延評価をおこなうことで
無限リストなどのうち必要な部分のみを計算することで、non-terminationの問題を避けることができる。
もちろん、遅延評価ならどんな式でも計算が終了するというわけではない。
0869
NGNG>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となり、余分な計算を避けることができる。
そんなこと言うけど
実際に実装してみたら、値渡しの方が無駄がないよ。
シンプルだし。
0870
NGNGノンターミネーションの為であり、
ひいては無限の為でしょう。
0871デフォルトの名無しさん
NGNG>実際に実装してみたら、値渡しの方が無駄がないよ。
>シンプルだし。
宣言的プログラミングという理想からすると、そのプログラムが
「何を求めるか」だけ宣言すればよく、「どのように求めるか」
はコンピュータに任せることができる、というのがゴールでしょ
う。多少計算に時間がかかっても「その解法が正当かどうか」を
検証する手間を省けるなら、その方が嬉しいことも少なくないだ
ろう？
それは遅延評価と関係あるのかな。
関係あるとしても導入の理由かな？
というか、それは副作用の話では？
0873デフォルトの名無しさん
NGNG0874デフォルトの名無しさん
NGNG0875デフォルトの名無しさん
NGNG>>867
ありがとうございました、勉強になりました。
なんの議論かようやくわかりました。
>>873
個人的にはGHCと関連のライブラリだけでできそうな気がします。
Haskellは、いろんなモノがそろっててすごいと思った。
日本では全然マイナーだから机上の言語と思っておりました。
にしても本当なんでしょうか？
マイクロソフトがHaskellだなんて、ラティンとブッシュが手打ちしたようにも
思えるのは私だけ？
0876デフォルトの名無しさん
NGNG別に副作用だけの話じゃないだろ。
よーするにcall by nameだのreductionの戦略なんてのは
実装上の問題にすぎないわけで、
真に宣言的プログラミングを実現しようとすれば、
そんな事気にしなくてよいほうがいいに決まってるじゃん。
だったら、より安全かつ効率もそこそこいいgraph reductionが
現状では一番理想に近いっつーことでしょ。
0877デフォルトの名無しさん
NGNG次期IISってのはネタかと。
http://www.haskell.org/~simonmar/abstracts/web-server.html
0878デフォルトの名無しさん
NGNG純粋に数学的な関数を実現しようとすると参照透過性って必要にならない？
で、参照透過性って、プログラミング言語ではcall by nameがそうな
んじゃないの？だから実装の問題だけとも言えないような…
0879デフォルトの名無しさん
NGNGcall by nameが参照透明性を保障するわけではない。
参照透明性が保障されていればcall by nameでもcall by valueでも
同じ結果が求まる(ただしnon-terminationは除く)っつーこと。
ちなみにAlgolは手続型言語だがcall by nameをサポートしていた。
0880デフォルトの名無しさん
NGNGじゃ参照透過性はどうやって実現するの？ 例えばHaskellでは、
何が参照透過性を実現するために必須のコンポーネントなの？
0881デフォルトの名無しさん
NGNG強いて言えば、もなーど。 ＃そっか、だから2chで人気なのか...
参照の透明性自体は破壊的代入などの副作用を起こすものや非決定性を
言語やライブラリから排除する事で達成できる。
でもそれじゃ外部I/Oなんかを扱うのに困っちゃうから、関数型言語では
それぞれ工夫して折り合いをつけている。
Mirandaなら無限リスト、Haskelならmonad。
っつーか、武市先生の「関数プログラミング」とか読んでみれば？
0882デフォルトの名無しさん
NGNG全部解けちまったよ。はっはっは。
そらそーだよな。簡単だったもん。
「関数プログラミング」の６章までが範囲でした。
ﾄﾞｷｭｿ学生でスマソ。
現実には、遅延評価はプログラムの正当性を検証しやすくする方向に
働くとは限らないでしょう。
同じことを繰り返すが、
遅延評価とプログラムの正当性の検証しやすさは余り関係ないと思うが。
理想的ともいいきれないと思いますよ。
0884デフォルトの名無しさん
NGNG遅延評価と参照透明性の関係をいう人は、
その例を示して欲しいと思います。
特に正格評価との比較において。
0885デフォルトの名無しさん
NGNGじゃ，なんでHaskellは遅延評価を採用しているの？
0887石敢當
NGNGisFinite :: [a] -> Bool
のような関数というのは簡単に作れるものなのでしょうか。
ちょっと考えてみたりライブラリを調べてみたりしてみたのですが
良く分かりません。何に使うというわけでもないのですが、
なんとなく気になっています。
0888デフォルトの名無しさん
NGNGa. [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]
0889デフォルトの名無しさん
NGNG嬉しそうだな。
0890デフォルトの名無しさん
NGNGなんか直観的にはできなさそうですね。
ちょっと問題を拡大して、任意の表現式のterminationを返す関数について、
任意の式のterminationを返す関数willTerminateが定義できると仮定して
対角線してみたらどうでしょうか？
0891デフォルトの名無しさん
NGNG>>876にはプログラムの正当性や検証の話は全然出てこないのですが。
0893871
NGNGたしかに俺の書き込みはちょっと飛躍があったかも知れない。
それで混乱させたんなら悪いと思う。
正当性について述べたのは「なぜ宣言的プログラミングが必要か」を
述べるためでであり、「なぜ遅延評価が必要か」を直接述べたわけで
はないよ。誤解させたのならすまん。
で、宣言的プログラミングには遅延評価が必要なわけだ。
いつでも遅延評価が必要なわけではないし、
遅延評価ではまずいこともある。
でも、宣言的プログラミングを実現するにあたって、
遅延評価が「不必要」ってことはない。
Haskellは宣言的プログラミングを完全にサポートしているわけではない。
しかし、そこに近づくためのひとつの実験だと、僕は考えている。
とりわけ遅延評価の重要性と問題をともに検証するための実験だと。
その点、MLはぐっと実用上の理由から設計された言語だと思うんだ。
少なくとも宣言的プログラミングを目指してはいないでしょう？
僕はこういう理解で871を書いた。
間違ったことを書いているかも知れない。
それは指摘してください。
でも、書きたかったことはこういうことです。
0894デフォルトの名無しさん
NGNGチューリング機械のエミュレータを関数で作る。
関数は機械の状態遷移図と初期状態を引数にとり、
１ステップおきの状態のトレースをリストで返す。
そうすれば、リストが有限であることと
初期状態から状態を遷移させ、終了状態に至ることは同じになる。
ということはもしisFiniteがあったらチューリング機械の停止性が
判定できてしまう。だが、これはできないことがわかっているので
そもそもisFiniteは書けないと思われ。
0895デフォルトの名無しさん
NGNGこの問題ってrecursiveだけれどenumerableでない典型ですよね．
0896デフォルトの名無しさん
NGNGそりゃそうなんだ。
リスト操作しかできなかったら、そうやって即答できる。
でも無限リストとして定義されている、というところを触れれば判定できてしまう。
できるかねえ？
というかそこまで判定したかったら、リストを拡張してしまえば・・ってそれじゃ
リストの判定ならない？
0897876
NGNG> 多少計算に時間がかかっても「その解法が正当かどうか」を
> 検証する手間を省けるなら、といっているのは、
-----------
値渡しの場合には各引数のcannonical formを求める手続きの停止性を
正当化しなければならない。
遅延評価を使えば、少なくとも各引数の停止性を正当化する必要がない分だけ
「何を求めるか」に集中することができる。
--------------------------
って事だと解釈した。
つまり、遅延評価でのプログラムの検証がどうこうということではなく、
値渡しでのプログラムでは正当化しなければならない事が増える、って事。
あってる？>871
あと、俺はHaskelなどのlazy evaluationを理想とは思っていない。
ただ、値渡しに比べればより宣言的プログラミングの理想に近いとは思う。
0898デフォルトの名無しさん
NGNG0899
NGNGここでの正当性の話というのは正当性のテスト又は
部分正当性の話ではないのか？
ターミネーションの話ならば、私の話とどう違うんでしょう？
0900871
NGNG>つまり、遅延評価でのプログラムの検証がどうこうということではなく、
>値渡しでのプログラムでは正当化しなければならない事が増える、って事。
>あってる？>871
うん。というか、値渡しだと、処理順序を特定することなしに
手続きの停止性は決定できないわけだから、必然的に処理順序
を特定することになる。つまり「アルゴリズム」を記述しなけ
ればいけなくなり、アルゴリズムの正当性を（言語処理系の責
任ではなく、プログラマーの責任において）保証しなければな
らなくなる。つまり、それは宣言的プログラミングではない、
ということだと。
あ、そうでもないか。言語処理系が任意のアルゴリズムの正
当性を決定できれば良いのか。できるのか？
0901899
NGNG0902デフォルトの名無しさん
NGNG>> あ、そうでもないか。言語処理系が任意のアルゴリズムの正
>> 当性を決定できれば良いのか。できるのか？
それはNP完全なのでは？
0903デフォルトの名無しさん
NGNG変更点をコピってきました。
・ 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.
0904デフォルトの名無しさん
NGNG訳せ〜
・・っちゅうか英語を日本語に直す作業くらい私でもできんことはないが、
1.用語を正しく訳せるかあやしい
2.変更点の持つ意義についての解説がさっぱり
ということで、どなたかお願いします。
0905デフォルトの名無しさん
NGNGhttp://www.post1.com/home/hiyori13/buy/buy1.html
この人あんまりプログラミングとかしない人だと思ってたのだが…
つか時期的にアレだな、このスレの影響である可能性も無くもないな。
0906デフォルトの名無しさん
NGNG0907デフォルトの名無しさん
NGNG山形せんせ、いきなりＨａｓｋｅｌｌではなくて、
ＭＬをＵｌｌｍａｎの翻訳本→大堀先生の本で「斜め読み」してからＨａｓｋｅｌｌにしたほうが
いいかもしれないです。
いや、Ｈａｓｋｅｌｌに敵対するつもりはないです。
がっこの先生いわく、ＭＬ（からの）方がやさしいし、関数型でのコードの書き方もわか
って挫折しにくいとか。
いきなりＨａｓｋｅｌｌでくみ出すとコードが書けないこと多しとかで。
＃わたしもこの路線でべんきょしとります。
＃こけた人はこの迂回路を試して見てください。
0908デフォルトの名無しさん
NGNGこらっ！山形！
プログラムのしろーとがいきなりＨａｓｋｅｌｌに取り組んでどうする！
Ｔｃｌ/Ｔｋ【＋Ｃで機能拡張】でもやっときなさい。
いや、結構マジです。
なぜなら、言語内部で戯れていただくより、
アプリケーションで世界と戯れていただきたい。
微妙に絶妙なアプリを作って我々を笑わせてください。
＃Ｔｃｌ/Ｔｋなら、山形著のプログラム解説本が拝めるかもしれないし（笑
レス数が900を超えています。1000を超えると表示できなくなるよ。