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

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

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が最終的な値に簡約できないようになっている。

524:デフォルトの名無しさん
08/08/18 03:17:18
>>522
元気無い理由って何でしょうか。他に元気ある言語ってあるのかな。

525:デフォルトの名無しさん
08/08/18 04:14:24
ruby

526:デフォルトの名無しさん
08/08/18 08:38:27
>>520
> 1:2:3:[] → [1, 2:3:[]] → [1, 2, 3:[]] → [1, 2, 3]と簡約されるかもしれない。

型が滅茶苦茶だよ。

> この並びがプログラム終了後にコンパイラにわたって、コンパイラがこれを順番に処理していく。

意味不明。なぜプログラム終了後にコンパイラが出てくる。
ランタイムライブラリとごちゃまぜになているぞ。

527:デフォルトの名無しさん
08/08/18 10:05:00
Haskellにこういう奴が多い気がするのはなぜだ

528:デフォルトの名無しさん
08/08/18 10:21:37
「こういう奴」と書けばどんな奴を指してるのか分かってもらえると思ってるような、
想像力の貧しい奴がこのスレに多いような気がする

529:デフォルトの名無しさん
08/08/18 13:36:03
末尾が「気がする」で終わってるレスは
全部気のせいのような気がする

530:デフォルトの名無しさん
08/08/18 15:08:49
なんという自己言及レス

531:デフォルトの名無しさん
08/08/18 15:12:16
関数型らしくて言いじゃないか

532:デフォルトの名無しさん
08/08/18 15:41:06
>>531
つ座布団1枚

533:デフォルトの名無しさん
08/08/18 21:50:15
* -> * -> * ってどんなとき使うの？

534:デフォルトの名無しさん
08/08/18 22:25:25
アナルトレイン

