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

関数型プログラミング ..

310:デフォルトの名無しさん
08/07/02 02:44:41
中身読めるよ
URLﾘﾝｸ(book.realworldhaskell.org)

表紙が決まったんだね。ヘラクレスオオカブト？

311:デフォルトの名無しさん
08/07/02 03:40:51
後の兜本である。

312:デフォルトの名無しさん
08/07/02 22:40:44
オライリーからHaskellの本が出るなんてありえない。
そう思っていた時期が僕にもありました

313:デフォルトの名無しさん
08/07/02 23:40:42
2008/09
ちょおまｗ

314:デフォルトの名無しさん
08/07/04 04:55:50
>>310
全30章中残りは3章。
20. The foreign function interface
27. Profiling and tuning for performance
30. A concurrent RESTful web application
書きにくそうなのが残った感じｗ

315:デフォルトの名無しさん
08/07/09 08:14:01
初心者用のスレで関数型の話をすると罵られる。なぜだろう。

316:デフォルトの名無しさん
08/07/09 12:30:55
初心者には関数型が高尚すぎて理解できないからです。

317:デフォルトの名無しさん
08/07/09 22:36:35
しつもんです
らむだけいさんってなんですか？

318:デフォルトの名無しさん
08/07/09 23:38:52
世界遺産の一種です

319:デフォルトの名無しさん
08/07/09 23:44:40
URLﾘﾝｸ(wwwfun.kurims.kyoto-u.ac.jp)

320:デフォルトの名無しさん
08/07/10 05:32:31
全部ひらがなだとぱっと見、人名かなんかかと思った。羅武田圭さんとか。

321:デフォルトの名無しさん
08/07/10 16:58:13
俺がムラタだ

322:36 ◆K0BqlCB3.k
08/07/11 01:58:31
URLﾘﾝｸ(hackage.haskell.org)
とっとと仕事しろやボケ

323:デフォルトの名無しさん
08/07/11 09:38:42
まあ遅延評価だから

324:デフォルトの名無しさん
08/07/11 10:04:21
等無駄計算

325:デフォルトの名無しさん
08/07/11 16:03:12
>>322
なにエラソーに言ってんだよ。しょーもない評論家なくせして。

326:デフォルトの名無しさん
08/07/19 00:59:56
名村啓？

327:デフォルトの名無しさん
08/07/20 23:31:18
do記法で

'aとか''aとか出てきますが
どのような意味なのでしょうか

328:デフォルトの名無しさん
08/07/21 01:16:27
>>327
具体的なコード書いてみて

329:デフォルトの名無しさん
08/07/21 15:09:50
>>327
a'とかa''じゃなくて？
ちなみにそれならただの変数名だよ。

330:デフォルトの名無しさん
08/07/21 15:13:03
>>329
見直したらそうでした
許してくださいｗ
ごめんなさい

331:デフォルトの名無しさん
08/07/21 23:32:45
\_ -> k

この\_ってC++のtemplate <t>みたいなもんですか？

332:デフォルトの名無しさん
08/07/21 23:38:07
全然違います

333:デフォルトの名無しさん
08/07/21 23:43:54
>>332
じゃあ何なのでしょうか？

334:デフォルトの名無しさん
08/07/21 23:55:35
URLﾘﾝｸ(www.codelogy.org)
ていうかなんか一冊入門書買うことをおすすめする

335:デフォルトの名無しさん
08/07/22 01:00:32
なんか夏まっさかりって感じ？

336:デフォルトの名無しさん
08/07/22 01:40:52
質問の仕方スレもいるな
Haskellでぐぐっていくつか読めばわかるぐらいのことで
これって型でしょ
違います
じゃあなんなんだよ
つ　やさしいHaskell入門

337:デフォルトの名無しさん
08/07/26 19:44:30
おい、おまえらの仲間が「初心者のための～」スレで暴れてるから早く回収してくれ

338:デフォルトの名無しさん
08/07/26 20:22:33
狂犬に噛まれて狂犬が増えるって
怖くね？

339:デフォルトの名無しさん
08/07/27 01:34:24
あれは仲間じゃない

340:デフォルトの名無しさん
08/07/27 02:01:40
そもそもスレタイからして興味ない話だし。
向こうで完結して。

341:36 ◆K0BqlCB3.k
08/07/27 02:23:52
さて、この夏、何かおもしろいことでもしようかな。

342:デフォルトの名無しさん
08/07/27 10:47:30
お前らの中にアホがいます
他のスレを荒らすならここを荒らしますよ？

343:デフォルトの名無しさん
08/07/27 12:10:53
>>342
ほー、やってみてください。本当にできるのですか？

344:デフォルトの名無しさん
08/07/27 13:11:28
夏厨誕生物語

A　「この夏、何かおもしろいことでもしようかな。」
B　「ならスレ荒らししてみれば？」
A　「簡単にできるのですか？」
B　「こうやれば邯鄲」
A　「ネ申ｷﾀｰ！㌧！ﾏｼﾞ面白いね。他スレ荒らしてｸﾙｰｗｋｔｋ」

345:デフォルトの名無しさん
08/08/06 05:48:39
注目ワード“高階プログラミング”って何だ？
URLﾘﾝｸ(ascii.jp)

346:デフォルトの名無しさん
08/08/06 06:00:24
>>345
面白かった。サンクス。

347:デフォルトの名無しさん
08/08/06 19:32:59
仕事でHaskellできるなんて羨ましいなぁ。

348:デフォルトの名無しさん
08/08/06 20:30:02
>>345
nobsunだね。

349:デフォルトの名無しさん
08/08/06 20:47:23
ハイカラなシャツ着てる

350:デフォルトの名無しさん
08/08/06 22:06:03
この会社ってホームページ見た感じ普通のSI会社に見えるけど、
山下さんなんかがいるってことは特殊な会社？

Haskellの開発コンサルということだけど、一般企業の業務システム
なんかを対象にしてるのかな。金融系とか合ってそうだけど、
普通の土方システムには豚に真珠かな。

