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

[過去ﾛｸﾞ] 関数型プログラミング言語Haskell Part4 (1001ﾚｽ)
上下前次 1-新

このｽﾚｯﾄﾞは過去ﾛｸﾞ倉庫に格納されています｡
次ｽﾚ検索歴削→次ｽﾚ栞削→次ｽﾚ過去ﾛｸﾞﾒﾆｭｰ

381: 2006/04/16(日)00:50 AAS
てめー三輪車なめんなよ？

382(4): 2006/04/16(日)10:20 AAS
すいません。関数型マスターのかたがたにお伺いしたいんですが･･･
手続き型に比べて関数型が生産性高いといわれているのですが、それはどのようなところから着てるんでしょうか？
またそれはC++のテンプレート、それを応用したSTL,Boostなどの総称プログラミング、C#のGenerics,delegate、Reflection,CodeDOM、属性などを使って代替することは出来ないものなのでしょうか？

383: 2006/04/16(日)10:40 AAS
嫁
外部ﾘﾝｸ[html]:www.sampou.org

384(2): 2006/04/16(日)11:28 AAS
>>382
・Haskellは関数型言語です。
・関数型言語とは関数中心のプログラミング言語です。
・関数は入力に対して出力を返します。
・関数型言語には代入が存在しません。

Haskellのメリット
・プログラムが短く書ける
省4

385(1): 2006/04/16(日)11:34 AAS
>>384　
この代入がないっていう部分が理解できてないんですね。手続き型と考え方が違うんだろうけどそれがわかってない。
オブジェクトという概念はもたないんですか？この場合オブジェクトとは状態をを持つ何かとします。
たとえば、押されている状態とそうでない状態のどちらかを持つチェックボックスとか。
逆にそういうものをHaskellで取り扱いする場合にはどうするんでしょう？

386: 2006/04/16(日)11:46 AAS
>>385
レコード型とか使ったらできるんじゃない？

387(1): 2006/04/16(日)12:15 AAS
>>384
「代入がない」といういい方は不正確だと思う。
必要ならいつでもIORef, STRefを使って代入を表現できる。
「不必要に代入を使うことを強制されない」と言った方がいいんじゃないか。

388(1): 2006/04/16(日)12:17 AAS
つーかそこらへん関数型の肝なんだから興味あるなら入門記事でも読めや。

389(1): 2006/04/16(日)12:26 AAS
>>387
それよりもむしろ　代入文がない　の方が正しいかも？

390(3): 2006/04/16(日)12:31 AAS
>>388　いい記事見つけられなかったのかもしれんし、自分の理解足りないと思うんだが代入とかしないでどう処理を進めてくのかがまったく理解できんのよ。

391: 2006/04/16(日)12:33 AAS
>>390
つ　モナド

392: 2006/04/16(日)12:33 AAS
>>389
それはメリットなのか？

393(1): 2006/04/16(日)12:35 AAS
>>390
まず、遅延評価は理解してる？

あと、プログラミングが「慣れ」であることは大体は共通の認識だろうけど、
とりあえずサンプルプログラムをたくさん見るべきだね。

394(1): 2006/04/16(日)12:36 AAS
>>390
まず、入出力の絡まない処理が代入無しでできるのは分かるか？

395: 2006/04/16(日)12:37 AAS
>>393
遅延評価は無関係かと。

396(1): 2006/04/16(日)12:48 AAS
具体的なコードを例示して教えてくださいよ。
話のわからない人たちですね。

397(2): 2006/04/16(日)12:51 AAS
>>394　理解できていないかも。
自分の中でプログラムのイメージは複数ある生成･消滅するオブジェクトの状態が、複数の実行スレッドによって変わり行くさまというものなので。
代入なしでオブジェクトの状態を変えることができるのか？という疑問が。
その考え方と関数型のものの考え方はまったく異なるんですかね？

398: 2006/04/16(日)12:54 AAS
>>396
いつでも聞けば答えてもらえると思うなよ。
例が見たいなら自分で調べろ。
Haskellを広めたい人がHaskellで書いたプログラムをオープンソースとして公開しているはずだ。

399(1): 2006/04/16(日)13:02 AAS
ダメだ。ここの住民生産性低杉。

400(1): 2006/04/16(日)13:06 AAS
>>397
効率を考えない方法だと、状態の違うオブジェクトを毎回生成するような感じ。

### 手続き的なOOP
#oldobj = obj.copy
rtn_val = obj.do_something
#newobj = obj.copy
## newobj.state != oldobj.state
省3

