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

1 名前：潜伏していた1 mailto:sage [02/02/16 16:55] 何とか生き残れました。 前スレ pc.2ch.net/test/read.cgi/tech/996131288/l50 関連 >>2 以降 161 名前：153 mailto:sage [02/05/08 21:28] 仮想環境ッスかー？何ッスかー？ 162 名前：デフォルトの名無しさん [02/05/09 01:26] Parallel Graph reduction Virtual Machine (PGVM) ? 163 名前：134 [02/05/09 01:31] >>135 >ストリームは「いくらでも長くなりうる列」というデータだ。 確かに漏れも、そう思います。ストリーム() しかし、haskellのモデルではIO入出力はストリーム(ぎリスト)ではないですよね。 ということは結局、評価の順序が入出力に影響するはずですよね。 評価の順序を強制するためにモナドというものを利用しているんじゃないですかねー？ どうなんでしょ。 164 名前：デフォルトの名無しさん [02/05/09 01:48] www.yfcbookshelf.com/ml_lisp_scheme.htm ここの下の所に「Programming Languages：Concepts and Constructs 2/E」 の「日本語訳版を期待」という文字が見えるんですが、今翻訳中なのでしょうか？ もしそうなら超期待！！ >>158 どうも効率面を問題にされているようですが、 私自身たいして関数型言語の経験はありませんが、 仕事の関係上感じている事です。 コンパイラ作ってると、この副作用がないというのが 結構オプティマイズに有効だったりするので、 結構これからの言語の核にすえるのは悪くないと最近思ってます。 計算の依存関係が明白でないと最近のスーパスカラーみたいに 命令スケジュールが必要だと面倒です。 全体的とはいわなくても部分的には関数型言語が高速化への寄与大きいと考えています。 計算機の並列度が上がってくると、少し考え方を変えてみるのも悪くはないと思っています。 ちなみにモナドはあんまり良くわかっていません。(TT) だれか教えてくれー 165 名前：デフォルトの名無しさん mailto:sage [02/05/09 02:25] >>163 昔のバージョンではストリームでI/OやってたんだよHaskellは。 I/Oエラーが扱いにくくってなあ… モナドの方が楽だよ。 166 名前：134 [02/05/09 02:43] >>165 本当ですか？ 何時の頃のモノなんでしょう？ 処理系の名前とバージョンを教えてもらえませんか？ >I/Oエラーが扱いにくくってなあ… >モナドの方が楽だよ。 たしかに、そうですね。 うーん、モナドから逃げてるのかなー？俺は 167 名前：デフォルトの名無しさん mailto:sage [02/05/09 02:45] モナドを意味づける（動作を定義する）のにストリーム使えるしね。 168 名前：デフォルトの名無しさん [02/05/09 02:46] 副作用推進派のかた、もっと高階関数を活用してみては どうでしょう？ 関数も各引数を繋ぐための糊だと考えると 副作用が無いほうが嬉しいのでは？ 169 名前：158 mailto:sage [02/05/09 02:50] >>164 効率は計算機上での実行の際のことです。 ･･････というか効率を考えた動作をガチガチにプログラマが記述する際に 場合によってはあるほうが便利ということですね。 一方、最適化のためのプログラムの解析においては 一般に副作用がないほうがやりやすいのは確かだと思います。 だからこそ代入を消してSSAなんて形式に落としたりもするんでしょうし。 170 名前：158 mailto:sage [02/05/09 02:51] >>168 行列を配列並みの高効率で実装できる方法があるなら是非そう致したいと。 171 名前：158 mailto:sage [02/05/09 02:54] 引数で指されるオブジェクトがコピーのコストが気にならないほど小さいうちは それほど悩ましくないんですが･･････。 172 名前：デフォルトの名無しさん mailto:sage [02/05/09 02:57] >>166 Haskell 1.1まではそういう仕様だった。全ての準拠処理系がそうなって たはず。stream I/Oとcontinuation-based I/Oの両方が使えた。 www.haskell.org/definition/haskell-report-1.1.tar.gz Monadic I/Oがあんまり便利なんで今は全部そっち。 173 名前：デフォルトの名無しさん mailto:sage [02/05/09 03:04] >>170 配列使えばいいじゃん。副作用なしの。 SISALっていう関数型言語がそうやって、スーパーコンでも Fortranに負けない性能出してたよ。 Fortran厨は他の言語が書けなかったので普及しなかったが。 174 名前：デフォルトの名無しさん mailto:sage [02/05/09 08:17] なんかこのスレ人増えたな。 175 名前：158 mailto:sage [02/05/09 09:51] >>173 　www.sys.uea.ac.uk/~jrwg/Sisal/index.html を読んで見てるけど、やたら配列に特化した言語だなぁ。APLを思い出したよ。 サワリの部分を読んでの感想としては、 配列に特化した構文が多すぎるし、拡張性にも疑問が残る。 この言語を実装する上で研究された内容（解析や最適化の技術）は有益そうだが、 それをつかって書けと言われると結構苦痛かも。 CやFortranのソースに混ぜられると言われてもねぇ。 176 名前：158 mailto:sage [02/05/09 10:01] でついでに、「スーパーコンでも」というよりは むしろ「スーパーコンのために」開発されたようだ。 スパコン以外にも移植はされているようだが、 どうもメインの技術ははデータ並列っぽい気配が。 もっと詳しく読んでみないと判らない部分もあるが、 そうなると今時のマシンの記憶階層と マッチするかどうかは些か怪しげ。 177 名前：Super Combinator [02/05/09 11:43] MonadとInfinite listの関係について知りたければ、 "Comprehending Monads", Philip Wadler読め。面白い。 178 名前：デフォルトの名無しさん mailto:sage [02/05/09 13:23] >>176 文句の多いヤツだな。 179 名前：デフォルトの名無しさん mailto:sage [02/05/09 15:07] >>158 は >>173 を「Sisal 使えば?」と読んでそうな感じだが >>173 は「Haskell の副作用無しの配列使え」と言ってるのだろう。たぶん。 180 名前：デフォルトの名無しさん mailto:sage [02/05/09 20:50] >>179 どんな実装してるんでソ。＞「Haskell の副作用無しの配列使え」 私が読んだ何件かの「副作用なし配列」の論文は皆頑張っていたけどヤパ−リ オーバーヘッドが大きくて生の配列ほどには早くない･･････。 181 名前：デフォルトの名無しさん [02/05/09 21:06] >>132 >Prologにカットオペレータ カットオペレータ思い出した。これでProlog嫌いになった。 ところで、Prologも関数型かな？　副作用ないみたいだし。 真偽の２値のみを返すと考えられるかな。もっとも偽の値が 返ればストップするので真のみ返るが。 182 名前：デフォルトの名無しさん mailto:sage [02/05/09 21:22] >>181 関数型じゃないね。論理型。 項の「値」を求めてるわけじゃない。 定理を満足する変数の値の組（代入）を求めている。 両方を組み合わせた関数論理型ってのもあるけど。 183 名前：第５世代はどうなった [02/05/09 22:51] >>182 論理式の値を求めるのでなく、妥当な推論をするんだった。 unificationできなきゃ終わりという形式だったね。 Hugsのライブラリーに簡単なPrologあるね。 unificationなんかはもともとhaskellにあるから、 簡単に実装できるようだ。 そういえば、カットオペレーターもhaskellで実装 してたかな。 184 名前：デフォルトの名無しさん [02/05/10 00:36] haskellは非正格言語だからデバッグし辛いのでは？ 副作用がありまくる手続き型言語や正格言語ではデバッグで 苦労しない。というかデバッグしやすい。 非正格言語の優秀なデバッガって無いからね。 一つでもモデル(非正格言語のデバッガのね)が出来ればね。 185 名前：デフォルトの名無しさん mailto:age [02/05/10 03:55] Mondrianって言語がHaskellをコンパクトにして OO対応にしたような言語で、.NETにも対応してるらしい んだけど、この言語ってどうですか？ www.mondrian-script.org/ 186 名前：デフォルトの名無しさん mailto:sage [02/05/10 03:57] >>184 ていうか、副作用が無いってのはようするに 思わぬバグが混入しないようにする効果があるわけだから、 デバッグ以前にバグが混入しにくいのでは？ 187 名前：デフォルトの名無しさん mailto:sage [02/05/10 04:05] 代わりに呼び出し関係が入り組んでくるからねぇ。>>186 やっぱ銀の弾丸はないもんだよねぇ。 188 名前：デフォルトの名無しさん [02/05/12 02:28] >>186 でもバグが無くなる訳ではないでしょ？ 仕様のバグという根絶不可能なバグがあるんだから。 やっぱデバッガ必要でしょ。 189 名前：デフォルトの名無しさん mailto:sage [02/05/12 10:10] >>188 既存のデバッガ的な考えは合わないよね。 190 名前：デフォルトの名無しさん mailto:sage [02/05/12 19:07] >>184 副作用がないので Unit Test あたりが向いてるかも。 191 名前：デフォルトの名無しさん [02/05/13 22:37] www.haskell.org/libraries/#testing のあたりだろうか。 192 名前：デフォルトの名無しさん [02/05/13 22:39] >>188 仕様のバグとデバッガが関係あるんですか？ 193 名前：デフォルトの名無しさん mailto:sage [02/05/13 22:47] 副作用が無いんだから、 コードの打ち間違いと理論にだけ気をつければ やっていけます。 194 名前：Super Combinator [02/05/13 22:57] >>192 帰納推論系の人たちで、 間違った具体例の指摘から仕様を直したり、 なんて事が流行ったよね? そのengineのUI programはdebuggerと呼ばれることが多かった。 195 名前：デフォルトの名無しさん mailto:sage [02/05/13 22:59] なんじゃそら 屁理屈か 196 名前：デフォルトの名無しさん [02/05/14 16:02] つまり、従来のデバッガの役割は 非常に少なくなると言うことでいいのか？ 197 名前：デフォルトの名無しさん [02/05/15 00:14] デバッガの使い道ってバグを取るためだけの物かなー？ 198 名前：え？ [02/05/15 00:35] デバッガをバグ取りに使わないの？ 199 名前：デフォルトの名無しさん mailto:sage [02/05/15 01:06] >>198 プログラミング言語の前に日本語を勉強尻。 200 名前：え？ mailto:sage [02/05/15 01:16] >>199 君こそ根。 201 名前：デフォルトの名無しさん [02/05/15 01:24] Stream IOを勉強した頃は、同期関係の bugがあったら取り難そうだなあ、 とおもた。 Monadになったら改善できるのかしらん? 202 名前：デフォルトの名無しさん mailto:sage [02/05/15 01:28] >>198 はすさまじいアフォ 203 名前：デフォルトの名無しさん mailto:sage [02/05/15 01:28] >>201 並列処理の話？ 204 名前：え？ mailto:sage [02/05/15 01:29] >>199　は、すさまじいエロ 205 名前：デフォルトの名無しさん mailto:sage [02/05/15 01:38] ＞デバッガの使い道ってバグを取るためだけの物かなー？ 他に使い道は？ 206 名前：デフォルトの名無しさん mailto:sage [02/05/15 02:30] >>204 ウザイ 「バグ取りの他に使う」と「バグ取りに使わない」の 区別もつかない糞は小１からやりなおせヴォケ 207 名前：デフォルトの名無しさん [02/05/15 12:22] >>206 その前にお前は>>205の質問に答えろよ。 208 名前：デフォルトの名無しさん [02/05/15 13:45] 静的なプログラム検証ツールはデバッガの範疇に入るの？ こういうものが作りやすいのが関数型言語の特徴って言われてるから そっちに期待しちゃうな。あくまで素人の考えだけど。 209 名前：Ｃ厨房 mailto:sage [02/05/15 14:01] lintはデバッガって言うか？ 210 名前：デフォルトの名無しさん mailto:sage [02/05/15 14:24] なんでHaskellスレは厨房がワラワラと寄ってくるんだろ。 無視できない何かがあるんですかねー。 211 名前：206ではないが [02/05/15 14:28] 関数型言語にあてはまるかどうかは知らんが、 他人が書いたプログラム(またはライブラリ)を理解するために デバッガを使って動作を見るのは、けっこうよく使う手だと思う。 >>208 普通は静的な検証ツールはデバッガには含めないと思うけど、 参照透明性の高い関数型言語では、静的/動的の境界はどう定義するんだろう？ 例えば多相型の型エラーをデバッグするのって、静的なのか動的なのか… 212 名前：デフォルトの名無しさん mailto:sage [02/05/15 14:42] 言語理論に比べて処理系のセオリーが 弱い気がするのは気のせいでしょうか？>>211 213 名前：デフォルトの名無しさん [02/05/15 15:27] >>210 お前のような厨房がな。 214 名前：201 mailto:sage [02/05/16 00:31] >>203 並列って言うか、そもそも関数型言語は逐次処理でもないじゃん。 木の好き勝手なところを簡約していくっていうか。 そでで再帰的に定義された無限リストの簡約とかまちがうとこわいな。と。 P.Wadlerの入門書にもそれがらみの話あったよねえ? 215 名前：デフォルトの名無しさん [02/05/16 01:21] 関数プログラミングでは、動作手順を記述するわけではないので、命令プログラミングの 動作をステップ実行する従来のデバッグ手法のイメージとはあいいれないかも。 でも、計算順序を無理矢理いれこむ、モナドIO使いまくりのプログラミングなら 命令プログラミングとおんなじだから、print デバッグができるよ。 216 名前：デフォルトの名無しさん [02/05/16 01:39] Windowの表示とかやる場合はモナド使うんですか？ 関数型でイベント駆動処理を書くのって、 ちょっと想像できないんですが。 217 名前：デフォルトの名無しさん mailto:sage [02/05/16 13:57] Fudgetあげ ようとしたけど古いから sage 218 名前：デフォルトの名無しさん [02/05/16 14:49] >>216 GTK+HS のサンプルコードとかみてみれば？ 219 名前：デフォルトの名無しさん mailto:sage [02/05/16 17:00] >>216 モナドによるI/Oのコードをじっとみつめると 入力列内の文字種に応じて呼ばれるハンドラの集まりとも見えてくる。 それがメッセージ列に変わったと思えば書けそうな気がしてくる。 220 名前：デフォルトの名無しさん [02/05/17 06:30] >>205 処理系の実行過程の確認 最適化の結果、プログラマーの予想もしないプログラムに変化したりしないとか その確認をする。勉強にもなるね。 某本にもデバッガでは、シングルステップを使えと載っていた。目から鱗。 221 名前：デフォルトの名無しさん [02/05/17 11:20] >>215 GHCか何かだと、unsafeとか何とかいうモジュールに、 どこでもprintできる関数がなかったっけ。 まさにprintfデバッグのための抜け道として。 222 名前：デフォルトの名無しさん [02/05/17 13:19] >>220 それは要するにデバッガがアナライザだって言ってるだけでは？ そういうのとは微妙に話が違うような気がするなー。 つまり、デバッガにはそういうブラウジング機能とは別に 何かあるって言ってるんだろ？ 223 名前：デフォルトの名無しさん [02/05/17 17:10] >>222 いや、デバッグ以外に使い道があるかどうかって話だろ？ だからアナライザとして使ったり、ってのも答えとしてアリだろ。 224 名前：デフォルトの名無しさん [02/05/17 18:54] ナスです。 225 名前：デフォルトの名無しさん mailto:sage [02/05/18 05:44] ウリです。 226 名前：デフォルトの名無しさん mailto:sage [02/05/18 05:45] デバッガっでようするにアナライザだろ。 デバッガがバグを指摘するわけじゃなし。 227 名前：デフォルトの名無しさん mailto:sage [02/05/18 13:13] >>226 書くのが遅い 228 名前：デフォルトの名無しさん [02/05/19 20:37] >>221 遅延評価だと、どのprintが先に実行されるかわかんなくねえ？ そんなんでデバッグできるのか？ 229 名前：デフォルトの名無しさん mailto:sage [02/05/19 21:05] >>228 何をデバッグしたいかによるけど。 (文字列やファイルの最終的な内容も含めた)計算結果が 正しければ良いなら、別に求まる順序は重要じゃないよね。 まあprintを使うってことは順序も気にするんだろうから、 もともと$!やseqを使いまくってるんじゃないの？ 230 名前：haskell [02/05/26 07:37] age 231 名前：デフォルトの名無しさん [02/05/26 13:54] 高階関数に詳しくなりたいので教えて。 232 名前：Super Combinator [02/05/26 14:22] Bird「関数プログラミング」 www.amazon.co.jp/exec/obidos/ASIN/4764901811/qid=1022390348/sr=1-17/ref=sr_1_2_17/250-5692221-3686632 萩谷昌己「関数プログラミング」 www.amazon.co.jp/exec/obidos/ASIN/4535608172/250-5692221-3686632 あたりで。 233 名前：デフォルトの名無しさん [02/05/26 18:09] まさみさまがそんな本書いているとはしらなんだ.. 竹内先生の Lisp本もじつは読んでないんだよなあ。 234 名前：デフォルトの名無しさん mailto:sage [02/05/26 20:36] 日本語で書かれたHaskell本はいつ頃出ますか？ SMLだって出てるのに……。 235 名前：デフォルトの名無しさん mailto:sage [02/05/26 22:00] >>234 日本のHaskellユーザの数が、初回印刷部数(200)を越えたら。 236 名前：デフォルトの名無しさん mailto:sage [02/05/26 22:42] ユーザの数はどうやって数えるんですか？ 237 名前：デフォルトの名無しさん mailto:sage [02/05/26 23:11] うちの研究室だけで10人はいるんだから簡単に超えそうなもんだけど(藁 238 名前：デフォルトの名無しさん mailto:sage [02/05/26 23:14] >>237 そこが特別なんじゃないの？ 239 名前：デフォルトの名無しさん mailto:sage [02/05/26 23:31] じゃ、漏れが布教用に3冊買ってやるから、早く出してくれよ。 訳本でいいからさ。 240 名前：デフォルトの名無しさん mailto:sage [02/05/26 23:46] つーかさ、200位だったら、 いろんな図書館に要望しまくれば、 なんとかなるんじゃないの？ 241 名前：デフォルトの名無しさん mailto:sage [02/05/27 00:06] 200じゃだめみたい。 www.onweb.to/ken9/log/039.htm 242 名前：デフォルトの名無しさん mailto:sage [02/05/27 11:55] >>237 ここのところ素人も増えてるぞ＞オレオレ 243 名前：デフォルトの名無しさん mailto:sage [02/05/28 02:43] 有明で売れよ! ってことですか? 244 名前：デフォルトの名無しさん mailto:sage [02/05/28 10:52] >>243 東京ビッグサイトの巨大同人誌即売会サークル抽選当選しますた。 でもジャンルはプログラミング言語とはホド遠いけど(w。 245 名前：デフォルトの名無しさん mailto:sage [02/05/28 22:01] >>244 適当でいいからHaskell本もきぼんぬ 買いに行くから(藁 246 名前：244 mailto:sage [02/05/29 14:49] ウチはなんと女装本だぞ。それでも買いに来られるか？（ｗ って、実際問題としてHaskell本を作る余力はなし。 247 名前：デフォルトの名無しさん mailto:sage [02/06/04 16:02] Haskell本かどうかは分からんが、 R. Birdの「関数プログラミング」第２版を翻訳して出版して欲しい。 流れで近代科学社に。 248 名前：デフォルトの名無しさん [02/06/04 19:43] 今売ってる「関数プログラミング」も、 みなしHaskell本では。 249 名前：デフォルトの名無しさん mailto:sage [02/06/04 22:27] ぶっちゃけた話、古いわけよ。 250 名前：デフォルトの名無しさん [02/06/05 00:02] で。 結局、日本語のHaskellの本て有るんですか？ 無いんですか？ （というのか無いのか？） 251 名前：デフォルトの名無しさん [02/06/05 02:13] >>237 おどろき。 どんな研究なんだ！？ 252 名前：デフォルトの名無しさん [02/06/05 15:33] >>237 ならむしろおまえの研究室で発行しる！ 253 名前：デフォルトの名無しさん mailto:sage [02/06/05 21:53] F#のサイトより転載。 Purely functional languages like Haskell are excellent within certain niches, but many simple programming exercises can quickly turn into problems that require a PhD. to solve. 大げさだな・・・ 254 名前：デフォルトの名無しさん mailto:sage [02/06/05 22:30] うまいこというな〜 255 名前：デフォルトの名無しさん [02/06/06 21:13] 女装+Haskell本期待age 256 名前：デフォルトの名無しさん [02/06/06 23:28] 「女装しながら覚えるHASKELL」 257 名前：デフォルトの名無しさん [02/06/06 23:29] 「HASKELLによる女装プログラミングの理論と実践」 258 名前：Super Combinator mailto:sage [02/06/07 07:40] Mocking Bird, "Introduction to Female Attire using Haskell", Price Sale, 2002. 259 名前：デフォルトの名無しさん [02/06/07 13:06] Purely functional languages like Haskell are excellent within certain niches, but many simple programming exercises can quickly turn into problems that require a Female Attire. to solve. 260 名前：デフォルトの名無しさん mailto:sage [02/06/07 13:20] ネタスレ化か？ 261 名前：デフォルトの名無しさん [02/06/07 22:26] 女装した場合には、その人の参照の透明性はどう確保されるのでしょうか？

---

---

[ 続きを読む ] / [ 携帯版 ]

read.cgi ver5.27 [feat.BBS2 +1.6] / e.0.2 (02/09/03) / eucaly.net products.
担当:undef