351:デフォルトの名無しさん
08/08/06 22:30:36
>>350
看板役みたいなものだよ。
よくあること。
SRAでも青木淳みたいなのを雇っているけど、青木は普通の仕事はしていないね。
金にならないことを自由にやっているって感じ。
ちなみに、青木の部下はかわいい女の子限定。

352:デフォルトの名無しさん
08/08/07 05:56:03
まあ、天才ならなんでも許されるってことだ。

353:デフォルトの名無しさん
08/08/07 07:30:34
>>351
青木はSRAやめたよ

354:デフォルトの名無しさん
08/08/07 08:39:56
>>345 nobsunのコードは以前からスゲーと思ってたけど、こんな会社のこんな人なんだ。知らなかった。
会社の事業だけ見ると、Haskell関係なさそうだね。Higher Order Programmingってなんだ？造語か？
もっと記事をよく見てみる。

355:デフォルトの名無しさん
08/08/07 08:55:02
>>354
ちょ、おまwww

356:デフォルトの名無しさん
08/08/07 09:12:13
Higher Order Programming: プログラミングを丸投げするためのプログラムを書くこと

357:デフォルトの名無しさん
08/08/07 09:45:57
継続ベースのWebフレームワークってHaskellにもありますでしょうか。

358:デフォルトの名無しさん
08/08/07 12:53:37
>>350
あそこって、gaucheかんけいなひとがおおそうなんだけど。

359:デフォルトの名無しさん
08/08/07 12:58:00
>>358
そりゃそうだ。普通のJaverやC++マが金を取ってこなきゃ、
みんなgaucheとかに走ったら誰が食い扶持を稼ぐんだって。

360:デフォルトの名無しさん
08/08/07 13:19:40
二等兵には二等兵の仕事があるわな。

361:デフォルトの名無しさん
08/08/07 13:46:18
むしろ、パンダと飼育員。

362:デフォルトの名無しさん
08/08/07 13:54:11
俺はまだ士官候補訓練兵だ

363:デフォルトの名無しさん
08/08/07 16:12:52
あの写真を見て
小野伸二を思い出したんだけど。nobsunはやっぱり天才なんですかね。

364:デフォルトの名無しさん
08/08/07 19:03:09
俺は山田ルイ53世を思い出した。すまん＞nobsun
ルネッサ～ンス!

365:デフォルトの名無しさん
08/08/07 19:05:14
あの芸人、この前番組内であからさまにいじめられてたぞ。
最近テレビの前で普通にいじめる先輩芸人が多くないか？

366:デフォルトの名無しさん
08/08/07 19:55:17
そんなことより「Real World Haskell」の発売が10月に延びてる・・・

367:デフォルトの名無しさん
08/08/07 20:41:53
URLﾘﾝｸ(book.realworldhaskell.org)

にある最終章、「A concurrent RESTful web application」が読みたいんだけど、
これは本買わないとダメってこと？

368:デフォルトの名無しさん
08/08/07 21:15:32
最近少しずつ読み進めていたんだが
そうか、本になるのか…買おうかな＞RealWorldHaskell

369:デフォルトの名無しさん
08/08/07 23:21:20
RealWorldHaskellってHaskellの批判本なのに
なんでみんな買うの？

こんなにHaskellって腐ってます
ゴミですって随所に書かれているのにw

370:デフォルトの名無しさん
08/08/07 23:24:06
買おうかなと言ったのが一人いるだけなわけだが
脳内カウンターが回りまくりですかな

371:デフォルトの名無しさん
08/08/08 00:09:00
ん？批判本なんだ？

372:デフォルトの名無しさん
08/08/08 00:12:48
そう思っている人がいるかどうかは定かではないですが、
そう書き込んだ人間が一名いるようです。
また、買おうかなと書き込むことと買うことは別です。
プログラマたる者、このくらいの論理性は持って欲しいです。
部分と全体を混同するなんて、継承に毒されすぎです。

373:デフォルトの名無しさん
08/08/08 02:02:00
>>372
論理じゃなくて、揚げ足取りっていいませんか？
買おうかなと書き込んだということは、買う意思が比較的強いということでしょう。
0か1かじゃないんですよ。
物事は確率的なのです。

374:デフォルトの名無しさん
08/08/08 02:42:06
>>373
> 買おうかなと書き込んだということは、買う意思が比較的強いということでしょう。

著作権者や出版社勤務者が宣伝のために書いたかも知れませんよ

375:デフォルトの名無しさん
08/08/08 02:42:51
>>374
そういう可能性もある。
確率の問題。

376:デフォルトの名無しさん
08/08/08 02:50:39
>>369
ソース

>>370
君が一人しか見てないだけ

377:デフォルトの名無しさん
08/08/08 03:20:20
>369
>Throughout this book, we're going to show you how Haskell's
alternatives to the features of traditional languages are more
powerful, more flexible, and safer. Haskell is positively crammed
full of cutting edge ideas about how to create great software.
(chap1 power)

と最初のところでかいてるけど、なぜ批判本と?
どこをさしていってるの？

378:デフォルトの名無しさん
08/08/08 03:22:29
なんとなくpractical common lispのhaskell版と言う印象なんだけどな。
オレイリーから関数型言語ぼんが出るのは初めてじゃ内科?
国内ではgauche本があるがね。

379:デフォルトの名無しさん
08/08/08 03:42:03
フランスではocamlの本が出てた

380:デフォルトの名無しさん
08/08/08 11:58:00
washって継続ベースなの？

381:デフォルトの名無しさん
08/08/08 14:34:11
>>379マジだ
URLﾘﾝｸ(www.amazon.fr)
フランスでは流行ってるんだな

382:デフォルトの名無しさん
08/08/08 14:42:46
感覚的には日本のRubyと同じ感じじゃないすかね。

383:デフォルトの名無しさん
08/08/08 16:16:02
>>381
いつの本の話してんだか。
この本の和訳プロジェクトはつぶれたね。

384:デフォルトの名無しさん
08/08/08 19:15:39
>>382
全然違う。Rubyは世界的にPythonを急追している。

385:デフォルトの名無しさん
08/08/08 23:55:14
急追して、、いたけど結局ダメだった、というのが現在のところだよ
俺も1.9がちゃんとしたモノになるまではrubyは使うべきではないと思う。