401(1): 2006/04/16(日)13:12 AAS
>>397
個々のデータを、「生成・消滅するオブジェクト」と見る代わりに、
「単なる無個性な値」とみなす。
例えば、住所録を扱うことを考えると、手続き型言語では
「空の住所録オブジェクトを生成し、そこにfoo氏の情報を追加し、bar氏の情報を追加し、…」
と操作するのに対し、関数型言語では、
「「空の住所録にfoo氏の情報を追加したもの」にbar氏の情報を追加したものを、…」
省3

402(1): 2006/04/16(日)13:15 AAS
>>400　・・・わからんです・・・
オブジェクトを毎回生成するのは元のオブジェクトを元に生成？
そうでないなら、どうやってそのオブジェクトの状態の整合性を保障する？
オブジェクトで考えないほうがいいのかな･･･

403(1): 2006/04/16(日)13:22 AAS
>>401　その場合手続き型の考え方のほうが自然に思えるんですが・・・
関数型で住所録にfoo氏及びbar氏の情報を登録したい場合、「foo氏及びbar氏の情報を含む住所録」を作るとして、
今度それにあとからdog氏を追加したい場合、「foo氏及びbar氏の情報を含む住所録」というのはどこかにとっといてるんですよね？それを元に「foo氏及びbar氏及びdog氏の情報を含む住所録」をつくると。
だとしたら形式的には毎回オブジェクトを生成してるのかもしれないけれど、実質的には住所録オブジェクトに住所オブジェクトを追加すると変わらない？

404: 2006/04/16(日)13:25 AAS
object is poormans closer!!!!!!!!!!!!

405(1): 2006/04/16(日)13:31 AAS
>>402
>オブジェクトを毎回生成するのは元のオブジェクトを元に生成？

当然。そのためにobjを引数に取っている。

>>403
>実質的には住所録オブジェクトに住所オブジェクトを追加すると変わらない？

常に最新の住所録オブジェクトだけを利用し続けるのであればそう。

406: 2006/04/16(日)13:32 AAS
関数の引数に住所録を持たせる。

407(2): 2006/04/16(日)13:38 AAS
>>405　住所録を複数の場所（入力処理、削除処理、検索処理、表示処理)から扱いたい場合、結局は最新の状態である住所録をどこかに保持しないといけないんですよね？
だとしたら、それがどのように関数型のメリットであるプログラムが煩雑にならない？とむすびつくのでしょう？
それとも考え方がおかしい？

408: 2006/04/16(日)14:00 AAS
>>407
確かに、「最新の住所録」という唯一の住所録があって、それを操作することにしか興味がない場合は、
「プログラムが煩雑にならない」は当てはまらないかもしれない。

409: 2006/04/16(日)14:03 AAS
>>407
>だとしたら、それがどのように関数型のメリットであるプログラムが煩雑にならない？とむすびつくのでしょう？

全部が全部煩雑にならないように出来るというわけではないよ。
状態変化とかは手続き型で書いた方が簡単だし。

OOPではデータの特徴を括りだして共通した操作をクラスにまとめ上げるけど、
関数型では処理の共通部分を括りだしてより抽象化した関数にまとめる感じ。

410: 2006/04/16(日)14:15 AAS
object is poormans closer!!!!!!!!!!!!

411: 2006/04/16(日)15:09 AAS
外部ﾘﾝｸ:www.ipl.t.u-tokyo.ac.jp
外部ﾘﾝｸ[html]:www.ipl.t.u-tokyo.ac.jp

ここら辺見てみたらどう？実務アプリケーションじゃないけど。

412(4): 2006/04/16(日)16:19 AAS
結局、明確な生産性の差を述べるレスはなしですか・・・

413: 2006/04/16(日)16:26 AAS
>>412
研究中です。

414(1): 2006/04/16(日)16:32 AAS
>>412
「聞けば答えが返ってくるような問題」なら、ググれといわれるだろう。
研究的価値があるのはそれ以上のことで、
たとえアイデアがあったとしても、研究も競争なのでこんなところでは書かないし、
すぐに思いつくようなことなら「聞けば答えが返ってくるような問題」になるから。

415(1): 2006/04/16(日)16:34 AAS
>>414　説明できないのはわかってないから。これまでの質問でそんな研究のことなんか誰も聞いてないことぐらいわかるだろうに・・・

416: 2006/04/16(日)16:35 AAS
なんて生意気な質問者なんだろう。
俺は放置するよ。