535:デフォルトの名無しさん
08/08/19 07:45:46
　　（　ﾟдﾟ）ﾟдﾟ）ﾟдﾟ）
　　/　　つ　つ　つ
　 (_(_　ﾉ　ノ　ノ
　　し∪ ∪　∪

536:デフォルトの名無しさん
08/08/19 10:10:53
>>505
> ところで、　データ型とAPIのセット　のことをなんて呼べばいいの？

プログラミング言語一般での話なら「抽象データ型」でしょうね。

537:デフォルトの名無しさん
08/08/19 11:50:46
>>533
関数(->)とかタプル(,)とか

538:デフォルトの名無しさん
08/08/20 20:24:46
485でおま。
それでなのです。　>ときどきの雑記帖の中の人

539:デフォルトの名無しさん
08/08/21 14:40:13
Arrow は * -> * -> * のクラス
MonadTrans は (* -> *) -> * -> * のクラス

540:デフォルトの名無しさん
08/08/21 21:20:37
URLﾘﾝｸ(book.realworldhaskell.org)

これの30章が消えてるんだけど・・・。

541:デフォルトの名無しさん
08/08/21 22:05:29
本買えよ

542:デフォルトの名無しさん
08/08/21 23:26:23
30章だけが読みたいんだよ。

ところで、HaskellでPetStoreってあるの？

543:36 ◆K0BqlCB3.k
08/08/21 23:56:58
>>542
横からすみませんが、
Pet Storeをよく知らないのでちょこっと検索したんですが、
これっていったい何が面白いんですか？

544:デフォルトの名無しさん
08/08/22 00:08:29
>>543
面白くは無いんだけど、色んな言語やフレームワークで同じもの作る
ことで比較をするためのものでしょ。同じアプリがこんな感じで作れ
ちゃうぞ、という。

545:デフォルトの名無しさん
08/08/22 11:40:45
Haskellでウェブアプリというとふつう本か

546:36 ◆K0BqlCB3.k
08/08/22 12:37:40
最近では新しい言語はWEBアプリが書きやすくないと人が入ってこないらしく、
ライトウェイト言語がブームみたいだね。
HaskellはライトウェイトではないからWEBアプリ向きとは全然思えないんだけど、
RubyでRubyOnRailsが考えられたみたいにHaskell独自のWEB向きキラーアプリが
出てこないとHaskellの人気はこれからもずっと平行線だと思うよ。

547:デフォルトの名無しさん
08/08/22 12:41:19
>>546
WEBアプリが書きやすいっていうより、APIとかWEBコンテナが標準装備されてないとダメという感じがする。
Javaの功罪は大きい。

548:デフォルトの名無しさん
08/08/22 12:41:59
まだ横ばいならたいしたもんだ

549:デフォルトの名無しさん
08/08/22 12:48:26
>HaskellはライトウェイトではないからWEBアプリ向きとは全然思えないんだけど、
ライトウェイトって何？動的に型を付ければライトウェイト？
それとwebとどういう関係があるの？

550:デフォルトの名無しさん
08/08/22 13:05:36
あまり考えずに気の向くままに書いてもあっさり動くのが
ライトウェイトってことじゃないか？
web案件は短期だったりアジャイルだったりでライトウェイトに
開発できるのが求められてるってのはある

551:デフォルトの名無しさん
08/08/22 13:10:45
WEBアプリの開発者は、JavaかRubyのHowto本から入ってる。
だから、WEBアプリ開発者は、身体のどこかに、プログラミング言語のJavaかRubyに似てない部分に拒否反応を持ってる。

552:デフォルトの名無しさん
08/08/22 13:11:10
ここでHaskellは人間の思考過程に最も近いから
考えが即座にコードにうつせるため開発期間が最短であると主張する人がどこからか登場
　　　　　　　　　　　　　　　　　　　　↓

553:デフォルトの名無しさん
08/08/22 13:23:23
　　　　　　　　　　　　　　　　　　　　｜
　　　　　　　　　　　　　　（ﾟдﾟ　）↓
　　　　　　　　　　　　　　　　（⊃⌒*⌒⊂)
　　　　　　　　　　　　　　　　　/__ﾉ''''ヽ__）

554:デフォルトの名無しさん
08/08/22 13:27:58
>>550
それならHaskellもライトウェイトで良くね？

555:デフォルトの名無しさん
08/08/22 14:05:36
明示的なコンパイル作業が必要ないってのはLLの必要条件な気がする。

556:デフォルトの名無しさん
08/08/22 14:18:04
LLとかWebアプリとか、
だから普及しないとか、
どうでもよくねえ?
好きな事、楽しい事すればいい。

557:デフォルトの名無しさん
08/08/22 14:22:47
>>555
runghcがあるじゃないか
もうちょっと速ければと思うことはあるけど

558:デフォルトの名無しさん
08/08/22 14:34:05
>>556
そういう立場も理解できるけど、俺は普及してほしい
ライブラリのメンテとか人が足りてないじゃん

559:デフォルトの名無しさん
08/08/22 14:46:33
>>552
Prologには負けるんじゃない。

560:36 ◆K0BqlCB3.k
08/08/22 14:47:15
runghcはオーバーヘッドもかなり大きいみたいだね。

$ cat hello.hs
main = putStrLn "hello"
$ time runghc6 hello.hs
hello

real 0m0.835s
user 0m0.780s
sys 0m0.052s

$ cat hello.rb
print "hello\n"

$ time ruby hello.rb
hello

real 0m0.015s
user 0m0.012s
sys 0m0.000s

561:36 ◆K0BqlCB3.k
08/08/22 14:48:14
$ cat hello.pl
print "hello\n"

$ time perl hello.pl
hello

real 0m0.007s
user 0m0.004s
sys 0m0.000s

$ cat hello.py
print "hello"

$ time python hello.py
hello

real 0m0.035s
user 0m0.020s
sys 0m0.016s

562:デフォルトの名無しさん
08/08/22 15:03:43
LLでHaskell関係のプレゼンとかしてる人いるみたいだけど？

563:デフォルトの名無しさん
08/08/22 15:07:56
WebアプリとLL（と呼ばれている言語）との間には全く関係はないけど、
Webアプリのかなり大部分は一般的にLLと呼ばれている言語で書かれているだろう。
そういう"LL"はテキスト処理がしやすいからってのがあるだろうな。
まあHaskellがそういう意味で人気にならなくても別にどうでもいいけど。

ここでmondic Parser Combinatorを持つHaskellが
最もテキスト処理に適した言語であると主張する人がどこからか登場。
　　　　　　　　　　　　　　　　　　　　↓

564:デフォルトの名無しさん
08/08/22 15:38:43
HaskellもLL言語だよ

565:デフォルトの名無しさん
08/08/22 15:45:06
これどうなの？
URLﾘﾝｸ(happs.org)

566:デフォルトの名無しさん
08/08/22 16:09:31
Parser Combinatorがあるからテキスト処理ならHaskell最強だろ。

満足した？

567:デフォルトの名無しさん
08/08/22 17:42:48
haskellは型推論がちゃんと効いてる使い方が出来れば、LL的な生産性は確保できるだろう。
だがな、至高の存在で良いじゃないか。

haskellの性質上webプログラミングは不得意分野に思うんだが、mod haskellなんて生まれる
分けでもないし生まれたところで破壊的操作がほとんどできないし、ファイル操作は基本的に
苦手でしょ。webは動的言語の親玉が一番向いてるけどs式アレルギーな人が多いからLLに
なってるんでしょうね。

だから、無理にwebに擦り寄らずとも良いと思うんだけどね。むしろ、破壊的操作より安全性を
大切にされる金融などのところで目立つ存在になってくれたらいいんじゃないか？

568:36 ◆K0BqlCB3.k
08/08/22 18:09:07
>>567
もし金融などで使われることを想定するなら、
haskellの並列処理に関する部分も早く実装してほしいところですね。
（まだ未完成）

569:デフォルトの名無しさん
08/08/22 18:44:00
某氏のhapps解説はお流れ？

>>567
> 破壊的操作がほとんどできない
なんで？

570:デフォルトの名無しさん
08/08/22 18:58:34
なんでそんなにHaskellの応用分野を限定したがるんだｗ

>>567
コンパイルするならmod_haskellがあっても恩恵は小さいだろ
>破壊的操作がほとんどできないし
Haskellで入出力書いたことあるか？
>ファイル操作は基本的に苦手
これも良く分からん
flock使うのにわざわざライブラリを落としてこないといけないとか、そういうこと？

571:デフォルトの名無しさん
08/08/22 19:43:28
ウイルス対策ソフトのように危機感を煽るのはいいが、
既存のシステムを補強するのではなく全部作り直せというのは、ちょっとね

572:デフォルトの名無しさん
08/08/22 19:54:17
>>570
Prologを事務処理に使うと、住所や氏名情報などで爆発的にアトムが
発生し、Heap領域を埋め尽くして、GCが頻発するという事態となる。
もちろん数百万レコードを越える処理単位の話だが。
Haskellの場合この問題は起きないの?

573:デフォルトの名無しさん
08/08/22 20:37:03
Webアプリが苦手ってことは無いと思うんだけどな。今後Webベースのアプリは
まだ増殖するだろうから、そっちで使いやすいフレームワークやDSLが出ないと
使う人は頭打ちだと俺も思う。

研究者の論文レベルのものも面白いだろうけど、上から下までHaskellベースで
かかれたWebアプリとかで目立つものが出てほしいよ、個人的には。

574:デフォルトの名無しさん
08/08/22 20:53:32
>>572
アトムの爆発ってのはPrologスレで言及されてる現象のことでいい？
そもそもPrologのアトムってのが良く分からんので何が問題なのか理解できん
Lispのシンボルみたいな物と思っていいのかな
それなら相当するものはHaskellにはないよ

575:デフォルトの名無しさん
08/08/22 21:35:41
>>574
Lispのシンボルみたいな物、ですね。
記号をどう処理しているのですか。

576:デフォルトの名無しさん
08/08/22 21:53:05
>>540
30章ってなんの章だったの？

577:デフォルトの名無しさん
08/08/22 22:12:26
>>575
「記号」と言われてもいまいちピンと来ないんだが、何にせよ、
普通の手続き型言語が「記号」を処理するのと大差ない方法で処理してると思う

取り得る種類がコンパイル時に決まっているなら列挙型
そうでないなら整数とか文字列
文字列の比較のコストが問題になるなら自分でシンボルテーブルのようなものを用意する、とか

578:デフォルトの名無しさん
08/08/22 22:34:03
>>576
>>310-314

579:デフォルトの名無しさん
08/08/23 09:45:26
>>572
Prologでも、
1レコード512バイトをsub_atomで30項目に分解したり、更にsplitの
処理をしたりすると確かにアトムが大量発生するだろうが、
Stringとして読み込んで、終始String処理に徹すれば、アルファベットの
数、つまり高々数万のアトムで済むんじゃないの?
Stringすなわちリスト処理になると遅いから嫌なのかな。

580:デフォルトの名無しさん
08/08/23 10:00:27
宣言的言語をリアルタイム処理に使いたくない病にかかってる。
資源が十分にあると理屈では分かっていても、終わったら電源切っても大丈夫な処理じゃないと拒否反応がでる。

581:デフォルトの名無しさん
08/08/23 10:09:14
>>579
処理速度もあるかも知れませんが、アトムだと、
foo([株式会社|R],R).
と書けるところが、Stringだと
foo(List,R) :- append("株式会社",R,List).
と書かなくてはならないということがあります。
appendを高速化する機構が欲しくなりますね。

582:デフォルトの名無しさん
08/08/23 10:35:10
それって代数的データ型を使ってこんな感じで良いんじゃない？

data Atom = Kabushiki | Dummy deriving (Show, Eq)

foo :: [Atom] -> [Atom]
foo (Kabushiki : r) = r

583:デフォルトの名無しさん
08/08/23 11:43:27
Prologでまったり Part3
ｽﾚﾘﾝｸ(tech板)

584:デフォルトの名無しさん
08/08/23 12:43:04
>>581
この話おかしいよ。
foo([株式会社|R],R). の方は、
すでに株式会社というアトムが切り出されていて、リストの構成要素になっている。
一方、
foo(List,R) :- append("株式会社",R,List). のListはString。ここは、
foo(["株式会社"|R],R).
でなきゃ、フェアじゃない。

585:デフォルトの名無しさん
08/08/23 13:58:45
>>572
> Prologを事務処理に使うと、住所や氏名情報などで爆発的にアトムが発生し

第五世代コンピュータプロジェクトの成果を是非参照下さい。

586:36 ◆K0BqlCB3.k
08/08/23 14:16:16
>>585
よく知らないけどソフトウェア科学会会誌7月号に第五の話題が載っていたよ

587:デフォルトの名無しさん
08/08/23 14:21:10
成果って、「prologって役立たずじゃん」という結論を得たこと？

588:36 ◆K0BqlCB3.k
08/08/23 14:28:53
>>587
それは短絡的な人たちの根拠のないうわさ。
第五は基礎研究なので企業の人たちが求めるような成果が出ないのは当たり前のこと。

589:デフォルトの名無しさん
08/08/23 14:31:33
Prologの話は他でやってくれ
んで問題点を整理してまたいらっしゃい

590:36 ◆K0BqlCB3.k
08/08/23 14:33:31
詳しいことは忘れたけど、
述語論理による仕様記述を使った鉄道のプロジェクトが企業側で行われた例があったような。
なんだったっけ？

591:デフォルトの名無しさん
08/08/23 14:45:22
Prologはどうでもいいのだが、Haskellで金融(とくに保険業)のアブリを
開発する場合、何か問題になる点はないのか。

592:デフォルトの名無しさん
08/08/23 14:54:20
>>591
必要なメモリサイズを予測しにくい点とか。full lazyな処理系全般に言えると思うけど。

593:デフォルトの名無しさん
08/08/23 14:57:02
金融系システムにHaskellを使うメリット自体が思いうかばん。
いいじゃん、Javaでつくるのが流行ならJavaで作らせれば。
どうせ枯れたシステムなんだから。

594:デフォルトの名無しさん
08/08/23 15:00:18
>>592
full lazyな処理系って、よくわからない。

595:36 ◆K0BqlCB3.k
08/08/23 15:11:43
どんな言語で書いたとしても、必要なメモリの量は実際に動かしてみないとわからないよ。

596:デフォルトの名無しさん
08/08/23 15:17:46
haskellっていいプロファイラあんの？

597:デフォルトの名無しさん
08/08/23 15:26:42
>>595
COBOLなんかは確定してると思うけど。

598:デフォルトの名無しさん
08/08/23 15:42:16
>>597
してない。
SORTなどに内部的に使う記憶容量が不明。

599:デフォルトの名無しさん
08/08/23 15:43:11
Haskellのようにデフォルトで遅延評価する言語は、
計算をできるかぎり遅延させようとするから、
下手な書き方するとすぐメモリリークする

Haskellのメモリリークは大抵の場合小規模な修正で直るけど、
どこを修正すべきか探すのに慣れとプロファイラが要る

>>596
GHC付属のプロファイラは優秀だと思う

600:36 ◆K0BqlCB3.k
08/08/23 15:47:59
>>596
profオプションをつけてコンパイルしたらランタイムシステムにプロファイラが組み込まれるよ。
詳しくはマニュアルで。

601:デフォルトの名無しさん
08/08/23 16:19:23
>>598
ん？確定はしてなくても最大どれかけかかるかは確定してるでしょ。
グラフ簡約のヒープ消費は予測もつかんぞ。

602:デフォルトの名無しさん
08/08/23 16:27:11
>>601
確定してるのかしてないのかどっちだｗ

603:初心者修業中
08/08/23 16:37:52
Haskellでメモリーリークが起きるのですか?

ガベージコレクションにバグがない限り、
メモリーリークが起きるとは思えないのですが…。

FFIを使った場合の事でしょうか…。

604:デフォルトの名無しさん
08/08/23 17:15:44
>>599 の例としては↓の話かな。
URLﾘﾝｸ(d.hatena.ne.jp)

この場合のメモリーリークは単なるメモリの解放忘れって事ではなくて、
期待した解放タイミングと実際のそれとのギャップの事みたいだね。

605:初心者修業中
08/08/23 17:42:49
これも「メモリーリーク」と呼ぶのでしょうか？

*Main> foldr (+) 0 [0..1000000]
*** Exception: stack overflow

606:デフォルトの名無しさん
08/08/23 18:05:58
プログラマが意図してないで、リファレンスが残るようなコーディングを
しちゃってる、というのをリークに含めることもある。

607:デフォルトの名無しさん
08/08/23 18:34:57
>>605
それは「マヌケ」と呼びます。

608:初心者修業中
08/08/23 18:57:56
stack overflowが発生する時、

簡単にわかる場合は「マヌケ」
ちょっとわかりづらい場合は「メモリーリーク」

と呼ぶという認識でよろしいでしょうか？

609:デフォルトの名無しさん
08/08/23 19:14:20
リークってのは「漏れ」のこと。
GCのある言語だと、>>606しか起こり得ない。
>>605の「溢れ」とは全然違う。

610:デフォルトの名無しさん
08/08/23 19:20:46
>>605
それはスタックオーバフロの例外であって、エラーとは違う。
メモリリークしているわけではないよ。

611:デフォルトの名無しさん
08/08/23 19:22:12
C言語みたいに型があいまいな言語ではメモリリークが起こりうるが、
Haskellみたいに強い静的型付けされている言語にはメモリリークなんてありえないよー

612:デフォルトの名無しさん
08/08/23 19:26:56
スタックオーバーフローとメモリーリークは
現象として全然違うと言う事ですね。
分かります。

613:デフォルトの名無しさん
08/08/23 19:53:14
>599や>604が挙げているような例はC言語で
良く言われる「メモリーリーク」とは違う現象だな。

Haskellの場合、遅延評価がデフォーなので
うかつに再帰を使うと計算の途中結果が膨大な
ものになってヒープ領域が溢れてしまう。

Cの場合はただの確保したメモリの解放し忘れ。
Cでも再帰的なメモリー確保をすれば
Haskellみたいな事も起きうるはずだが。

614:デフォルトの名無しさん
08/08/23 20:06:48
>>611
強い静的型付けとメモリーリークの有無はほとんど関係がありません。
GCの方がずっと関係が深いです。

615:デフォルトの名無しさん
08/08/23 20:09:24
Pascalのnewとfreeだっけ?
あれ考えれば分かるよな。
強い型付けでも簡単にメモリーリークは起きる。

616:デフォルトの名無しさん
08/08/23 20:56:45
foldl でも stack overflow するんだよね。
Data.List.foldl' 使えばいいんだけど。

617:デフォルトの名無しさん
08/08/23 21:35:43
なんで foldl でスタック溢れるの？末尾再帰が最適化されてないの？

618:デフォルトの名無しさん
08/08/23 21:48:31
>>604のリンク先に書いてある
末尾再帰は最適化されるよ

619:初心者修業中
08/08/23 23:53:01
>>617
遅延評価だからと認識しています。
↓参考
URLﾘﾝｸ(haskell.g.hatena.ne.jp)

620:617
08/08/24 00:40:37
>>618-619
なるほど、非常によくわかりました。
（つーか前出のリンク読まずにレスして申し訳ない）

うーむ、しかし末尾再帰が最適化されることの旨みは、
・ローカルスコープの値をスタックに積む必要がなくなることと
・連続するreturnが省略されること
の２点だと思うけど、foldl のように結局は遅延評価のための
computation がスタックに積まれていて、後から順次簡約するなら
「最適化されている」とは言い難い気もするな・・・。
最適化するための然るべき変形は、一応してあるんだろうけど。

まあ seq 使うとか、回避の仕方がないわけじゃないからいいのかな？

621:デフォルトの名無しさん
08/08/24 00:54:46
↓にも関連した話が載ってる。
URLﾘﾝｸ(itpro.nikkeibp.co.jp)

622:デフォルトの名無しさん
08/08/24 13:10:00
■■学校を作ろう！■■
VIP発でサイトを作ろうと思うんだ。（詳しくはWikiを見てくれ）
パートスレになるんでパー速（GEP)に移動している。
今スタッフを募集しているから、来てくれないか？

■Wiki
URLﾘﾝｸ(www36.atwiki.jp)
■募集スタッフ
プログラム担当（特にErlang、Perl）
デザイナー（サイト上のアイコン、ロゴなど）
WEBデザイナー（サイトデザイン案に沿って、htmlやCSSを書ける）
他にも宣伝担当なども募集している。
■スレ
URLﾘﾝｸ(ex14.vip2ch.com)

623:デフォルトの名無しさん
08/08/24 16:41:26
「特にErlang」…

実用性でいうとやっぱErlangなのかな…

624:デフォルトの名無しさん
08/08/24 18:20:21
>623
大規模なWebサービスを構築するのに向いていると
考えたから企画者がErlangを採用したんだろうね。

625:デフォルトの名無しさん
08/08/25 09:10:25
大規模な、ってのがクセ者で、
実情は単にDBのテーブルが大きいだけだったりするよな。
そもそもウェブアプリでDB以外どこが肥大化するよ？

626:デフォルトの名無しさん
08/08/25 09:11:28
画面？

627:デフォルトの名無しさん
08/08/25 09:20:29
>>625
複数のwebサービスから情報集めたり、もしくはhttp以外のプロトコルで通信して情報を取得しなきゃいけなかったり、
別プロセスで並列キューに入れて処理しなきゃいけなかったり、システムそのものが大きくなるとこはあると思う。
それともデータサイズの規模に限定した話？

628:デフォルトの名無しさん
08/08/25 09:53:32
>>625
とりあえずErlang + YAWSの事例くらいは、
念頭においてくれないと、話にならないのでは?

629:デフォルトの名無しさん
08/08/25 09:55:11
>>627
> 複数のwebサービスから情報集めたり、

そういうのはAjaxでクライアント側がやるのが流行では？
まあサーバ側がやってもいいですが、HTTPセッションを入れ子にするのは
あまり筋がいい設計とは思えません。

> もしくはhttp以外のプロトコルで通信して情報を取得しなきゃいけなかったり、

まあDB接続なんかもそうですよね。
しかし「大規模になる」ような要因とはあまり考えられないのですが。

> 別プロセスで並列キューに入れて処理しなきゃいけなかったり、

fastcgiとかの話でしょうか？特段、だから大規模になるというものではないと思いますが。

> それともデータサイズの規模に限定した話？

コード自体はほとんどCMS系フレームワークをユーザ定義コンテナを定義する程度で
用が済むことが多いと思います。特に、>>622のような、いかにもCMSっぽいシステムでは。

630:デフォルトの名無しさん
08/08/25 10:00:08
>>629
> コード自体はほとんどCMS系フレームワークをユーザ定義コンテナを定義する程度で
> 用が済むことが多いと思います。特に、>>622のような、いかにもCMSっぽいシステムでは。

よいCMS系フレームワークを、
容易に開発できるかどうかって話をしているんだと思いますよ。

631:デフォルトの名無しさん
08/08/25 10:54:21
>>630
なるほど、わかりました。
格納するコンテンツの量は結局DBのサイズの問題になると思うので、
それ以外の「大規模」の要因というと、
・同時接続数（パフォーマンス)
・登録ユーザー数
ぐらいでしょうか。
それとも単純にコードサイズを指して「大規模」という話なんでしょうかね。
「学校」というドメインが明確になっているので、
一般のCMSフレームワークほど汎用化は要求されないし、
どのような要因でコードサイズが「大規模」化するのか興味があります。

632:デフォルトの名無しさん
08/08/25 12:22:00
>>624
Apacheとか使わずErlangでサーバー構築するんじゃないの?

633:デフォルトの名無しさん
08/08/25 12:26:39
キッチンシンクアプローチか……

634:デフォルトの名無しさん
08/08/25 13:01:50
Erlangをわざわざ使うということは、数百レベルの並列プロセスを
マルチコアで何とかしようと考えていると見て間違いない。
Webだとすれば、WebServer以外考え難い。生徒数千でほぼ
同時にアクセスがあるとか。

635:デフォルトの名無しさん
08/08/25 13:13:15
しかし、>>622 はなんでErlangスレに書いてないんだ？w

636:デフォルトの名無しさん
08/08/25 13:16:41
単に初期メンバーにErlang使いが居ただけなじゃいの？

637:デフォルトの名無しさん
08/08/25 13:16:52
Erlangスレ見たことない方ですねw

638:デフォルトの名無しさん
08/08/25 13:42:02
Erlangはどうでもいいんだけれど、
HaskellでもPerl使いを確保しておいて、単体の機能は専らCPANから取り出させて、
確保されているインターフェイスを介してHaskellで利用するというやり方は
多くなるんじゃないかな。短時間で開発する一手法としてね。

639:デフォルトの名無しさん
08/08/25 13:57:49
ならないね。

640:デフォルトの名無しさん
08/08/25 14:13:29
>>638 落日のPerlを使うかどうか。規格書の通りに一からすべて開発するのは確かに大変だね。

641:デフォルトの名無しさん
08/08/26 00:21:14
Text/ParserCombinators/ReadP.hsとKoen Claessen氏のペーパーを読んで思ったんですが、

Haskellに慣れてくるとこの実装が直感的に見えてくるんですか？
Haskellのパーサコンビネータ関連のペーパーを読んでいない状態でReadPを読んで、

data P a = Get (Char -> P a)　　
　　　　　　略
　　　　　　| Result a (P a)
　　　　　　略　　　　　　　　　　　　　　　　　　なのを「え、一番直感的じゃん」

とか、
newtype ReadP a = R (forall b . (a -> P b) -> P b)
で
instance Monad ReadP where
　　return x　　 = R (\k -> k x)　　　　　　　　　　　　　　　　　　　 ← これとか
　　fail _ 　　　　= R (\_ -> Fail)
　　R m >>= f 　= R （\k -> m (\a -> let R m' = f a in m' k)）　　← これとか
とか
get = R Get
ってなるを、「ああ、自明だなすげえ直感的」みたいに理解できるようになる物なんですかね。。難しすぎる。。。

642:デフォルトの名無しさん
08/08/26 00:29:58
>>629
大規模になる要因なんていくらでもあるじゃん。
今時は単にUIがWebで、バックエンドが複雑化してるものも少なくないしね。
分散業務システムで多種類のプロセスを相手にすりゃ自然と規模は大きくなるかと。
何でもかんでもインターネット上でパブリックに利用可能な整理されたサービスばかりじゃないからね。
学校だって企業並みにシステムが複雑化してるとこもあるから、強ち単純とは言えないんじゃないかと。
まあ何はともあれ、ロジックが複雑になればなるほど、関数型の恩恵は大きくなるわな。

643:デフォルトの名無しさん
08/08/26 01:08:51
といったって、googleも複雑なシステムとか言われてるけど、
googleを支える技術とか読んでもそんなに複雑とは思えないんだよなぁ。
台数は1台だけど自宅で似たようなことやってるもん。

644:デフォルトの名無しさん
08/08/26 08:11:38
>>641
P のような再帰的な型のモナドを、
効率のために継続モナド(ReadP)で包むのは定石。
Haskell への慣れっていうより、
モナドや継続モナドへの慣れの問題な気がする。

P は問題によって様々だけど、
ReadP のとこは Control.Monad.Cont の
一般的な継続モナドと(型を除いて)同じなので、
それを理解しておくと問題に集中できていいかもよ。

645:デフォルトの名無しさん
08/08/26 08:13:32
つチラシの裏

646:デフォルトの名無しさん
08/08/26 08:21:08
>>642
それはバックエンドで動いている他プロセスが複雑なのであって
ウェブアプリが複雑なわけではないのでは？

647:デフォルトの名無しさん
08/08/26 08:32:48
>>625
機械翻訳とかではなくて?

648:デフォルトの名無しさん
08/08/26 18:38:57
>>644
どうもレスありがとうございました。

＞P のような再帰的な型のモナドを、
＞効率のために継続モナド(ReadP)で包むのは定石。
これは初めて聞きました。どうもありがとうございます。

確かに
If we want to build monads on top of a continuation based programming paradigm,
such as stream processors or continuation based I/O in Haskell,
we need to build a monad around the continuation based operations.
って書いてあるペーパーを見付けました、その継続ベースの方法について考えながら考えていこうと思います。

次ページ