386:デフォルトの名無しさん
08/08/08 23:59:16
そうか？
そもそも本当に10月に発売できるか分からんぞ。

387:デフォルトの名無しさん
08/08/09 00:21:55
コレすでに3回発売日伸びてる
年内出れば御の字

388:デフォルトの名無しさん
08/08/09 00:33:37
>>385
それがほんとかなぁ。とおもってgoogle trendsでruby,python,perlの検索数を比較させて
みたけど、国によって微妙に違うね。
usaなら、2006ねんごろからperlが凋落しきって、python,rubyとならんで、2006中頃から、
rubyが一歩抜けて、perl,pythonが同等になっていた。

italyは、同じような時期にperlが落ちてきてるけど、pythonがかなり強くって、perlとruby
が同等

japanが、perlの凋落が進んできてるけど、usaやitalyほどではなくて、一番ですね。2番め
がrubyで徐々に増えてる。pythonは完全に横ばい。

chinaはpythonの伸びがかなり強い。そんなにrubyは使われてない。
indiaは日本と傾向が似てるな。
israelはrubyは絶滅ぎみ。
google全体ではrubyが一番強くなってきてるけど、これはusaでのruby人気が支えてる
ような感じだな。europaとchinaではpythonが強く、それ以外の国ではperlが強いかな。

389:デフォルトの名無しさん
08/08/09 04:23:59
>>384
世界的にみても、わかって言語を選んでいる人よりも
バズワード追ってるだけの人のほうが多いからね。

390:デフォルトの名無しさん
08/08/09 06:09:31
Haskellって本当にLLって言っていいのかな。
基本コンパイラだし、インタプリタも軽量とは言い堅いし。。。

391:デフォルトの名無しさん
08/08/09 06:13:31
LLじゃないだろw

392:デフォルトの名無しさん
08/08/09 08:06:03
> 基本コンパイラだし
GHCばかり取り上げられてHugs涙目

393:デフォルトの名無しさん
08/08/09 08:07:11
>>392
そんなあなたをはぐはぐ。w　あーっ！ではないよ。

394:デフォルトの名無しさん
08/08/09 08:22:00
初心者なんですが、Haskellが型については静的であることを選択した
理由って何かあるんでしょうか。純粋であることや遅延評価が、静的
型やコンパイル時の最適化を要請するということなんでしょうか？

395:デフォルトの名無しさん
08/08/09 08:27:55
GHCはHaskell解釈系ランキング第一位！

「やっぱりGHCだね」

396:デフォルトの名無しさん
08/08/09 09:06:49
>>394
静的なのは、最適化も大きいだろうけど、
むしろ安全性を狙ってるという要素が大きいんだろう。

遅延評価なのはコンパイル時の最適化にプラスなのかなぁ？
これは理論的に停止できる関数は必ず停止できるっていう、
これまたある種の安全性？が主な目的だと思うけど
( if true (answer foo) (nonStop baa) ) みたいな文を考えよう（Haskellの文法忘れたから適当）。

397:デフォルトの名無しさん
08/08/09 10:14:15
別に"動的型付け-純粋-非正格-インタプリタ型"の関数型言語もあり得るよな
効率はどうなんだろう、"動的型付け-正格"の言語よりさらに遅いことは想像が付くが

398:デフォルトの名無しさん
08/08/09 10:28:23
>>394
Goferがそうだったから。
で、なんでGoferがそうだったのかというと、Mirandaがそうだったから。

399:デフォルトの名無しさん
08/08/09 10:37:45
>>396
遅延評価は最適化にマイナスだよ。少なくともメモリ空間の最適化には全く向かない。

400:デフォルトの名無しさん
08/08/09 10:44:26
遅延評価なんて
今日はやらない

401:396
08/08/09 10:50:37
>>399
そうだよね。
コンパイル技術がすげー発達して高速になれば、話は変わるだろうけど。
（まぁ、コンパイル技術が「すげー発達」すれば、どのコンパイル言語でもマシン語と同じスピードが出るんだから、意味ない話）

あと「理論的に停止できる関数は必ず停止できる」は意味不明だとか、
文じゃなくて式だとか、気づいたけど後の祭り、いわゆるアポステオリorz

402:デフォルトの名無しさん
08/08/09 11:02:51
>>395
Guarded Horn Clauses

403:デフォルトの名無しさん
08/08/09 11:31:02
手続き型言語は、ノイマン型計算機を抽象化することで生まれてきたので、
評価方式としては、式、文の逐次的解釈が当然になる。

関数型言語は、ラムダ式から出て来たから、
その評価形式をどうするかというのが一つのポイントになる。
遅延評価は最左最外簡約の研究から出て来た。

効率がどうのこうのというより、
新しいプログラミングパラダイムを産み出したので、
(例えば無限リスト、無限木の積極的利用)
研究され続けているんだと思う。

404:デフォルトの名無しさん
08/08/09 11:32:55
>>402
GLOBAL HONORED CROWN URLﾘﾝｸ(www.noah.co.jp)

405:デフォルトの名無しさん
08/08/09 11:37:31
関数型とか意味がない言語だと思うけどねぇ
何ができるってわけでもないし
HaskellでWindowsは作れないしLinuxも作れない
Webサーバも作れないしDBも作れない
意味がない

406:36 ◆K0BqlCB3.k
08/08/09 11:44:54
>>405
URLﾘﾝｸ(www.thenewsh.com)

407:36 ◆K0BqlCB3.k
08/08/09 11:45:52
ごめん、今からインディージョーンズ見に行くから急いでるから！

408:デフォルトの名無しさん
08/08/09 11:47:37
まあ普通はモデルを現実に合わせるよな。
代入だらけのプログラムをSSAとかいう形式に変換するとか。

409:デフォルトの名無しさん
08/08/09 11:48:09
>>394
純粋関数型言語・遅延評価で、
型なし・インタプリタ言語ってあるよ。

変態言語 Lazy K がそれ。
ある意味では Make とかもそうかも。

少なくとも、
純粋関数型言語・遅延評価と、
コンパイル言語かインタプリタ言語か
っていうのはあまり関係ない。

純粋関数型言語・遅延評価は、
シンプルな手続き型よりもインタプリタを書くのが難しい、
っていうのはあるかもしれないけど。