417: 2006/04/16(日)16:41 AAS
>>412
そんなに生産性が気になるなら自分で勉強して試してみてくれ。
それだけの調査にも値しないと思うなら世間の評価が固まるまで待てばいい。
Haskellを学んでいて分からないところがあるならここで聞いてくれれば喜んで手伝うが、
生産性の高さを自慢するような芸当は少なくとも俺にはできん。

418: 382 2006/04/16(日)16:41 AAS
>>415は自分じゃないです。

419: 382 2006/04/16(日)16:42 AAS
>>412も

420(1): 2006/04/16(日)17:52 AAS
誰だよ、関数型言語を使うと生産性があがる、なんて宣伝した奴は。
関数型言語は他にはない高度な抽象化機能を提供する、とでも言っておけば良かったのに。

421: 2006/04/16(日)17:59 AAS
誰も、手続き型との違いを言えません。本当にありがとうございました。

422: 2006/04/16(日)18:00 AAS
>>420
とりあえず胡先生は、そう言ってた。

423: 2006/04/16(日)18:00 AAS
そもそも違いなど尋ねられていないわけだが。

424(1): 2006/04/16(日)18:02 AAS
生産性が高い→違いがあることから生じる。
読解力だかめとこうや。

425(1): 2006/04/16(日)18:10 AAS
>>424
論法がおかしい。
違いを挙げろというなら簡単だ。
それらの違いのうち、何が生産性の差をもたらすかという質問はまた別の話だ。

426(1): 2006/04/16(日)18:11 AAS
>>425　すまん。それらの違いのうち、何が生産性の差をもたらすかという質問にしてくれ。

427: 2006/04/16(日)18:13 AAS
「Productivity Haskell」という本を書いたら買いますか？

428(1): 2006/04/16(日)18:29 AAS
>>382
やろうと思えば大体は代替出来る。

429(1): 2006/04/16(日)18:36 AAS
>>428　それは、CでC++みたいなクラスをまねるようなもので作りやすさでは段違いということなんでせう？

430: 2006/04/16(日)18:43 AAS
根拠のない生産性を強調しすぎると、
RubyやCurlみたいな立場になるぞ。

せいぜい面白い言語です、にとどめておけばアンチも出ない。

こんなこと今更言っても既にRubyの道を辿っているようにしか見えない。乙。

431: 2006/04/16(日)18:44 AAS
>>429
書きやすいということだけではなく、エラーチェックとかのデバッグ面でも段違いだと思う。

432(4): 2006/04/16(日)19:01 AAS
>>426
考えてみた。あまり当てにしないでくれ。括弧内はそれを可能にする言語要素。

1.抽象化の能力
分離できる概念はかなりの確率で分けて定義できる。(代数的データ型、遅延評価)
共通部分のある処理はかなりの確率で共通化できる。(高階関数)

2.コードの簡潔さ
不要なものを書く必要がない。(変数の値が不変であること)
省6

433: 2006/04/16(日)19:19 AAS
C++のテンプレートって展開が停止するかどうかっていう判定が不可能らしいね。

434: 2006/04/16(日)19:30 AAS
17回でちょんぎっていいことになってるんでコンパイラは困らない。
ユーザは困るが。

435: 2006/04/16(日)19:31 AAS
フィボナッチ書けるだろ

436: 2006/04/16(日)19:32 AAS
だからここでC++の話をするなと

437(2): 2006/04/16(日)19:33 AAS
>>432
ちょっと聞いてもらえます？
ヒドイんです…。今の彼とは、もぉ～えっちしたくないんです。
なにがヒドイって、めっちゃくちゃイクの早いんです。
どんなに頑張っても３分間…３分間ファッキングですよ(>。<)
「絵里のアソコが物凄い喰いついてくるんだ」って言うから
私のせいなのかもしれないけど、このままじゃ困っちゃう！
省6

438: 2006/04/16(日)19:36 AAS
>>437
彼に遅延評価してもらえ。
実際に評価するまでは速く動くだろうよ。

439: 2006/04/16(日)19:54 AAS
>>437
eagerの限界だな

440(1): 2006/04/16(日)19:55 AAS
ありがとう。
やってみたけど、正格性解析されて一気に評価されちゃいました。。。

441: 2006/04/16(日)20:00 AAS
>>440
そりゃ、あなたが解析しやすい、単純な女だからさ。

442: 2006/04/16(日)20:42 AAS
ネタはネタスレで

443: 2006/04/16(日)20:46 AAS
ネタはネタスレで

444: 2006/04/16(日)20:46 AAS
ネタはネタスレで

445: 2006/04/16(日)20:50 AAS
ネタはネタスレで？

