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

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

263:デフォルトの名無しさん
08/06/23 19:21:38
zip [] ⊥ = []
らしいから>>260と>>261は等価かな
こういうのを意識しないといけない場面だと非正格性が気持ち悪い

264:デフォルトの名無しさん
08/06/24 00:09:28
>>263
⊥って勃起してるのｗ？

265:デフォルトの名無しさん
08/06/24 01:03:13
いやむしろ tail で書けて気持ちいいだろ。

266:デフォルトの名無しさん
08/06/24 06:18:25
>>265
でも
zip (tail xs) xs
と
zip (drop 1 xs) xs
は等価じゃない
つまり、zipでは第一引数が先に評価されるということを覚えていないといけない分、ややこしい
(厳密には評価順の問題じゃなくて「zipは第一引数について正格で第二引数について非正格」ということだけど)

267:デフォルトの名無しさん
08/06/24 07:48:57
>>266 どういうこと？
例えば
f (x1 : x2 : x3 : xs) -> x1 + x3
だったら、引数のリストの最初の要素と３番目の要素について正格ってこと？

268:デフォルトの名無しさん
08/06/24 08:32:09
>>267
そういうつもりで「正格」という言葉を使った

269:初心者修業中
08/06/24 09:53:02
関数結合の(.)って優先順位が高いので、
どうしても括弧が増えて見ぐさい気が…。

こんなのがあったら便利だと思うんですけど、
↓
infixr 1 $.
($.)=(.)

こんな感じ
↓
sigma = tail $. scanl (+) 0

標準ではなさそうなんですが、
やっぱ、問題ありですかね？

270:デフォルトの名無しさん
08/06/24 09:55:22
慣れの問題

271:初心者修業中
08/06/24 10:13:14
ああ、勘違いしてました。
関数の優先順位はどの演算子よりも上ですね。

これで問題ないのか
↓
sigma = tail . scanl (+) 0

>>270
レスありがとうございます。
早く慣れたいです。
まだ、頭で考えないとよくわからない。
(考えてもわからない時ありw)

272:デフォルトの名無しさん
08/06/24 11:35:10
>>266
「厳密には」も何も最初っからそう

273:デフォルトの名無しさん
08/06/24 12:56:24
>>266
> 覚えていないといけない
覚えてなくてもプログラム書くのにはなにも困らない。
等価性とか考えだすと全部正格のほうが楽かもしれんけど。

274:デフォルトの名無しさん
08/06/24 18:49:23
>>273
書くときは良くても読むとき困る
例えば>>260のコードが空リストに対しても正しく動作するかどうか確かめるのに、
いちいちPreludeの仕様を読まないといけない

zipみたいに明確な定義のある関数ならまだいいけど、
例えばhPutStrLn undefined ""の値が
1. ⊥
2. 実行時にエラーになるアクション
3. （）を返すアクション
のどれになるかは仕様では決まっていないはずで、ちょっと厄介

275:デフォルトの名無しさん
08/06/25 15:42:16
>>274
その辺は想像で読めば十分じゃない？

zip xs (tail xs) とあって、
コードを書いたのが信頼できる人なら、
zip は第二引数について非正格なのだろうな、とか。

hPutStr undefined "" も、
hPutStr _ "" = return () と定義されては無いだろうし、
undefined が正しいハンドルじゃないからと
hPutStr が独自にエラーを出すというのも、
先に undefined が評価されるから有り得ないだろう、とか。
hPutStr (error "1") (error "2") にしても error "1" だろう、とか。

276:デフォルトの名無しさん
08/06/25 15:49:33
ム板のやつらはなんでこんなに視野が狭いんだろうといつも思う。

277:デフォルトの名無しさん
08/06/25 17:38:53
3の場合

main「ちょっと undefined に "" 出力してこい」
hPutStrLn「へい」
...数十ns後
hPutStrLn「やってきやした」
main「おまｗｗｗｗ改行どうしたｗｗｗｗｗｗｗｗ」

>>276
正直くだらないネタ以外はここではなく他の所に書く。

278:デフォルトの名無しさん
08/06/25 18:27:02
質問です

HaskellでGPGPU関連の話題ってありませんか？

279:274
08/06/25 20:23:02
すまん、hPutStrLnじゃなくてhPutStrじゃないと話が合わないな

>>275
>コードを書いたのが信頼できる人なら、
勉強のためにコードを読んでるならいいけど、
レビューとかデバッグとかしてるならそうはいかないだろ

>hPutStr が独自にエラーを出すというのも、
誤解させたかもしれんが、HugsもGHCも2.の振る舞いをする
実行した時点でundefinedが評価されてエラー発生ね
でも、例えば最適化のために
hPutStr h s = seq h $ ...
みたいな実装になってたら1.だし、
hPutStr h s = mapM_ (hPutChar h) s
みたいな定義が考えられる以上3.もあり得なくはない

結局、非正格がデフォルトなせいで関数の仕様に書かなければいけない事項が多いのが問題
それを不用意にうやむやにすると関数の振る舞いが実装に依存してしまう
それほど頻繁に問題になることではないけど、たまに面倒

280:275
08/06/25 21:28:51
>>279
> レビューとかデバッグとかしてるならそうはいかないだろ
うん。