純粋関数型言語であることと静的型であることは、少し関係があるかも。
純粋関数型言語でかつ動的型というのは、概念的にあまり良い食い合わせではないとは思う。

動的型っていうのは、関数の世界では「型無し」ってことになると思うんだけど、
いずれにせよアドホックなエラー処理が必要になって、
純粋関数型的にアドホックなエラー処理というのは少なくとも美しくない。

410:デフォルトの名無しさん
08/08/09 12:17:29
>>409
遅延評価でインタプリタ。破壊的関数が作れないというものなら、R言語くらいしか知らない。

411:394
08/08/09 12:56:14
皆さんレスありがとうございます。

論理的に組み合わせ悪いというよりは、静的型のメリットを選んだ
ということなんでしょうか。

静的型VS動的型というのは、安全VS自由ということだと思うんですが、
Haskellは安全を選んだということなのかな。純粋関数型としては、
副作用に関連する不具合から自由なのが売りだと思うので、更に
静的型によって徹底的に信頼性を上げてるという感じなんでしょうか。

>>409
純粋関数型であること(参照透明であること)と動的型が食い合わせ
悪いというのがちょっと分かりませんでした。動的型は実行時不具合
の問題が付きものと思うのですが、参照透明との関係をよろしければ
少し詳しく教えていただけマスでしょうか。

412:デフォルトの名無しさん
08/08/09 13:08:18
そもそも関数型言語に意味が無い

413:デフォルトの名無しさん
08/08/09 13:13:08
>>411
動的型を使うと、アドホックなエラー処理が必要になるよね？
っていうか、それがないと動的型を使ううまみがないと思うんだけど。

ここでいうアドホックなエラー処理っていうのは、
対象オブジェクトの型をプログラムで認識して、
意図しないオブジェクトが来たときにエラー処理するってことだけど。

このエラー処理にIOを使わないなら、
それは多相型やクラスを使っても同じ結果が得られるよね。

だから、Haskellに動的型を組み込む必要性は、
意図しないオブジェクトが来たときIOを使ったエラー処理をしたいときに限られると思う。

で、純粋関数型言語は参照透明性ゆえにIO処理するの苦手。

まぁ、動的型っていうのはプログラム中で型を認識できないと意味ないよね？
っていう時点で、カリー・ハワード対応との関係で微妙っていう気にするけど。

僕が考えているのは、そんな感じ。

414:デフォルトの名無しさん
08/08/09 13:17:44
上っ面を語り合って自己満足か
Haskellに多いやつらの典型だなｗ

415:デフォルトの名無しさん
08/08/09 13:18:59
グリーンスパンの第10法則が発動すると、どんな言語で書こうと
動的でマルチパラダイムな言語で書いたのと同じになる。

416:394
08/08/09 13:33:07
>>413
なるほど、理解しました。ありがとうございます。

417:デフォルトの名無しさん
08/08/09 13:50:48
>>405
せいぜい生きる力を養ってください

418:デフォルトの名無しさん
08/08/09 13:54:52
>>416
implementationの本を読むといいよ
Peyton Jonesのがpdfで読めるはず

419:デフォルトの名無しさん
08/08/09 14:11:34
>>418
俺はPJのが好きだな。
静的型付けとグラフ簡約が運命的な出会いであることがわかった。

420:デフォルトの名無しさん
08/08/09 14:19:55
>>413
なんか議論が無茶苦茶じゃないか？
例えば「型エラー」を「0除算エラー」に置き換えても論理展開が変わらん

>このエラー処理にIOを使わないなら、
>それは多相型やクラスを使っても同じ結果が得られるよね。
動的型の重要な利点は、型をいちいち書かなくてもいいという利便性だよな
多相型やクラスを使って動的型をシミュレートするのはすごく面倒だから、この利点を享受できない

それから、GHCではerrorやundefinedで発生したエラーをIOモナド上で捕捉できる。念のため

421:デフォルトの名無しさん
08/08/09 14:26:59
だな。Haskellの例外処理で不足があることはそうそうないと思う。
あと、動的型のメリットを例外処理だけに限定するのは視野が狭すぎる。
LISPのメリットはアドホックな例外処理か？そうじゃないと思う。

422:デフォルトの名無しさん
08/08/09 14:39:32
>>420-421
納得できないのなら、それで良いです。
僕も、べつにそんなに優れた論拠だと思ってないから。

423:デフォルトの名無しさん
08/08/09 14:55:35
俺も>>413はひどい文章で内容もないと思う。
>>416が理解したのが驚愕。

424:デフォルトの名無しさん
08/08/09 15:20:10
本当だ、マジで何言ってるのかわからん
すげえ

425:394
08/08/09 15:22:47
動的型のメリットは型を単に書かなくて済むことだとは思えないんですが。

それだけであれば、コンパイルで発見する不具合をテスト時に見つけよう
とする、つまり面倒なことを後回しにしてるだけ、ってことになりませんか？

426:デフォルトの名無しさん
08/08/09 15:23:15
別に動けばいい

427:デフォルトの名無しさん
08/08/09 15:30:45
何でも指せるポインタってのはメチャ便利なんですよ。
S式なんて最たるもので、静的な型付けは不能あるいはワイルドカード的。
静的か動的かはトレードオフの問題。

428:デフォルトの名無しさん
08/08/09 15:42:04
>>425
不具合を見つけるタイミングが遅くなるという対価を払って、記述の利便性および変更の容易さという報酬を得る
ちゃんと取引として成立してるじゃないか

もちろん「型を書かなくて済む」こと以外にも利点はある
特定の静的型付け言語ではそもそも型を付けられないようなコードが許容されるとか

429:デフォルトの名無しさん
08/08/09 17:38:51
>>425
lispを使ってる限りの印象だが
都合のよい所だけ型宣言が出来るというのは柔軟性につながるかな。
プログラムの最適の仕方も静的/動的で違いがあると思うよ。
型なんで考えずにアルゴリズムだけ作っちゃえができるからね。
それでも型を意識したプログラミングをすることはあるが。
でも、haskellでもポリモつかえばある程度型無視ラピッドプログラミング
は可能じゃないか?