446(1): 2006/04/16(日)21:04 AAS
このスレのPart1の過去ログは読んで役に立った。
今のスレは役に立たない。

447(2): 2006/04/16(日)21:15 AAS
>>432　２．は状態がないということに関連するの？

448: 2006/04/16(日)21:19 AAS
>>446
自分が役に立とうという気はないらしいな

449(6): 2006/04/16(日)21:21 AAS
>>432
これ読んだか？外部ﾘﾝｸ[html]:www.sampou.org

なんで 1.はほぼ同等なんだ？C++で持ち運んで代入したりできるものといったらプリミティブぐらいだろ？
もっと高位の抽象化の話ならBASICやアセンブラでもできるぞ？

比較するんならC++みたいなメモリリークが起こるバキーな言語じゃなくてJavaとかの方がまだましだと思うんだが。

450: 2006/04/16(日)21:30 AAS
>>447
新しいインスタンスを得るのにわざわざnewしたり、既存のものをcopyしたりするのは面倒。
それから、Haskellのコードが簡潔になる傾向がある原因の一つとして、
Haskellでは繰り返しを表現するのに明示的な再帰ではなくリスト操作を使うことが多いんだが、
そういうときリストをサクサク使い捨てることができないととても不便。

451: 2006/04/16(日)21:33 AAS
>>449
>なんで 1.はほぼ同等なんだ？C++で持ち運んで代入したりできるものといったらプリミティブぐらいだろ？
ユーザー定義型を持ち運んだり代入したりできる。
書き忘れてたけど、>>432で「C++」と言ってるのは
Boost(や、場合によってはFC++)などのライブラリを十分活用した場合の話。

452: 2006/04/16(日)21:40 AAS
Boostには、例えば次のものが含まれている。
function 第一級の関数
optional Maybeに相当
variant 代数的データ型に相当
lambda 無名関数を構築するためのコンビネータライブラリ関数の部分適用もできる
tuple タプル
iterator 遅延リストのようなもの
省2

453(1): 2006/04/16(日)21:45 AAS
なんか賑わってますね。
ようやくhaskellの真の実力が世間に認知され始めたのかな？

454: 2006/04/16(日)21:50 AAS
>>449　C#ならどう？

455: 2006/04/16(日)22:11 AAS
あんな本でも、日本語の本の影響は大きいんだな。
むしろ、あんな本だから影響が大きいのか。

456: 2006/04/16(日)22:24 AAS
>>453
ごめんなさい。
はじめの方で自演していました。
あまりに人が少なかったから。

457(1): 449 2006/04/16(日)22:25 AAS
真面目なスレですね。通りすがりで後ろのほうだけ読んだせいで煽り気味の文章を書いてしまったのでフォローします。

C++でアルゴリズムや型を抽象化するには必ずクラスやテンプレートを定義しなければならない。

関数型言語の場合は、とりあえず書き始めてアルゴリズムができてきたらその部分をコピーしたり必要ならクロージャに入れて外で使うなり関数内で移動するなり割と簡単にできる。

関数の引数が増えた、とかローカル変数を共有したくなったりしたら、その時点で型を作るなり言語の抽象化機能を使う。（これ自体はC++でもできる）

型の実装を変更しても、ML以降の関数型ならアルゴリズムの実装の変更に対して型を推論させながら修正できるから、わりとスムーズに移行できる。インタプリタがあることが多いのでその場合はリターンも早い。
省1

458: 449 2006/04/16(日)22:26 AAS
(つづき)
カリー化その他の抽象化能力の話もいろいろありますが、こういう感じで関数型言語は書きながら抽象化を進めていくのが容易だ、と言えると思います。
この話はC、C++(Boost含む）、Java、C#、Basic、その他手続き型言語とML以降の関数型言語との比較に於て言える内容でしょう。

>比較するんならC++みたいなメモリリークが起こるバキーな言語じゃなくて
これがまずかったみたいですね。煽るつもりはありませんので。

459(1): 449 2006/04/16(日)22:29 AAS
読み返したら口調が変わりすぎて気持悪いから自分でツッコミ入れとく

460: 2006/04/16(日)22:32 AAS
AA省

461: 2006/04/16(日)22:37 AAS
こっちみんな

上下前次 1-新書関写板覧索設栞歴

あと 540 ﾚｽあります
ｽﾚ情報赤ﾚｽ抽出画像ﾚｽ抽出歴の未読ｽﾚ AAｻﾑﾈｲﾙ

ぬこの手ぬこTOP 0.025s