> hPutStr h s = mapM_ (hPutChar h) s
> みたいな定義が考えられる以上3.もあり得なくはない
なるほど。

> それほど頻繁に問題になることではないけど、たまに面倒
そういうこったね。

281:275
08/06/25 21:32:14
> 誤解させたかもしれんが、HugsもGHCも2.の振る舞いをする
> 実行した時点でundefinedが評価されてエラー発生ね

そういうつもりでしたか。
ちなみにそれだと1.はどういうつもりだったのですか？

282:デフォルトの名無しさん
08/06/25 21:49:44
>>281
hPutStr undefined "" `seq` 0
を評価してエラーが発生すれば1.だよな
実際試したらHugsでもGHCiでもエラーは発生しなかった

283:275
08/06/25 22:26:04
なるほど。というか>>279をちゃんと読んでませんでしたごめんなさい。

284:デフォルトの名無しさん
08/06/26 21:37:05
一通りよく取り上げられる教科書は読んだんですが、Arrowなどの
比較的新しい技法についてわかりやすく書かれた文書はどの辺
でしょうか。

285:デフォルトの名無しさん
08/06/26 23:11:25
本家から辿って論文を読むのがいいと思うよ。

286:デフォルトの名無しさん
08/06/26 23:16:36
Arrow　アーーー

287:デフォルトの名無しさん
08/06/26 23:28:26
arrowねぇ・・・イマイチだねぇ・・・
プログラミング的にはこれといってメリットないよ。

288:デフォルトの名無しさん
08/06/27 00:23:45
>>284
URLﾘﾝｸ(www.haskell.org)

289:デフォルトの名無しさん
08/06/28 00:05:34
arrowで量子コンピュータのシミュレーションやってます
めっちゃべんりですっっっっｓ

290:デフォルトの名無しさん
08/06/28 01:15:42
ユニタリ変換の理解が一つの山かも。

291:デフォルトの名無しさん
08/06/28 01:22:40
ユニタリ変換？高校生でも知ってるよ

292:デフォルトの名無しさん
08/06/28 10:42:43
皆さん、エディタは何使って書いてますか？

293:デフォルトの名無しさん
08/06/28 10:48:09
emacsしか選択肢ないんじゃね？
eclipseは糞だし。

294:デフォルトの名無しさん
08/06/28 11:10:10
vim

295:デフォルトの名無しさん
08/06/28 11:45:12
notepad.exe

296:デフォルトの名無しさん
08/06/28 12:32:37
vimやemacsだと使い勝手のいいプラグインあるんでしょうか。

自分もEclipseはちょっと嫌ですねぇ。

297:デフォルトの名無しさん
08/06/28 12:44:03
URLﾘﾝｸ(www.haskell.org) その他いろいろ

$ hugs -Evim

298:デフォルトの名無しさん
08/06/28 16:06:10
Haskellの構文解析ってどういう風な作りになってるん?
結合性宣言があったりするので、
トークン読んだ時点では構文木を作れないような気がするんだけど。

何かの資料とか、HugsやGHCでの実現方法のソースとかあったら教えてくだしあ

299:デフォルトの名無しさん
08/06/28 16:38:24
>>298
GHCはとりあえず全部左結合として解析(parser/Parse.y)して、
後のrenameのパスで結合性宣言をもとに組み立て直してる(rename/RnExpr.lhs)

300:デフォルトの名無しさん
08/06/28 16:57:55
>>292
俺もvimだわ
なんか文法と相性良さげだし

301:デフォルトの名無しさん
08/06/28 17:16:47
>>299
そういう手があったか。いや、全然関係ないパーサを先日作ってたんだが。
パス（1パスコンパイラとか2パスコンパイラとかのパス）にこだわっていては
非富豪的かねぇ。

302:デフォルトの名無しさん
08/06/28 18:10:34
左結合にするってのは、
とりあえずリンクトリストにしといてから、
あとでパーズしなおすって事。

303:デフォルトの名無しさん
08/06/28 18:39:00
>>292 俺はAgda使ってるよ。結構使いやすい。

304:デフォルトの名無しさん
08/06/28 20:10:12
project eulerに接続できねーぞ！！！
どうなってんだ糞

305:デフォルトの名無しさん
08/06/28 20:19:06
質問です

グラフの研究で路線データ(や道路のデータなど)が使いたいのですが、
そういうデータを手に入れるにはどうすればいいですか？

306:デフォルトの名無しさん
08/06/28 21:47:48
>>305
質問です

Haskellと関係ありますか？

307:298
08/06/28 22:27:19
>>299,302
thx、参考になった。
細かく追えてないけど、かなりがんばらないとparseできないってことか。

308:デフォルトの名無しさん
08/06/29 08:23:28
とりあえず左結合って要するにS式だよね。

309:デフォルトの名無しさん
08/07/01 18:44:49
Real World Haskell
URLﾘﾝｸ(www.amazon.co.jp)

> This easy-to-use, fast-moving tutorial introduces you to functional
> programming with Haskell. Learn how to use Haskell in a variety of
> practical ways, whether it's for short, script-like programs or large
> and demanding applications.

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)

次ページ