430:デフォルトの名無しさん
08/08/09 17:41:42
じゃあOCamlでいいじゃん

431:デフォルトの名無しさん
08/08/09 17:44:14
>>430
haskellって参照透明性ってかなりのメリットだと思ってるけど。

432:デフォルトの名無しさん
08/08/09 17:49:41
注意してかけばいいだけの話
Hashkellはメリットを殺すデメリットしかないだろ

433:デフォルトの名無しさん
08/08/09 17:56:37
正直、exists型が標準になれば動的型付けは不要じゃね？
URLﾘﾝｸ(en.wikibooks.org)

434:デフォルトの名無しさん
08/08/09 17:57:26
>>430
OCamlはstrictだから。残念。

435:394
08/08/09 19:55:26
>>428
コンパイル時に問題が抽出されることと、テストによって抽出されるのでは
質的な違いがあるんじゃないですか？テストは結局は人間がやるものだし、
不具合の可能性を低めるということにしかならないけど、コンパイルでの
不具合検査は対象となるプログラムの論理的正しさを証明していることに
なるかと思います。

容易に変更ができたとして、不具合がどこに潜んでいるのか分かりにくい
というのは非常に問題あると思いますよ。コンパイルで分かるのならば、
これは明白でしかも機械的に全てが晒されますから安心です。

436:デフォルトの名無しさん
08/08/09 20:20:59
Rubyは危険だしセキュリティリスクしか
そんざいしないしな

437:デフォルトの名無しさん
08/08/09 20:23:09
>>435
確かに、バグがどの段階で発見されるかには質的な違いがある
でも、静的な型検査だって全てのバグを検出できる訳じゃないから、
結局、動的検査との安全性の違いは程度問題

その上で、静的な型検査の利点がコストを上回るという判断は当然ありえるし、
そう判断したなら静的型言語を使えばいい

438:デフォルトの名無しさん
08/08/09 20:28:12
>>435
静的型チェック馬鹿ですやん

439:394
08/08/09 20:39:50
>>437
例えば、参照透明ということについてはどうでしょうか？こちらも、副作用を許容
すれば、プログラム中に登場する変数の中身が何に変異しているかどうかが
分からなくなり、実行してみないと問題が検出できない、ということになります。

参照透明を強要するのも、型を強要するのも、結局その辺がクリアできない
プログラマというのはそれらに関連する不具合を出してしまうんだと思いますが
どうでしょうか。気をつければいい、というのは簡単で規模が小さなシステムでは
言えることで、そうでなければ膨大なテスト工程が必要になってしまうのでは？

440:デフォルトの名無しさん
08/08/09 20:46:48
OCamlが参照透明じゃないから嫌ってどういう事を言ってるの？
refとかで破壊的な変数が作れるから嫌とかそういうレベルの話じゃないよね。

それだったらref使わなければいいだけだから。
逆に、Haskellの参照透明で良い所ってどのへんなの？
OCamlのでも、ErlangのでもなくHaskellの参照透明性が良い理由を説明してほしいんだが。

441:394
08/08/09 21:04:32
>>440
参照透明でない、ということは値が望んだ通りの値であることを
保証するためにどこまでも神経質にテストをしなければならない、
ってことですよね。

一人で開発するのであればいいですが、多くの人の手によって
間違いがあってはならないシステムの開発をする際、「それは
禁じ手だから止めてね」と口約束するだけってのは非常に怖い
わけです。だからこそ、テストの工程が膨れ上がる。

Haskellに自分が惹かれている大きな理由の一つは、この辺の
頑固さを貫いていることですね。

442:デフォルトの名無しさん
08/08/09 21:19:02
参照の透明性があれば、
それだけでテストが必要なくなるわけでも、
テストが簡単になるわけでもない。
そうなるのはトイプログラムだけ。

嘘だと思うなら、GHC, Hugsなどのバグトラックをみてみればいい。

443:デフォルトの名無しさん
08/08/09 21:21:51
テストが減ることを数学的に証明してみせれ。

444:437
08/08/09 21:22:55
>>439
何が言いたいのか良く分からん
俺は「気をつければいい」なんて一言も言ってないよ
>>428に書いたように、動的か静的かの間でトレードオフが成立すると言っているだけ

>>441
OCamlの変数は変更不可だよ
変更できるのは参照(ref)で、これは変数とは別物
だから、口約束するまでもなく変数の値が変わらないことは保証されてる

445:デフォルトの名無しさん
08/08/09 21:26:07
>>440
参照透明性を壊さないと入出力できないのが嫌

446:36 ◆K0BqlCB3.k
08/08/09 21:37:36
>>443
数学的に無理だから、統計的に証明するわけですよ。
実際に～～でした、ってね。

ヒューマンインターフェース系の論文が参考になるんじゃないかな。
あっちは全部そんな感じ。

447:デフォルトの名無しさん
08/08/09 21:38:56
>>441
Haskellでもやろうと思えばIORefとかで事実上破壊的な操作が可能になるわけですが、
これについてはどうお考えで？

「HaskellでIORefは使うな」っていうプログラミングルールを設定することは
「OCamlでref使うな」っていうルールを設定することと本質的に違わないと思うんだけど
それについてはどうなんすか。

448:36 ◆K0BqlCB3.k
08/08/09 21:40:14
インディージョーンズ、あれは予算が無いからあんなにちゃっちい水晶髑髏なのか？
どう見てもアクリル製のガワの中に反射板入れただけやん。
UFOとかエイリアンとか、考古学じゃなくてSFやん。
突っ込みどころ満載な映画でした。

かしこ

449:デフォルトの名無しさん
08/08/09 22:13:11
monadとラムダの簡単な練習いっぱい
したいです。どこがいい問題集頂戴

450:デフォルトの名無しさん
08/08/09 22:23:39
>>449
do記法を使わずにliftM、liftM2、joinを実装
Continuationモナドを実装

451:36 ◆K0BqlCB3.k
08/08/09 23:30:03
>>450
また何も考えずにそういうこと言う。

>>449
URLﾘﾝｸ(ja.doukaku.org)

452:36 ◆K0BqlCB3.k
08/08/09 23:31:04
英語が読めるなら
URLﾘﾝｸ(projecteuler.net)

453:デフォルトの名無しさん
08/08/10 05:05:51
>>451
モナドとλの練習なら>>450はいい案じゃないか。
いっぱいじゃないけど質的にいい。

454:デフォルトの名無しさん
08/08/10 05:08:55
そんなことが書きたいんじゃなかった。

>>419
PJのって何？本もpdfもPJのでしょ？

455:デフォルトの名無しさん
08/08/10 08:02:29
PJは
Implementation of Functional Programming
Implementing Functional Languages,(D. Lesterと共著)
を書いていて両方公開。
URLﾘﾝｸ(www.haskell.org)

456:デフォルトの名無しさん
08/08/10 08:05:37
>>449
URLﾘﾝｸ(www.haskell.org)

457:デフォルトの名無しさん
08/08/10 13:23:16
>>454
すまん、>>455のImplementing...のほうを言いたかった。

458:36 ◆K0BqlCB3.k
08/08/10 13:39:12
>>453
>>449は本当にモナドとラムダの練習のためだけに問題をほしがっているのかどうかってこと。
それに、初心者は何か目に見えて動かせるものを書きたがるものさ。
誰かに見られることを想定して書くのと、「動けばそれでいい」だけで書くのとでは、
やっぱり前者の方がいろいろ調べたりすることで勉強になる。

459:デフォルトの名無しさん
08/08/10 15:23:20
>>455
そこ載ってなくね？ｗ
URLﾘﾝｸ(research.microsoft.com)
URLﾘﾝｸ(research.microsoft.com)

>>457
サンクス。目次しか見てないけど、
Implementationがパターンマッチや型など広く扱ってて、
Implementingはコンパイラのコアな部分を主に扱ってる感じ？
静的型付けとグラフ簡約の運命的な出会いというからそうでもない？
まあImplementingのほうを読んでみます。

>>458
そうですね。

460:デフォルトの名無しさん
08/08/10 16:23:15
載ってるよー

グラフ簡約と運命的な出会いというと遅延評価じゃないかね。
特にPJ的には。

461:419
08/08/11 14:41:51
>>460
まあグラフ簡約は前提として、それを効率的に実装するには静的型付けがイイんだよ、
と、約20年前に読んだ時に思った。

462:419
08/08/11 14:44:37
20年前じゃなくて15年前だった。かなり記憶が混乱してるな、俺 orz

463:デフォルトの名無しさん
08/08/11 16:05:22
>>461
あまり理解できてなかったんじゃない？w

464:デフォルトの名無しさん
08/08/11 16:13:31
>>463
かもしれない。
できれば君が読んでポイントだと思ったところを挙げてくれると皆の参考になると思う。

465:デフォルトの名無しさん
08/08/11 16:20:35
PJの最初の本だと、
例え動的型チェックをやろうとも、そのコードは、
他の普通のコードと一緒でスーパー・コンビネータになって、
グラフ簡約されるだけだから、コンパイル時に型チェックを済ませることが、
スーパー・コンビネータのグラフ簡約上、特に有利だとは思えません。

466:デフォルトの名無しさん
08/08/11 17:39:55
横から口はさんですまんが、静的型がついていたほうがパターンマッチが速くならね？

467:デフォルトの名無しさん
08/08/13 09:02:33
Haskellの継続ってSchemeとは違いありますか？

468:デフォルトの名無しさん
08/08/13 10:48:15
call/cc のようなものはありません

469:デフォルトの名無しさん
08/08/13 11:17:46
>>468
MonadCont の callCC :: ((a -> m b) -> m a) -> m a のことじゃないの。

>>467
俺も気になる。違いはあるだろうけど、どう違うのか。

470:デフォルトの名無しさん
08/08/13 11:23:16
やっぱりそうですか。継続ベースのアプリ
作るとしたら、ステートモナドに次のアクション
入れておくとかですかね。

471:デフォルトの名無しさん
08/08/13 13:45:50
MonadContだと、型の関係で、無限ループするような式は書けない。
# mfixとか使えば別だけど。

例えば、Schemeで次の式は書けるが、MonadContでは書けない。
(call/cc (lambda (c) c))
(call/cc (lambda (c) (set! foo c)))

つまり、次の式は型が付かない。
callCC (\c -> return c)
callCC (\c -> lift $ put c)

要は、callCCで捉えた継続をそのcallCCの外に出せない。ただし、
callCC (\c -> ... callCC (\c' -> c c') ...)
のように、内部で別のcallCCを使って、それで捉えた継続を外に出すのはOK。

あと、変な例として、
callCC (\c -> return (Right (c . Left)))
はOK。でもやっぱり無限ループはできない。

472:デフォルトの名無しさん
08/08/13 14:58:55
>>471
だとすると、smlのcall/ccを使ったco-routineみたいなことはできないということ？

473:デフォルトの名無しさん
08/08/13 17:43:19
smlのcall/ccを使ったco-routineは知らないけど、co-routine自体はできる。

import Control.Monad.Cont

foo = callCC (\c0 ->
do
c1 <- callCC c0
c2 <- callCC c1
c2 10
undefined)

bar =
(do
c1 <- foo
c2 <- callCC c1
callCC c2)

main = print $ runCont bar id

474:デフォルトの名無しさん
08/08/13 18:18:41
>>471
HaskellでYコンビネータを書くとき型が問題になるけど、
実質的には fix f = let g = f g in g で問題ない。
それと同じように、
loop = callCC (\c -> let g = c g in return g)
とすれば
do { l <- loop; liftIO $ print 0; l }
のように無限ループを書ける。
(これの変数付きループ版が MonadLib にあった。)
(call/cc (lambda (c) c))
がどう使われるのかよく分からないけど、
実質的には同じことになるんじゃないかな?

(call/cc (lambda (c) (set! foo c)))
callCC (\c -> lift $ put c)
は IORef を使うと問題なくできる。
State だと無理だけど、新しく再帰的なデータ型を定義してやれば、
あまり便利では無さそうだけど一応できた。

475:デフォルトの名無しさん
08/08/13 22:46:51
オラ本の執筆遅れてます
著者にプレッシャﾖﾛ

476:36 ◆K0BqlCB3.k
08/08/13 22:51:05
どうせ買わないので暖かい目で見守るだけです。

477:デフォルトの名無しさん
08/08/13 23:21:14
Schemeのcall/ccってその時点の継続を勝手にキャプチャして渡してくれる
んですよね？Haskellではそういうのは無いと思っていいんでしょうか？

478:デフォルトの名無しさん
08/08/14 00:04:58
>>477
モナド無しでということなら無い。
そもそもcall/ccは副作用があるし。

479:デフォルトの名無しさん
08/08/14 13:47:21
>>474ができると言ってるじゃないか

480:デフォルトの名無しさん
08/08/14 17:35:34
あれはモナド有りでの話だよ。

481:デフォルトの名無しさん
08/08/14 18:53:40
ごめん、>>479は>>477へのレスね

482:デフォルトの名無しさん
08/08/14 18:54:49
山本モナド

483:デフォルトの名無しさん
08/08/16 19:35:13
Haskellはボブマリーの言語?
URLﾘﾝｸ(lethain.com)

484:デフォルトの名無しさん
08/08/16 20:24:00
コメント欄も読もうな

485:デフォルトの名無しさん
08/08/16 22:50:09
URLﾘﾝｸ(profile.myspace.com)

こうゆう落ちもある。

486:デフォルトの名無しさん
08/08/17 12:30:17
Xmonad/Config archive - HaskellWiki
URLﾘﾝｸ(haskell.org)
の設定ファイル郡を理解できるぐらいまでHaskellについて知りたいんですが
どこから勉強すればいいんでしょう？
知識はXmonadやGhcをソースからインストールできる程度です

487:デフォルトの名無しさん
08/08/17 13:44:52
>>443 >>446 静的で強い型を持つ言語は、単純な実行時エラーを防ぐので
テストは軽減する。haskellなどはそのことが数学的に証明されているので
プログラマはぬるぽやoutofboundsなどの基本的な間違いにであうことなく、
本質だけを考えることができる。

488:デフォルトの名無しさん
08/08/17 14:23:37
パターンマッチに失敗すること多くない？
たとえば「空でないリスト」型が欲しいとき、ぬるぽ的な実行時エラーを防げるの？

489:デフォルトの名無しさん
08/08/17 14:47:05
ぬるぽは無いけどout_of_bounds発生させまくりですが
依存型のある言語なら防げるかも知れんけど

490:デフォルトの名無しさん
08/08/17 15:31:08
>>487
おまえ初心者スレにいたHaskell信者だろ。

491:デフォルトの名無しさん
08/08/17 18:08:12
はいはい両者リングアウト

492:デフォルトの名無しさん
08/08/17 18:14:59
>>488
それヘボすぎ

493:デフォルトの名無しさん
08/08/17 18:26:58
モナドがIOに使えるのは分かった。けどどうしてそれをIO以外にも使ってるの？ >Haskell
誰か教えて下さい

494:デフォルトの名無しさん
08/08/17 18:36:20
Maybe(笑)を証明するため

495:デフォルトの名無しさん
08/08/17 18:36:41
便利だから

496:デフォルトの名無しさん
08/08/17 18:42:38
どんな時に便利ですか？

497:デフォルトの名無しさん
08/08/17 18:59:33
モナドのすべて
URLﾘﾝｸ(www.sampou.org)
の以下の部分を読むとわかるかも

Maybe というモナド
ひとつの例
リストもモナド

498:497
08/08/17 19:11:05
第 II 部：標準的モナドのカタログ
の各モナドの利用場面や動機を見るのもいいかもしれない

499:デフォルトの名無しさん
08/08/17 19:15:59
一応リストモナドやMaybeモナドが計算に使える、というのは理解しているつもりですが、
便利だからという理由以外にモナドをIO以外に使う理由はあったりしますか？
それだけの理由で使うには扱いが難しくて、プログラムを組む度に頭がオーバーヒートしそうになる

慣れの問題かそれとも理解不足か・・

500:デフォルトの名無しさん
08/08/17 19:25:15
>>489
そこでmaybeもなどですよ。

501:デフォルトの名無しさん
08/08/17 20:06:22
モナドという抽象的な枠組みを考えることで
IO, Maybe, List, etcの計算の合成を統一的に扱えるってのが最大の利点なんではないかと。

単に使うだけなら主に慣れの問題だと思う。
いろんな例を見て慣れていけば少しずつ理解もできていくんではないかと。

502:デフォルトの名無しさん
08/08/17 20:09:49
自分の作ったモナド上でdo式を書くと、世界の法則を書き換えてるような気分になってちょっと面白い

503:デフォルトの名無しさん
08/08/17 20:33:06
>>501
レス有難うです
慣れの他に密度の問題もあるかもしれないと思ったり。
他の言語より1行あたりの密度が濃いものになりやすい気がする。
というか濃縮されすぎてわけが分からなくなりやすい気がする。

504:デフォルトの名無しさん
08/08/17 20:38:12
>>501
計算を統一的に扱うだけであれば、普通の型クラスでいいんですよね？

モナドは値ではなくて型コンストラクタに対するクラスなので、ちょっと違う
と思うんですが。

505:36 ◆K0BqlCB3.k
08/08/17 20:39:51
モナドっていうと仰々しいイメージがあるかもしれないけど、
所詮はただの代数的データ型とそのデータ型に対して一貫性あるAPIのセットに過ぎないよ。
ところで、　データ型とAPIのセット　のことをなんて呼べばいいの？

506:デフォルトの名無しさん
08/08/17 20:40:10
Stateモナドとかの(s -> (a,s))みたいな変な定義が気持ち悪い
型クラス(b,s) -> (a,s)に型bを部分適用したって考えれば意味は通るけど……

507:デフォルトの名無しさん
08/08/17 21:08:43
>>505
それが「型クラス」、ではないのでしょうか？MonadやFunctorはちょっと
毛色が違うという認識は勘違いでしょうか？

508:デフォルトの名無しさん
08/08/17 21:17:01
URLﾘﾝｸ(www.hyuki.com)

Ord、Eq、Show などのデータ型とそのAPIのセットは「型クラス」
Functor、Monad、MonadPlus などのデータ型の構築子とそのAPIのセットは「型構築子クラス」

509:デフォルトの名無しさん
08/08/17 21:31:22
それ単にOrdとかの『類』は*で引数をとらないけど
Functorの『類』は*->*みたいに引数をとる、って違いにしか見えない
分けて考えるのはおかしいと思う

510:デフォルトの名無しさん
08/08/17 21:37:45
>>509
型クラスと型構成子クラスじゃ抽象度が違うよ。

511:デフォルトの名無しさん
08/08/17 21:49:13
俺も>>509みたいに感じるなあ
抽象度が違うのは理解できるが

512:507
08/08/17 21:58:16
抽象度の違う型クラスを持つことで、値の計算遷移とは別レベルの
遷移を持つことが可能だ、という印象を持つんですけどどうなんでしょうか。

普通の計算を行う裏側で別の次元での計算が行われ、且つそれが
結合法則を満たしている、というのがモナドの定義と考えるのは
どうですか？自分は圏論などのこと全く無知なのでHaskellの構文
からの直感的な印象だけなんですけど。

513:デフォルトの名無しさん
08/08/17 21:59:06
じゃあ類が*->*->*（関数(->)とかタプル(,)とか）に対する型クラスとかは
もっと抽象度が違うので別の名前が必要なのか？型構築子構築子クラスとか。
有名な人が書いてるから鵜呑みにしてるだけなんじゃないの？

514:デフォルトの名無しさん
08/08/17 22:31:24
>>512
だいたいあってんじゃね？
見えてる部分で適当に処理を書いたら裏で適当に処理してくれる、
普通のプログラミング言語じゃfor文やif文みたいな処理構造、
あるいはマクロとして提供されるものと同等の処理ができるんだけど、
実態は単に型クラスでしかないので俺定義できるし、高階関数使えるし、表記もシンプルで、いろいろ小細工が利くのが利点。
たとえば、IOみたいにコンストラクタを隠したりすれば脱出不可な構造を作れるってわけ。

結合法則を満たしているってのは、まぁ別に特別なことじゃない。
EqやOrdにも反射律とか推移則とか守らないといけないルールがあるけど、
よっぽどのことがない限り変な実装はしないだろうから、一般のプログラミング言語ではそこまで突っ込まない
でもモナドって実態がよくわかんないから、ルールを明記してる。そんだけでしょう。

515:デフォルトの名無しさん
08/08/17 22:45:32
念のため補足。
＞処理構造(略)同等の処理ができるんだけど
普通の言語では処理構造のものが、モナドが利用されてる例としてはErrorモナドとかContinuationモナドとかがあったね。

＞よっぽどのことがない限り変な実装はしないだろうから、一般のプログラミング言語ではそこまで突っ込まない
浮動小数点の比較と等価性で違う実装がされてるとか、変な実装もあるけど。

個人的にはMonad則は、
値に関して順次実行できる何かで、値に対して何もしない処理もできる何かだ、というルールだと解釈してる。

516:デフォルトの名無しさん
08/08/17 22:50:03
変な実装＝全順序じゃない、と読み替えてくれ。
コンピュータのメモリ節約を考えれば生の浮動小数点型を使うのもまっとうな実装だわｗ

517:デフォルトの名無しさん
08/08/17 23:19:23
ごめん、誤解を招くといやなのでもう一つ補足……
＞値に関して順次実行できる何か
これは実行順序じゃなくて値の計算する方向を言ってるだけだよ。
g.f x がxにfを適用してgを適用するってのと同じことだよ。
実行順序は普通のモナドもIOモナドも方向は決まってないよ。

518:初心者修業中
08/08/17 23:37:55
ん？
実行順序を明確にするのがIOモナドの目的の一つ
と認識していますが。

そういう意味ではないのかな…

519:デフォルトの名無しさん
08/08/17 23:41:24
Haskellをみて日本のhaskellコミュって元気なの？
他の言語に比べて内と外をわけすぎるようなそんな印象をもってる。
なんでだろ？

520:デフォルトの名無しさん
08/08/17 23:58:38
>>518
たとえば、
1:2:3:[]は、
1:2:3:[] → 1:2:[3] → 1:[2, 3] → [1, 2, 3]と簡約されるかもしれないし、
1:2:3:[] → [1, 2:3:[]] → [1, 2, 3:[]] → [1, 2, 3]と簡約されるかもしれない。
でも結果は一緒でしょ？

同じように、
Hello, Worldって出力 >> 一文字入力 >>= 前の文字を出力
みたいなのは、まぁ言ってみれば(不正確だけど)
[Hello,Worldって出力, 一文字入力, 前の文字を出力]みたいな並びにされる(と思われる。実装はカプセル化されていて不明)。
この並びがプログラム終了後にコンパイラにわたって、コンパイラがこれを順番に処理していく。

実はこの並びをプログラム終了後以外に評価する方法があって、それがUnsafePerfomedIOって言う関数。
getContentとかは実はこれを使って実装されている。
Unsafeという名前が示すように、素人にはお勧めできない。(getContent自体は普通に使える。)

521:デフォルトの名無しさん
08/08/18 00:02:55
Maybeの特化にしか見えません

522:36 ◆K0BqlCB3.k
08/08/18 00:25:49
>>519
世界的に全く元気がありません。
ちょこっと変なライブラリを書いたと思えばそれっきり離れていっている人も多数。

523:デフォルトの名無しさん
08/08/18 01:36:55
>>520

後者の簡約は型がおかしいし、1:2:3:[]ではなく、
f x = (unsafePerformIO $ print x) `seq` xで
f 1:f 2:f 3:[]だった場合、前者と後者の簡約順序ではprintの順番が違ってくる。
前者は3,2,1で後者は1,2,3

一方で(>>=)は最左最外簡約でも最右最内簡約でも
左から順にしか値が定まらないようになってる。

putStr "Hello" >>= (\ _ -> getChar) >>= (\ c -> putChar c)
(>>=)の右辺が関数だから左辺の値が定まるまでa >>= bが最終的な値に簡約できないようになっている。

次ページ