02/02/16 18:44
> なんで使ってくれないんだ?
そんなに Haskell 側に立ってる感じでもないような。
9:age
02/02/17 11:17
module A where
data A a = A a
f = id
g :: a -> a
g = A.f
h :: a -> A a
h = A .f
10:デフォルトの名無しさん
02/02/18 12:20
age
11:デフォルトの名無しさん
02/02/18 15:06
>>8
胴囲
どっちかというと、Haskell擁護者よ。
Haskellを普及させたいなら、もっと頑張れみたいな。
たしかにHaskellには、一般向けアプリを作りるには足りないものが多いなー。
TCP/IP鯖作るにしても、ライブラリ作るところから始めなきゃいけないし。(多分)
鯖にTimeOut処理付けるにしても、Timer関数ないし、競争書き込みもしないから
各関数にTimeOut処理付けるしかないのかな？
と言うわけでParalell Haskell燃えー。(といっても何かは知らんがね)
12:デフォルトの名無しさん
02/02/18 15:49
> と言うわけでParalell Haskell燃えー。(といっても何かは知らんがね)
どうしてそういう結論につながるんだよ!
と思ったが、前スレに出てた Paralell Haskell で書かれた web server のことで…か。
とりあえずあれは Paralell Haskell だからライブラリがあるわけでなく
ただ単に GHC に付いてる ライブラリ使ってるだけっぽいですよ。
13:11
02/02/18 16:40
いやー。
こんな関数がほしいのよ。(Haskell消防なので笑わないでね)
readWithTimeOut :: Socket -> Int -> Maybe String
readWithTimeOut s ms = timer ms Nothing || read s
関数timer::Int->a->aは指定された時間簡約が停止する。
その後2番目の引数を返す
関数read::Socket->StringはTCP/IPにデータが来るまで簡約が停止する。
ソケットからByte列をStringとして返す。
演算子||は、競争書き込み。全ての最初に帰ってきた値を値として返す。
他の簡約は、もちろん正常に停止、消去(GC?)される。
もちろん a = b || c || dと複数書ける。
(競争に負けた簡約は、どうしたらいいんだろう？うーん、キャッシュしておく？)
ってParallell G-mahineを実装しているHaskellでも可かな？
このようなことのできる処理系あったら誰か教えて。お願いします。
14:デフォルトの名無しさん
02/02/18 18:05
Parallel と Concurrent ってどう違うんですか?
15:デフォルトの名無しさん
02/02/18 22:36
お前はどう違うと思うんだよ
16:デフォルトの名無しさん
02/02/19 21:28
Hugs98にはWin32グラフィックライブラリがついているが、
コンパイラ(GHC)の方にはグラフィック関係のライブラリない
みたい。Hugsでライフゲーム作ってみたけど、遅いので
コンパイルしたいが、GHC使ったことないので教えてくれ。
アニメーションもストリームにしちゃうから、グラフィックIO
も遅延評価じゃなきゃいけないが、このあたりがライブラリー
の作成を難しくしているのかな。
17:デフォルトの名無しさん
02/02/21 16:56
なんと、同じ名前で新スレとは！
なんたる！
18:デフォルトの名無しさん
02/02/21 17:10
>>17
参照の透明性が…（泣
19:デフォルトの名無しさん
02/02/21 17:23
>>1 は Haskellにお詫びしろ。
貴様は代入を行った（笑
20:デフォルトの名無しさん
02/02/21 18:07
実はMonadを使って回避されています……ってワケにも行かないか。>>19
21:デフォルトの名無しさん
02/02/21 18:39
>>17-20
ﾜﾗﾀ
22:デフォルトの名無しさん
02/02/21 20:29
17=18=19 の自作自演じゃない。
参照透明性くずすな。
23:17
02/02/21 20:33
私は17しか書きこんでないっ！
24:22
02/02/21 20:41
失礼。
17－20うまくオチが決まってたので、チャチをいれたくなった（笑）
25:17
02/02/22 01:37
もしかしたら、再帰呼び出しなのかもしれないな（笑
＃だとしたら次スレも同じ名前？（笑
26:デフォルトの名無しさん
02/02/22 02:55
「おっ、Haskell スレにいっぱいレスが付いてる」と思ったら…
27:20
02/02/22 04:51
代入と配列（あるいは大きなオブジェクトの部分更新）とMonadの関係について
丁度悩ましい思いをしてるトコなもんで(w。
>>25
その場合、このスレに関する型推論はどうなるのでありますか？(w
28:面白そうだけど、調べた事ないー
02/02/22 19:53
>>27 やってたやってた、蓬莱軒行った奴がそういうテーマ。
なんか、プログラムの停止性と関連付けて、
停止する関数と停止しない関数に分けるのかな？
多相型と関連付けると、ちいと面倒な結果になりそう...
＃真面目に調べたことないけど
29:20
02/02/23 12:55
>>28
蓬莱研？もしかすると物理的に近所かもしれない……(w。
ちなみに特に関心があるのはその実装と効率なんでスヨ。
今、メインで悩んでる課題ではないんだけどね。
30:デフォルトの名無しさん
02/02/24 05:33
ghcを使ってちょこちょこ簡単なプログラムを
作って遊んでます。が、しかし！
コンパイルが異常に遅いです。
ghcってHaskellで書いてあるんですよね？
だとしたらHaskellで書かれたプログラムは
遅いということになったりして・・・鬱
実際にghcでアプリケーション作ってる人の
感想を聞かせてください。
31:デフォルトの名無しさん
02/02/26 14:59
hoshu age
32:デフォルトの名無しさん
02/02/26 15:00
URLﾘﾝｸ(www.mondrian-script.org)
これはなんでしょうか？
33:デフォルトの名無しさん
02/02/28 04:08
乱数を生成関数では、素直に考えると
参照透明性が確保できませんよね？
（実行するたび帰り値が違うんですから。）
なんとか参照透明性を確保する方法ってないのでしょうか？
誰か教えてください。
34:デフォルトの名無しさん
02/02/28 04:13
>>32
おおHaskell.NETのBetaすか？
いいですねー。
今度Downしてみよう。
35:デフォルトの名無しさん
02/02/28 04:26
>>33
「入力」の仲間だと思えば継続(continuation)かMonadかなぁ。
無限リストで乱数列を表し遅延評価というのも、
形式的には面白いが実際に書くと重いだろうなぁ。
まー、擬似乱数を線形合同法とかでつくるなら、
お手軽には直前に出力された数を呼出し毎に渡すとか……。
36:デフォルトの名無しさん
02/02/28 06:50
>>33
URLﾘﾝｸ(www.sampou.org)
ほとんど>>35の言う通りのやり方。
>>35
> 無限リストで乱数列を表し遅延評価というのも、
> 形式的には面白いが実際に書くと重いだろうなぁ。
そこまで重くなるとは思えないけど?
というか、他の部分も遅いだろうから、
特別その部分が遅い気はしないだろうっていうほうが正しいか(w
37:33
02/02/28 13:23
>>35 >>36
お答えいただき有難うございます。
>URLﾘﾝｸ(www.sampou.org)
この方法ですか。なるほど。
質問してから解決策を考えていたのですが
乱数表を使うか、この方法かどちらかかなとしかないかなと
思っていたので納得出来ました。
それにしてもHaskellのIO型って変ですね。(名前が)
非決定なものは、すべてIO型なんですね。
うーん、もっと良いネーミングしてほしい。
38:デフォルトの名無しさん
02/02/28 13:35
Linux の /dev/random みたいなものかと
39:デフォルトの名無しさん
02/03/01 09:20
>>36
重くなるっていうか、乱数って最新の一個だけが必要なことが多いから
過去の値が全部リストになって残ると、沢山利用した時にメモリを無駄に圧迫するかなと。
GCで回収されるならまだいいんだけど。
40:デフォルトの名無しさん
02/03/01 15:50
>>39
参照されていないオブジェクトは回収されないんですか？
41:デフォルトの名無しさん
02/03/02 04:02
>>40
クライアントは再帰中なので、
生成された乱数は、参照可能だからかな？
そりゃ、回収されんわな。
42:デフォルトの名無しさん
02/03/02 11:59
>>37
IO monadは、最初は本当に入出力用だったのに、
後からいろいろと付け足したのだと思われ。
別々のmonadにすればいいじゃん、と思うかもしれないが
一緒に使いたくなったときに困る。
monadの合成は、理論的に自明じゃない問題があるので。
43:デフォルトの名無しさん
02/03/02 13:59
乱数乱数って普通言うけど、実際は乱数系列のことでしょ
だから>>36のやり方は別に特殊じゃないよ。
44:デフォルトの名無しさん
02/03/02 14:10
>>41
末尾再起なら回収できないかな？
45:デフォルトの名無しさん
02/03/02 14:43
つーか、素直にIO monadな>>36使え。
末尾再起じゃなくて乱数リスト回収できない事気にするくらいなら、
リストよりでかいスタックを解放するようにプログラム書き換えろ。
sagesage
46:デフォルトの名無しさん
02/03/05 18:35
たまには age ておこう。
47:言語障害なんです
02/03/08 04:49
Haskell は OOPL 疑惑
URLﾘﾝｸ(www.geocities.co.jp)
>>13はゆーあいさん疑惑
URLﾘﾝｸ(www.geocities.co.jp)
思っているだけで作る気はない疑惑
URLﾘﾝｸ(www.geocities.co.jp)
typo がやたら多いという罠
48:デフォルトの名無しさん
02/03/12 14:32
Haskellのモナドは正直言ってかったるい
49:デフォルトの名無しさん
02/03/13 07:58
age
50:デフォルトの名無しさん
02/03/13 09:04
あーそうだ haskell もやらなきゃ..
51:デフォルトの名無しさん
02/03/19 22:40
質問ですいません。
「lambda lifter」って、どういう処理なんでしょうか？
局所関数(関数内の関数)を展開して外側の関数と一体化する処理らしいですけど
実行速度改善のための最適化処理の一種だと考えてよいのでしょうか？
URLﾘﾝｸ(citeseer.nj.nec.com)
それと関数型言語にある代表的な最適化処理があれば教えてください。
52:デフォルトの名無しさん
02/03/19 22:42
>>51
Cのインラインと違うの？
53:デフォルトの名無しさん
02/03/19 23:03
>>52
実行時までどんな関数が来るのか分からない
らむちゃんなんだから全然違うだろ。
54:無名λ式
02/03/20 00:44
>>51
lambda liftingというのは、
一言で言えば、自由変数を除去する変換の事です。
・funarg問題がなくなる
・環境の扱いが簡単になる
・lazinessの境界がはっきりする
などなどの利点があります。
lifterはその変換器の名前です。
Super combinatorというのありました。(これは変換後のλ式の名前)
Prentice-Hallから処理系実装の本が出ていましたが、
> それと関数型言語にある代表的な最適化処理があれば教えてください。
こういう観点で非常にいい読物だと思います。
# 今やMicrosoft Research(CLI!)のSimon P. Jonesのが一冊、
# もう一冊はHughesじゃなかったかな? 教科書になって答えがWebで配布された奴。
驚きなのはcombinatorが非常に古い概念であるにも関わらず、
λ計算において非常に本質的な役割を担うことです。
55:無名λ式
02/03/20 00:46
>>53
> 実行時までどんな関数が来るのか分からない
> らむちゃんなんだから全然違うだろ。
λ式ちゃんは、Lisp野郎ほど酷くないですけどね。
奴の場合、cons, eval, macroと何でもありなので。
56:デフォルトの名無しさん
02/03/20 01:04
> # 今やMicrosoft Research(CLI!)のSimon P. Jonesのが一冊、
URLﾘﾝｸ(research.microsoft.com)
ここ (の一番上のとこ) から落とせるやつですな。
57:無名λ式
02/03/20 10:30
URLﾘﾝｸ(research.microsoft.com)
これ面白いよね。この作業苦痛じゃないのかな...
58:デフォルトの名無しさん
02/03/20 12:17
>>57
なんだか大変そうですね。これホントに自分でやってるのかな？（藁
59:デフォルトの名無しさん
02/03/21 16:58
仕事でcygwinを強いられるSimon萌え！
60:デフォルトの名無しさん
02/03/21 21:05
論文発表打ちage
61:デフォルトの名無しさん
02/03/26 05:40
>>54
コンビネータ、結合子ですか？
圏論？λ理論の話でしたか？
うーん難しい。
62:デフォルトの名無しさん
02/03/26 23:57
>>61
理論的には難しいとおもうけど、
"Implementing Functional Languages: tutorial"
には実装についてわかりやすく書いてありますです。
63:デフォルトの名無しさん
02/03/27 00:00
>>62
サイモン パイソン ジョーンズさんがM$用に書いたやつだよね？
どのチャプターに書いてあります？
(ファイルは持ってるんだけどねー。軟弱ものなので読んでません。)
64:デフォルトの名無しさん
02/03/27 02:13
> Peyton
ペイトン
65:デフォルトの名無しさん
02/03/27 09:17
>>63
Lambda lifting については ６章
コンビネータ実装のはなしは
"Implementation of Functional Programming Language"
というよく似た名前の本の方でした。これも、どこかのWEBサイトで公開
されてたとおもうですだす。
66:デフォルトの名無しさん
02/03/28 04:41
>>65
"Implementation of Functional Programming Language"
本の方は簡単に見つかったけどなー。
判らない。くそー。
67:Super Combinator
02/03/28 10:27
>>66
何がわからないのか、話してみれば?
68:デフォルトの名無しさん
02/03/28 10:28
Peyton Jonesは前に学会で会ったとき、冬のロンドンを裸足で歩いてた…。
別に変人じゃなくてナイスガイなんだけど。発表は楽しいし。
69:66
02/03/28 22:37
>>67
コンビネータといえばCL式
どんなCL式でもIKSを組み合わせたものまで分解できるらしいけど
どうやって？
あとSの意味が判らない。どう使うんだろう？
I = \ x -> x
K = \ x y -> x
S = \ x y z -> x z ( y z )
でも相手にしないでください。
頭正規形(hnf)って何？といぐらいのレベルですから。
ラムダ理論も知らないんですから。
70:Super Combinator
02/03/29 09:40
>>69
> あとSの意味が判らない。どう使うんだろう？
> S = \ x y z -> x z ( y z )
Distributor.
Combinator式は、グラフとして素直に表すことができるから、
部分グラフは、元のプログラムを分割したものと考えられる。
部分プログラムxと部分プログラムyの両方に引数zを渡し適用するのが役割。
x側では引数zは必要なければ、
(K x' z) (y z)
てな感じになる。(x ≡ K x')
(x z)を(y z)に適用するのは、部分プログラム同士を結合する方法が、
「適用」以外にはないから。Combinator logicやlambda calculusでは。
RAM(Random Access Machine)ではメモリ参照で、データを扱うわけだけど、
Combinator logicやlambda calculusでは、どんどん受け渡していくことになる。
# lambda calculusのβ簡約をメモリ参照で直感的に理解している人も多いと思うが。
71:デフォルトの名無しさん
02/03/29 19:23
>>69
I=SKK
Raymond Smullyan の "To Mock A Mockingbird" という本が楽しめます。
翻訳も出ていたと思う。
72:デフォルトの名無しさん
02/03/29 20:47
>>71
『ものまね鳥をまねる』森北出版 isbn 4-627-01901-7
73:69
02/03/29 22:43
みなさん、親切な解説有難うございます。
「プログラミング意味論」 横内寛文著
「計算論 計算可能性とラムダ理論」 高橋正子著
と読み理解しようと奮闘中なのですが、計算機屋の私にはさっぱりです。
しかし理論はむずかしーな。
一度ものにしてしまうと効果絶大なんですけどね。
もうちょっと、がんばってみます。
>>71
>I=SKK
む。なるほど。
上の本で書かれていましたが、改めてみると こういう意味だったんですね。
Sの機能が、ちょっとわかった気がしました。
>>70
>Distributor.
>
>Combinator式は、グラフとして素直に表すことができるから、
>部分グラフは、元のプログラムを分割したものと考えられる。
>部分プログラムxと部分プログラムyの両方に引数zを渡し適用するのが役割。
中略
>(x z)を(y z)に適用するのは、部分プログラム同士を結合する方法が、
>「適用」以外にはないから。Combinator logicやlambda calculusでは。
なるほど。
Sで式同士を組み合わせる。
もしくはSで式を分解できるということなんでしょうか？
>>71
>『ものまね鳥をまねる』森北出版 isbn 4-627-01901-7
URLﾘﾝｸ(www.morikita.co.jp)
よさそうな本ですね。購入したいと思います。
74:Super Combinator
02/03/29 22:49
>>73
> 両方に引数zを渡し
だから'分配器(distributor)'です。
Sはドイツ語だったかの頭文字だったはず。
K=cancel
75:石敢當
02/04/09 22:39
GHC 5.02.3 がリリースされました。
ただいま amortization の勉強中。
分かったような、分からんような・・・
ということは分かってないんだなぁ。
76:Super Combinator
02/04/10 00:36
>>75
amortizationは、時間のかかる処理を、複数の操作に対してひとまとめにして、
平均の計算量オーダーを下げる手法のこと。
木、ソートされたテーブル、pure functional arrayなどの
再構成、構造調節などで利用される事が多い。
77:デフォルトの名無しさん
02/04/10 20:28
amortizationって何ですか？
どういう物なのか興味あるなー。
教えてSuper Combinatorさん。
78:石敢當
02/04/10 21:57
> amortizationは、時間のかかる処理を、複数の操作に対してひとまとめにして、
> 平均の計算量オーダーを下げる手法のこと。
そのような雰囲気は分かるのですが、「分かったぞ！」という実感が
まだ伴っていません。もう少し勉強します。
.NETというのも名前はよく目にするものの中身はさっぱり分からない
のですが、Hugs98 for .NET というものがリリースされたようです。
URLﾘﾝｸ(galois.com)
79:デフォルトの名無しさん
02/04/11 10:18
Cormen, Leiserson, RivestのIntro. Algorithmsに
amortized analysisの章がありますよ．
80:デフォルトの名無しさん
02/04/11 11:31
たとえば固定長配列に1ずつ要素を追加していくことを考えます。
満杯になったら新しく大きい配列を用意して全部コピーして追加。
このとき、初期サイズ1で1ずつ大きくして行くとN要素追加するの
に合計コピー回数は1+2+3+…+NだからO(N*N)。定数Cずつ大きく
していくとしても、コピー回数がC分の1になるだけだからO(N*N)
は変わらない。ところが2倍ずつに大きくして行くことにすると、
1+2+4+…+NだからO(N)になるのね。しかし「1個追加するときの
最大計算量」はどの方法でも(その1個であふれた場合はどのみち
コピーするんで)変わらない。逆に言えば、最大計算量を考える
変わりにN個の操作全体の計算量を考えてその平均を取ると
1個追加する際の平均的な計算量はO(1)だよね、っていうのが
amortized analysis。
81:デフォルトの名無しさん
02/04/12 21:11
URLﾘﾝｸ(www.cs.columbia.edu)
ここに書いてあることかな？
英語が読めない。
82:デフォルトの名無しさん
02/04/13 19:28
なんか今はnot foundになっちゃうけど、それってChris Okasakiのページだよね。>>81
だったら、そうだと思う。
でもこのスレの人でも、英語は壁になるんだ…。自動翻訳希望？
83:81
02/04/14 01:11
そうです。
他力本願全開。
84:石敢當
02/04/14 23:51
> 逆に言えば、最大計算量を考える
> 変わりにN個の操作全体の計算量を考えてその平均を取ると
> 1個追加する際の平均的な計算量はO(1)だよね、っていうのが
> amortized analysis。
これは良く分かります。ただ、これだけだと amortization などという
言葉を持ち出すまでもなく、単に「平均」ですよね。（違うのかな？）
もし単に平均コストのことを言っているだけだとすると、
banker's method だの physicist's method （>>79の本では
accounting method と potential method）だのの技法を使い、
多くのページを割いて解説するほどのことじゃないように
思うんです。
>>80の例の場合、配列の確保がサイズに関係なくO(1)で行えると
仮定すると、あふれたときに1度に全部コピーするのではなく、
新しい要素が追加されるたびに要素を2個ずつコピーすることに
すれば1個追加する際の「最大の」計算量がO(1)となります。
結局、amortizationの何が良く分からないのかということを
改めて考えてみますと、amortized analysisで得られた平均
計算量が、平均ではなくて最大の計算量となるような実装が
いつも得られるのだろうか、ということであるような気が
してきました。
まだ良く分かっていません。変なことを書いていたらごめんなさい。
85:デフォルトの名無しさん
02/04/15 10:08
>>84
> これは良く分かります。ただ、これだけだと amortization などという
> 言葉を持ち出すまでもなく、単に「平均」ですよね。
「最悪」の場合の1ステップあたりの「平均」ではないでしょうか。
86:デフォルトの名無しさん
02/04/17 14:32
URLﾘﾝｸ(www.teu.ac.jp)
↑
ない・・・
87:デフォルトの名無しさん
02/04/17 17:53
URLﾘﾝｸ(www.brl.ntt.co.jp)
↑
ここも講義録だったような気がするんだけど、つながらない･･･
88:デフォルトの名無しさん
02/04/18 01:13
>>87
URLﾘﾝｸ(www.ipl.t.u-tokyo.ac.jp)
89:デフォルトの名無しさん
02/04/19 00:40
このスレを見て面白そうだと思いHugsを入れてみた関数型の素人です。
最初はやはり名前を入力させてXXXさんこんにちは、だと思い試したのですが
putStr "123" とか getLine とか単体では動くのに、次のように組み合わせるとエラーになります。
Prelude> putStr getLine
ERROR - Type error in application
*** Expression : putStr getLine
*** Term : getLine
*** Type : IO String
*** Does not match : [Char]
一行入力をそのままエコーすることを意図しているつもりなのですが、何故でしょうか？
90:デフォルトの名無しさん
02/04/19 00:49
>>89
getLine の型は IO String だが putStr は String 型を貰うので
型エラーになります。(IO が付いているかいないかの違いだけど)
getLine >>= putStr とすれば意図してるように動きます。
「>>= って何?」などと思うのでしょうが、説明するのは大変なので
URLﾘﾝｸ(www.sampou.org) などを読んでください。
91:デフォルトの名無しさん
02/04/22 03:35
色々試しているのですが、次のコードで
ERROR "ファイル名":3 - Type error in function binding
*** Term : sel
*** Type : a -> IO a
*** Does not match : a -> a
*** Because : unification would give infinite type
というのが消えてくれません。
module Main (main) where
sel x = do putStr "(y/n) ? "; c <- getChar
return (
case c of
'y' -> sel (x + 1)
'n' -> x
_ -> sel x)
main = do putStr (show (sel 0))
selの型は Int -> IO Intのつもりなのですが、型を明示しても駄目です。
いじっていると、IO (IO Int)みたいな型がエラー報告で出るときもあります。
このコードはどうすれば通るのでしょうか？
それと、IOを重ねる意味は無いように思えるのですが、IO (IO Int) というのはどういう状態なのでしょうか？
質問ばかりで申し訳ありません。
92:デフォルトの名無しさん
02/04/22 05:02
>>91
case c of
{'y' -> sel (x + 1)
;'n' -> x
;_ -> sel x}
この式の型は何でしょう?
93:91
02/04/22 06:35
IO Int …のつもり…です。
それをreturnで返していますから、selの返値もIO Intで、
selの型は Int -> IO Int …
エラーになるということは、間違った理解なのでしょうけれど…
94:91
02/04/22 06:48
sel (x + 1) と sel x が IO Intなのに、'n' の時の x がただの Int だからいけない…？
とすれば、ただの Int を IO Int に揃える必要があるということですか？
95:デフォルトの名無しさん
02/04/22 08:29
> IO Int …のつもり…です。
> それをreturnで返していますから、selの返値もIO Intで、
return の型は Monad m => a -> m a です。
>>91 のケースだと m は IO。
> とすれば、ただの Int を IO Int に揃える必要があるということですか？
うん。で、そういう場合に return を使う。
sel x = do
putStr "(y/n) ? "
c <- getChar
case c of
'y' -> sel (x + 1)
'n' -> return x
_ -> sel x
96:91
02/04/22 12:00
以下のコードで動作しました。ありがとうございます。
module Main (main) where
sel x = do putStr "(y/n) ? "; c <- getChar
case c of
'y' -> sel (x + 1)
'n' -> return x
_ -> sel x
main = sel 0 >>= putStr . show
(r <- case …にしてその後にputStr "/"とreturn rを続けて書いたら、'n'を打った時も表示されたので)
この場合returnはcaseから抜けているだけですよね？
doを使っている場合も、returnを書かなくても、最後の式が返値になるのですね。
97:デフォルトの名無しさん
02/05/01 14:16
return は関数であって、命令ではない。
98:91
02/05/01 23:13
IO型にするだけで、脱出はしないということですか？
99:デフォルトの名無しさん
02/05/02 00:29
返り値という表現に違和感を感じので。
深い意味はないです。return は、返り値を
もって呼び出し元へ帰る命令ではなく、単に
a 型の値を m a 型の値に写像する関数だと
いってみただけです。
100:デフォルトの名無しさん
02/05/02 00:51
試してみたら、returnの後に文を続けた場合、途中returnに渡した値は無視されて、最後の値が採用されているようです。
成程…Haskellのreturnはreturnしないのですね。
101:デフォルトの名無しさん
02/05/02 02:43
のぶさんのHaskell-MLに登録してみましょう
102:デフォルトの名無しさん
02/05/03 01:36
return とか戻り値をCチックに理解しようとしてる時点でもうダメでしょうって
感じかも。関数型言語の発想が根本からわかってない。
IOモナドって一見して普通の手続き型にも見えますからねえ・・
関数型が全くわからない人は、HaskellのまえにMLを経由した方が良い
というのは正しいのかも。
103:デフォルトの名無しさん
02/05/03 02:08
モナドは手続き型プログラミングの車輪の再発明だって、どっかに書いてあったね
104:デフォルトの名無しさん
02/05/03 10:55
俺、いつもはMLしか使ってなくてHaskellは詳しくないんだけど、
Haskell（特にGHC）って例外処理とか、入出力じゃない副作用も
どんどんIOモナドに入ってるじゃん。
モナドの合成が理論的に難しいかららしいけど、そのうちに現実的な
プログラムだと何でも一つのモナドの中で書くことになって、ほとんど
MLみたくなったりはしないの？（手続き型言語とまではいわないけど、
「どこでも副作用」って感じで）
105:デフォルトの名無しさん
02/05/03 15:56
>>104
モナドは副作用じゃないのでOK OK。
逆に言うとMLの利点がなくなってくる。
106:デフォルトの名無しさん
02/05/03 16:10
ML、Haskellってお互い仲悪いんですか？
107:デフォルトの名無しさん
02/05/03 16:11
ゆーざーがね
108:デフォルトの名無しさん
02/05/03 19:18
仲悪いなんて聞いたこともないぞ。
なかはわるくないです。
MLとHaskelは
ちょっと雰囲気は違うような気はしますけどね。
でもまあそれは両方使ってみれば解ることで。
109:デフォルトの名無しさん
02/05/03 20:43
>106
Haskell-MLというのが有るらしいですYO!
110:デフォルトの名無しさん
02/05/04 23:53
Haskellは、純粋関数型言語だから
MLの不純さが嫌なのかも？
どうなの？＞ALL
111:デフォルトの名無しさん
02/05/05 00:01
確かにHaskellの処理系の効率が良くなればMLは不要になる。
112:デフォルトの名無しさん
02/05/05 01:34
MLとHaskellは設計思想自体が全然違う気がします。
ML(Ocaml)は現実的にある程度の副作用を認めている代わりに
使っているとコンパクトな感じがします。
副作用も使えると言うだけで、副作用のある構文を使わずに書く事は
全然出来ますし、遅延評価もコードによって簡単に実現できます。
未だ出来あがっていないものの、ML2000の仕様書では言語自体に
遅延評価など新しい機能がかなり含まれています。
Haskellは純粋を歌ってはいますが、
結局の所モナドというものに問題を押しこんだだけのようにも思え
美しくないようにも思われます。
仕様もわりとごちゃごちゃしている気がします。
言語の性質上ML並みに速くなる事も難しいのではないかと思います。
113:デフォルトの名無しさん
02/05/05 03:11
MLで副作用使わずにどうやってI/Oするの？
114:104
02/05/05 14:26
あーなんか煽りっぽくなっちゃってスマソ。俺はHaskellも大好きだよ。(笑)
WadlerとかPeyton Jonesとか面白い人が多いし。（そういう問題か？）
>>113
一応、MLでもHaskellと同様のmonadicなプログラミングスタイルは可能。
MLだと文法的に面倒で、Haskellを使ったほうが楽だから誰もやらないけど…
115:デフォルトの名無しさん
02/05/05 14:57
副作用のある関数型言語は
中途半端な感じが払拭できないということでいいのか？
116:デフォルトの名無しさん
02/05/05 15:21
Ｒｕｂｙ ＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞ Ｈａｓｋｅｌｌ
117:デフォルトの名無しさん
02/05/05 17:42
モナドがあまりに手続き型っぽすぎるので、
Haskllを関数型を知らない人に触らせると、
モナドでC言語かよ！ということをやろうとする。
しかして正しく正面玄関から入ろうとすると、難解過ぎる。
MLの方がそういう意味でも適度に関数型な気がする。
純粋関数型を言うならば、遅延ストリームでゴリゴリ書くのが基本に
なってるような言語であるべきかなと思ってみたりする。
118:デフォルトの名無しさん
02/05/05 18:12
いいんじゃねえの？
多目的言語なんだから。
119:Super Combinator
02/05/05 23:13
>>104
> Haskell（特にGHC）って例外処理とか、入出力じゃない副作用も
> どんどんIOモナドに入ってるじゃん。
最近Haskellの動向は探ってないんだけどこれ本当?
IOErrorがIOモナドmoduleにあって、
HaskellがIOError以外ろくに例外をsupportしないだけなんだと思ってたよ。
120:デフォルトの名無しさん
02/05/06 02:01
勉強中だからよく分かんないけど、state モナドの事？
121:デフォルトの名無しさん
02/05/06 03:57
MLと（Haskellとも）離れますが、
モナドを使うと、手続き型言語を
関数的に解釈することができますか？
122:デフォルトの名無しさん
02/05/06 10:53
>>121
「関数的に解釈」の意味がよくわからない。
Haskellでインタープリタが書けるか？
という意味じゃないよね。
123:デフォルトの名無しさん
02/05/06 11:38
URLﾘﾝｸ(sato-www.cs.titech.ac.jp)
124:デフォルトの名無しさん
02/05/06 12:35
>>122
モナドを使うと、どうみても副作用な操作でもfunctionalな
操作と解釈できるわけですが、それと同じように手続き型言
語のプログラムに純関数的な意味を与えることができますか？
という意味です。
125:デフォルトの名無しさん
02/05/07 00:50
>>124
Idealized Algolとかいうのがなかったっけ。
126:デフォルトの名無しさん
02/05/07 01:16
グローバル変数が見当たらないんですが・・・
127:デフォルトの名無しさん
02/05/07 18:47
>>121 >>124
できません。
強引に無理矢理こじつけることならできるかもしれないけど意味無し。
128:デフォルトの名無しさん
02/05/07 19:13
>>124
モナドを使えば、代入、逐次的実行、手続き型ライクなI/O、例外などを
純関数型の枠組みで扱える。gotoくらいならもともとモナドに関係なく
等価な純関数型言語に変換することができる。
Cは無謀だがMINIMAL BASICくらいなら、純関数型とみなすことは可能だろ
う。
129:Super Combinator
02/05/07 20:21
>>124
Denotational semanticsじゃ駄目?
domainの性質がやっかいになるから、いいことないけど。
そもそも「簡単に」できるくらいなら、関数型言語の存在意義が…
130:デフォルトの名無しさん
02/05/07 22:49
Haskellで書いたプログラムに、関数的意味を与えうるなら、
手続き型の言語のインタープリタを Haskell で書いたら、
その言語の意味を与えたことになる？
ならない？
131:デフォルトの名無しさん
02/05/07 23:11
>>130
なるんじゃない？
きちんとやれば操作的意味論だろ。
132:デフォルトの名無しさん
02/05/08 00:35
結局、Haskellは非正格言語なのが問題じゃない？
実際に各項が何時評価されるか？どういう順番で評価されるか？
ということが予測しづらい(できない)からねー。
その点、正格言語や手続き型言語は評価の順序が一目瞭然だからねー。
Prologにカットオペレータがあるように、Haskellも競争書き込みで
評価の順序を、ある程度コントロールできる様にしたらよいのかな？
133:デフォルトの名無しさん
02/05/08 00:39
>>132
？？ 問題なのは結果であって、
順番なんてどうでも良いだろう。
順番じたいが望む結果に含まれる
(例えば入出力とかGUIとか)なら、
そこだけモナド使えば良いしさ。
134:デフォルトの名無しさん
02/05/08 07:47
>>133
133も書いていますがコンピュータの入出力は
ストリームを基本としているものが多いですよね。
しかし、ストリームにとって並び方も結果の内ではないでしょうか？
プログラムは外部と入出力して、なんぼのものだと私は思っています。
ゆえにストリームのようなモノに対して実行順序がコントロールできることは
プログラミング言語にとって重要であると思います。
そうじゃなきゃPrologもカットオペレータなんて付けなかった
と思います。
あと私のような消防には、実行される順序が予測できないと
デバッグしづらいです。(もしかして、こっちが本題か？)
135:デフォルトの名無しさん
02/05/08 08:13
>>134
ほんとに消防だな。Haskellだって
ストリームの順番が狂うわけはないだろう。
ストリームは「いくらでも長くなりうる列」
というデータだ。関数型の基本はデータの値を
求めることなんだから、モナドなんか用いなくたって
ちゃんと求まる。
136:チュウボウ
02/05/08 09:56
なんで副作用って困るの？ よく聞くはなしでは
副作用あり＝＞参照透過性がない＝＞数理論理的でない
数学って、まったく副作用のない構成になっているの？
137:デフォルトの名無しさん
02/05/08 10:03
> 数学って、まったく副作用のない構成になっているの？
副作用がなんなのかわかってる?
138:デフォルトの名無しさん
02/05/08 10:04
副作用が無ければ、デバッグ簡単
139:チュウボウ
02/05/08 11:10
＞副作用がなんなのかわかってる?
オレの理解
状態という一種の記憶域のようなものがあってその値が
変わること。
数学ではオートマトンとか除けば、状態のような概念は
知らない。
140:デフォルトの名無しさん
02/05/08 11:55
>>136
評価順序に依存してるから
141:チュウボウ
02/05/08 12:32
順序なしで考えるより、順序を指定されて考える方が楽じゃない？
142:デフォルトの名無しさん
02/05/08 12:34
>>141
そう思えるのはモノが単純な場合だけ
143:チュウボウ
02/05/08 12:49
状態（もの）と動作（働き）があった方が考えやすい気もする。
主語＋述語が人間の頭にあってるような気がする。
（状態があるならば副作用があると思ってる）
ペトリネットなんかかじってみてると、そんな気がしてきた。
URLﾘﾝｸ(www.aichi-pu.ac.jp)
144:デフォルトの名無しさん
02/05/08 15:04
副作用って､関数が値を返す以外の何かの作用を起してしまうことでしょ。
「なぜ関数プログラミングは重要か」に副作用が無い事のよさが力説されてた。
実感湧かなかったが。
145:デフォルトの名無しさん
02/05/08 18:09
>>143
日本語は主語なんかなくても良い言語だよ。英語カブレめ（ｗ
実際この書き込み(145かな？)のなかに主語のある文は一つもないが、
意味はちゃんと通じるだろ？
146:５月病
02/05/08 18:24
オレも人並みにSOE本ながめたりして、haskellの理解に
努めたわけよ。モナドの意味もつかもうとしてがんばった
んだけど、あるときふと、こんなに無理して副作用さけよう
という努力はなんなんだろうと感傷的になるわけよ。
147:デフォルトの名無しさん
02/05/08 18:26
Cでグローバル変数はやめよう、と似たようなもんじゃないの？
148:チュウボウ
02/05/08 18:35
>>145
>日本語は主語なんかなくても良い言語だよ
おお、そうであった。日本語は述語だけでつうじるのだ。
日本語こそ真の関数型言語であった。なんてわけないか。
149:デフォルトの名無しさん
02/05/08 18:47
>>146-147
つーか…
プログラムって要するに「入力と出力の関係を記述する」
ってだけで良いはずなのに、状態を持ち出すとよけい面倒に
なることも多いでしょ。
150:５月病
02/05/08 19:00
モナドを使い、高階関数を使い、入力と出力の関係だけで
ストイックに記述する。そうすると見えるすばらしい世界
を教えてください。
151:デフォルトの名無しさん
02/05/08 19:02
>>149
> 入力と出力の関係を記述する
時系列的な入力と出力の表現には内部状態があった方が記述が楽。
あと、入力の長さが不定なときも。
だから入力に対して反応するタイプのプログラムでは状態記述がないと不便。
>>145
主語がなくていいのは主語が明らか（容易に推測可能）な時だけだよ。
フォーマルな文章では日本語だって主語が必要。ここはかなりインフォーマルだからね。
ちなみに英語でも命令形などでは明らかな主語が省略されている。
152:デフォルトの名無しさん
02/05/08 19:14
>>151
なんで、ストリームやモナドなどではプログラムの動作が完了した時点では
入力が決定して、出力も決定する筈ということに注目して、
実行時に対応関係を組み立てるわけだ。
153:デフォルトの名無しさん
02/05/08 19:19
無限列から無限列への対応関係を陽に書くことはできないが、
無限列の有限部分列から有限部分列への対応関係なら書ける。
そしてその対応関係が再帰的に定義できているなら、
限りなく計算を続けられる。
ただ、有限部分列の入力から続きを計算する際に何度も同じ計算が
繰り返される場合がある。そういう場合は内部状態としてメモしておけば
計算効率が改善される。
154:デフォルトの名無しさん
02/05/08 19:21
>>153
現実的にはどんなケースがありますか？
155:デフォルトの名無しさん
02/05/08 19:39
無限ストリームはメッソドの呼び出しを遅延評価するように
しておけばJavaなんかでも再帰的に記述できるよ。
156:デフォルトの名無しさん
02/05/08 19:49
>>154
httpプロクシサーバとか。
リクエストは無限列とみなせる。
以前にあったリクエストなら、内部状態としてキャッシュしとけば
速くなる。この場合でも副作用は別に必須じゃないけどね。
157:デフォルトの名無しさん
02/05/08 20:42
多分もっと技術レベルが高かったら萌えるんだろうなぁ。
今はC、C++、C#、Javaで手一杯だよ･･･
158:デフォルトの名無しさん
02/05/08 20:47
>>156
副作用が絡むのは配列やオブジェクトの部分更新とかが絡むときが典型。
もちろん更新する値以外も全部複製してしまえば副作用は消せるが、
効率は･･････（ガクガクブルブル）
----
>>155
遅延評価は評価の仕方を「メモ」って行くわけだが、
結構、後でそのメモ・ツリーを辿るのに時間がかかったりする。
159:153
02/05/08 20:50
>>157
てひひひー。C#は全然把握してないッスー。
160:デフォルトの名無しさん
02/05/08 21:19
C#っていってももともとは.net frameworkのために作られた言語だからね。
シンタックスだけはJavaに似てるけど。逆に言語から仮想環境を想定するとしたら
どんなものになるんだろね。Hakell、というより関数型言語全般のために
作られたようなもの。あるとしたらどんなもんでしょ？
161:153
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
URLﾘﾝｸ(www.yfcbookshelf.com)
ここの下の所に「Programming Languages：Concepts and Constructs 2/E」
の「日本語訳版を期待」という文字が見えるんですが、今翻訳中なのでしょうか？
もしそうなら超期待！！
>>158
どうも効率面を問題にされているようですが、
私自身たいして関数型言語の経験はありませんが、
仕事の関係上感じている事です。
コンパイラ作ってると、この副作用がないというのが
結構オプティマイズに有効だったりするので、
結構これからの言語の核にすえるのは悪くないと最近思ってます。
計算の依存関係が明白でないと最近のスーパスカラーみたいに
命令スケジュールが必要だと面倒です。
全体的とはいわなくても部分的には関数型言語が高速化への寄与大きいと考えています。
計算機の並列度が上がってくると、少し考え方を変えてみるのも悪くはないと思っています。
ちなみにモナドはあんまり良くわかっていません。(TT)
だれか教えてくれー
165:デフォルトの名無しさん
02/05/09 02:25
>>163
昔のバージョンではストリームでI/OやってたんだよHaskellは。
I/Oエラーが扱いにくくってなあ…
モナドの方が楽だよ。
166:134
02/05/09 02:43
>>165
本当ですか？
何時の頃のモノなんでしょう？
処理系の名前とバージョンを教えてもらえませんか？
>I/Oエラーが扱いにくくってなあ…
>モナドの方が楽だよ。
たしかに、そうですね。
うーん、モナドから逃げてるのかなー？俺は
167:デフォルトの名無しさん
02/05/09 02:45
モナドを意味づける（動作を定義する）のにストリーム使えるしね。
168:デフォルトの名無しさん
02/05/09 02:46
副作用推進派のかた、もっと高階関数を活用してみては
どうでしょう？
関数も各引数を繋ぐための糊だと考えると
副作用が無いほうが嬉しいのでは？
169:158
02/05/09 02:50
>>164
効率は計算機上での実行の際のことです。
･･････というか効率を考えた動作をガチガチにプログラマが記述する際に
場合によってはあるほうが便利ということですね。
一方、最適化のためのプログラムの解析においては
一般に副作用がないほうがやりやすいのは確かだと思います。
だからこそ代入を消してSSAなんて形式に落としたりもするんでしょうし。
170:158
02/05/09 02:51
>>168
行列を配列並みの高効率で実装できる方法があるなら是非そう致したいと。
171:158
02/05/09 02:54
引数で指されるオブジェクトがコピーのコストが気にならないほど小さいうちは
それほど悩ましくないんですが･･････。
172:デフォルトの名無しさん
02/05/09 02:57
>>166
Haskell 1.1まではそういう仕様だった。全ての準拠処理系がそうなって
たはず。stream I/Oとcontinuation-based I/Oの両方が使えた。
URLﾘﾝｸ(www.haskell.org)
Monadic I/Oがあんまり便利なんで今は全部そっち。
173:デフォルトの名無しさん
02/05/09 03:04
>>170
配列使えばいいじゃん。副作用なしの。
SISALっていう関数型言語がそうやって、スーパーコンでも
Fortranに負けない性能出してたよ。
Fortran厨は他の言語が書けなかったので普及しなかったが。
174:デフォルトの名無しさん
02/05/09 08:17
なんかこのスレ人増えたな。
175:158
02/05/09 09:51
>>173
URLﾘﾝｸ(www.sys.uea.ac.uk)
を読んで見てるけど、やたら配列に特化した言語だなぁ。APLを思い出したよ。
サワリの部分を読んでの感想としては、
配列に特化した構文が多すぎるし、拡張性にも疑問が残る。
この言語を実装する上で研究された内容（解析や最適化の技術）は有益そうだが、
それをつかって書けと言われると結構苦痛かも。
CやFortranのソースに混ぜられると言われてもねぇ。
176:158
02/05/09 10:01
でついでに、「スーパーコンでも」というよりは
むしろ「スーパーコンのために」開発されたようだ。
スパコン以外にも移植はされているようだが、
どうもメインの技術ははデータ並列っぽい気配が。
もっと詳しく読んでみないと判らない部分もあるが、
そうなると今時のマシンの記憶階層と
マッチするかどうかは些か怪しげ。
177:Super Combinator
02/05/09 11:43
MonadとInfinite listの関係について知りたければ、
"Comprehending Monads", Philip Wadler読め。面白い。
178:デフォルトの名無しさん
02/05/09 13:23
>>176
文句の多いヤツだな。
179:デフォルトの名無しさん
02/05/09 15:07
>>158 は >>173 を「Sisal 使えば?」と読んでそうな感じだが
>>173 は「Haskell の副作用無しの配列使え」と言ってるのだろう。たぶん。
180:デフォルトの名無しさん
02/05/09 20:50
>>179
どんな実装してるんでソ。＞「Haskell の副作用無しの配列使え」
私が読んだ何件かの「副作用なし配列」の論文は皆頑張っていたけどヤパ－リ
オーバーヘッドが大きくて生の配列ほどには早くない･･････。
181:デフォルトの名無しさん
02/05/09 21:06
>>132
>Prologにカットオペレータ
カットオペレータ思い出した。これでProlog嫌いになった。
ところで、Prologも関数型かな？ 副作用ないみたいだし。
真偽の２値のみを返すと考えられるかな。もっとも偽の値が
返ればストップするので真のみ返るが。
182:デフォルトの名無しさん
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:デフォルトの名無しさん
02/05/10 03:55
Mondrianって言語がHaskellをコンパクトにして
OO対応にしたような言語で、.NETにも対応してるらしい
んだけど、この言語ってどうですか？
URLﾘﾝｸ(www.mondrian-script.org)
186:デフォルトの名無しさん
02/05/10 03:57
>>184
ていうか、副作用が無いってのはようするに
思わぬバグが混入しないようにする効果があるわけだから、
デバッグ以前にバグが混入しにくいのでは？
187:デフォルトの名無しさん
02/05/10 04:05
代わりに呼び出し関係が入り組んでくるからねぇ。>>186
やっぱ銀の弾丸はないもんだよねぇ。
188:デフォルトの名無しさん
02/05/12 02:28
>>186
でもバグが無くなる訳ではないでしょ？
仕様のバグという根絶不可能なバグがあるんだから。
やっぱデバッガ必要でしょ。
189:デフォルトの名無しさん
02/05/12 10:10
>>188
既存のデバッガ的な考えは合わないよね。
190:デフォルトの名無しさん
02/05/12 19:07
>>184
副作用がないので
Unit Test あたりが向いてるかも。
191:デフォルトの名無しさん
02/05/13 22:37
URLﾘﾝｸ(www.haskell.org)
のあたりだろうか。
192:デフォルトの名無しさん
02/05/13 22:39
>>188
仕様のバグとデバッガが関係あるんですか？
193:デフォルトの名無しさん
02/05/13 22:47
副作用が無いんだから、
コードの打ち間違いと理論にだけ気をつければ
やっていけます。
194:Super Combinator
02/05/13 22:57
>>192
帰納推論系の人たちで、
間違った具体例の指摘から仕様を直したり、
なんて事が流行ったよね?
そのengineのUI programはdebuggerと呼ばれることが多かった。
195:デフォルトの名無しさん
02/05/13 22:59
なんじゃそら
屁理屈か
196:デフォルトの名無しさん
02/05/14 16:02
つまり、従来のデバッガの役割は
非常に少なくなると言うことでいいのか？
197:デフォルトの名無しさん
02/05/15 00:14
デバッガの使い道ってバグを取るためだけの物かなー？
198:え？
02/05/15 00:35
デバッガをバグ取りに使わないの？
199:デフォルトの名無しさん
02/05/15 01:06
>>198
プログラミング言語の前に日本語を勉強尻。
200:え？
02/05/15 01:16
>>199
君こそ根。
201:デフォルトの名無しさん
02/05/15 01:24
Stream IOを勉強した頃は、同期関係の bugがあったら取り難そうだなあ、
とおもた。
Monadになったら改善できるのかしらん?
202:デフォルトの名無しさん
02/05/15 01:28
>>198 はすさまじいアフォ
203:デフォルトの名無しさん
02/05/15 01:28
>>201
並列処理の話？
204:え？
02/05/15 01:29
>>199 は、すさまじいエロ
205:デフォルトの名無しさん
02/05/15 01:38
＞デバッガの使い道ってバグを取るためだけの物かなー？
他に使い道は？
206:デフォルトの名無しさん
02/05/15 02:30
>>204 ウザイ
「バグ取りの他に使う」と「バグ取りに使わない」の
区別もつかない糞は小１からやりなおせヴォケ
207:デフォルトの名無しさん
02/05/15 12:22
>>206
その前にお前は>>205の質問に答えろよ。
208:デフォルトの名無しさん
02/05/15 13:45
静的なプログラム検証ツールはデバッガの範疇に入るの？
こういうものが作りやすいのが関数型言語の特徴って言われてるから
そっちに期待しちゃうな。あくまで素人の考えだけど。
209:Ｃ厨房
02/05/15 14:01
lintはデバッガって言うか？
210:デフォルトの名無しさん
02/05/15 14:24
なんでHaskellスレは厨房がワラワラと寄ってくるんだろ。
無視できない何かがあるんですかねー。
211:206ではないが
02/05/15 14:28
関数型言語にあてはまるかどうかは知らんが、
他人が書いたプログラム(またはライブラリ)を理解するために
デバッガを使って動作を見るのは、けっこうよく使う手だと思う。
>>208
普通は静的な検証ツールはデバッガには含めないと思うけど、
参照透明性の高い関数型言語では、静的/動的の境界はどう定義するんだろう？
例えば多相型の型エラーをデバッグするのって、静的なのか動的なのか…
212:デフォルトの名無しさん
02/05/15 14:42
言語理論に比べて処理系のセオリーが
弱い気がするのは気のせいでしょうか？>>211
213:デフォルトの名無しさん
02/05/15 15:27
>>210
お前のような厨房がな。
214:201
02/05/16 00:31
>>203 並列って言うか、そもそも関数型言語は逐次処理でもないじゃん。
木の好き勝手なところを簡約していくっていうか。
そでで再帰的に定義された無限リストの簡約とかまちがうとこわいな。と。
P.Wadlerの入門書にもそれがらみの話あったよねえ?
215:デフォルトの名無しさん
02/05/16 01:21
関数プログラミングでは、動作手順を記述するわけではないので、命令プログラミングの
動作をステップ実行する従来のデバッグ手法のイメージとはあいいれないかも。
でも、計算順序を無理矢理いれこむ、モナドIO使いまくりのプログラミングなら
命令プログラミングとおんなじだから、print デバッグができるよ。
216:デフォルトの名無しさん
02/05/16 01:39
Windowの表示とかやる場合はモナド使うんですか？
関数型でイベント駆動処理を書くのって、
ちょっと想像できないんですが。
217:デフォルトの名無しさん
02/05/16 13:57
Fudgetあげ
ようとしたけど古いから sage
218:デフォルトの名無しさん
02/05/16 14:49
>>216
GTK+HS のサンプルコードとかみてみれば？
219:デフォルトの名無しさん
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:デフォルトの名無しさん
02/05/18 05:44
ウリです。
226:デフォルトの名無しさん
02/05/18 05:45
デバッガっでようするにアナライザだろ。
デバッガがバグを指摘するわけじゃなし。
227:デフォルトの名無しさん
02/05/18 13:13
>>226
書くのが遅い
228:デフォルトの名無しさん
02/05/19 20:37
>>221
遅延評価だと、どのprintが先に実行されるかわかんなくねえ？
そんなんでデバッグできるのか？
229:デフォルトの名無しさん
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「関数プログラミング」
URLﾘﾝｸ(www.amazon.co.jp)
萩谷昌己「関数プログラミング」
URLﾘﾝｸ(www.amazon.co.jp)
あたりで。
233:デフォルトの名無しさん
02/05/26 18:09
まさみさまがそんな本書いているとはしらなんだ..
竹内先生の Lisp本もじつは読んでないんだよなあ。
234:デフォルトの名無しさん
02/05/26 20:36
日本語で書かれたHaskell本はいつ頃出ますか？
SMLだって出てるのに……。
235:デフォルトの名無しさん
02/05/26 22:00
>>234
日本のHaskellユーザの数が、初回印刷部数(200)を越えたら。
236:デフォルトの名無しさん
02/05/26 22:42
ユーザの数はどうやって数えるんですか？
237:デフォルトの名無しさん
02/05/26 23:11
うちの研究室だけで10人はいるんだから簡単に超えそうなもんだけど(藁
238:デフォルトの名無しさん
02/05/26 23:14
>>237
そこが特別なんじゃないの？
239:デフォルトの名無しさん
02/05/26 23:31
じゃ、漏れが布教用に3冊買ってやるから、早く出してくれよ。
訳本でいいからさ。
240:デフォルトの名無しさん
02/05/26 23:46
つーかさ、200位だったら、
いろんな図書館に要望しまくれば、
なんとかなるんじゃないの？
241:デフォルトの名無しさん
02/05/27 00:06
200じゃだめみたい。
URLﾘﾝｸ(www.onweb.to)
242:デフォルトの名無しさん
02/05/27 11:55
>>237
ここのところ素人も増えてるぞ＞オレオレ
243:デフォルトの名無しさん
02/05/28 02:43
有明で売れよ! ってことですか?
244:デフォルトの名無しさん
02/05/28 10:52
>>243
東京ビッグサイトの巨大同人誌即売会サークル抽選当選しますた。
でもジャンルはプログラミング言語とはホド遠いけど(w。
245:デフォルトの名無しさん
02/05/28 22:01
>>244
適当でいいからHaskell本もきぼんぬ
買いに行くから(藁
246:244
02/05/29 14:49
ウチはなんと女装本だぞ。それでも買いに来られるか？（ｗ
って、実際問題としてHaskell本を作る余力はなし。
247:デフォルトの名無しさん
02/06/04 16:02
Haskell本かどうかは分からんが、
R. Birdの「関数プログラミング」第２版を翻訳して出版して欲しい。
流れで近代科学社に。
248:デフォルトの名無しさん
02/06/04 19:43
今売ってる「関数プログラミング」も、
みなしHaskell本では。
249:デフォルトの名無しさん
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:デフォルトの名無しさん
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:デフォルトの名無しさん
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
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:デフォルトの名無しさん
02/06/07 13:20
ネタスレ化か？
261:デフォルトの名無しさん
02/06/07 22:26
女装した場合には、その人の参照の透明性はどう確保されるのでしょうか？
262:デフォルトの名無しさん
02/06/07 22:34
アブノーマルな野郎は消えろ。
263:デフォルトの名無しさん
02/06/12 09:48
>>216
FranTk
264:デフォルトの名無しさん
02/06/13 16:21
HTk
265:デフォルトの名無しさん
02/06/13 21:34
>>261
女装は代入ではありません。ラップするだけです。
本人への参照はそのままにしてください。
女装人格←女装関連の知り合い
↓
本人人格←普通の知り合い
私個人は女装人格をそのまま丸投げの委譲によって実装しているので、
実質どっちを見てても服装と化粧以外はさほどかわりません。
>>262
頑健なソフトウェアを構築するには
例外の存在をなかったことにして無視してはいけません。
266:244
02/06/13 21:37
>>265もね。
267:デフォルトの名無しさん
02/06/13 23:55
下らんこと書くな。
つまらんし。
268:ち ◆A2MadQ16
02/06/14 04:28
つまらんと不満をいうよりも進んでネタを振りましょう。>>267
269:デフォルトの名無しさん
02/06/23 15:09
おい>>1よ 聞いてくれ。
昨日、母の葬式に出たんです。享年54歳。
そしたらなんか自分、涙が一滴もこぼれないんです。
で、よく見たら会ったこともないような親戚のおばさんですら泣いているんです。
もうね、アホかと。馬鹿かと。
俺な、親の死を目の前にして放心してんじゃねーよ、ボケが。
目の前に人が死んでるんだよ、母親が。
なんか親子連れとかもいるし。一家４人で葬式か。ほんとありがとう。
パパは息子さんに挨拶してくるから車で待ってなさい、とか言ってるの。いい親父だな。
俺な、親が死んでんだからもっと泣けと。
葬式ってのはな、もっと殺伐としてるべきなんだよ。
死に化粧をみた瞬間いつ涙があふれてきてもおかしくない、
泣くか叫ぶか、そんな雰囲気が普通なんじゃねーか。オレ、なんなんだよ。
で、やっと葬式が終わったかと思ったら、なんか次々と母のことが思い出されるんです。
そこでまたぶち切れですよ。
あのな、今さら思い出したところで意味ねーんだよ。ボケが。
得意げな顔して何が、今度の休みには帰るよ、だ。
俺は本当に休みに帰るつもりだったのかと問いたい。問い詰めたい。小１時間問い詰めたい。
俺、適当に親との距離をとりたかっただけちゃうんかと。
親不孝者の俺から言わせてもらえば今、若者の間での最新流行はやっぱり、反抗期、これだね。
親ってのはいつまでも生きているもんだと思っている。これがガキの考え方。
親の期待をかなえたつもりで一人暮らし。そん代わりコミュニケーション少なくなる。これ。
で、「少しだけ仕送りいれといたから」 「ああ、無理すんなよ」。これ最期の会話。
今になって後悔ばかりが思い出される、諸刃の剣。
まあお前ら若いもんは、ほんの少しでもいいから親孝行しなさいってこった。
270:デフォルトの名無しさん
02/06/23 21:05
>>256 それは激しく同意。
つうか、がっこで関数言語やってた奴が、
仕事でオブジェクト指向の世界に戻されると、
「このオブジェクト指向言語の型システムは...」とか、
「RDBの動的型が云々...」って事を無意識に考えてしまって、結構ハマるんだよね。
そーゆー意味で、関数言語関係者を招聘したMS Researchの今後に期待
271:デフォルトの名無しさん
02/06/23 23:26
>>270
すまん、>>256でいいのか？
272:デフォルトの名無しさん
02/06/24 01:02
>>270
というわけでこのスレでは Simon P.J. 先生を「サイモン博士」と
呼ぶことを漏れは提案したいっすけど駄目っすか？
273:デフォルトの名無しさん
02/06/26 00:42
Haskellは東大工学部の一部でデフォルトの授業用言語になってて、
そのせいで全国の工学部（の一部）の授業に拡散・伝染してるから、
1000部ぐらいすぐに出ると思ってたんだが、どうよ？
女装じゃ無理かもしれんが…（それとも女装のほうががいけるか！？）
274:デフォルトの名無しさん
02/06/26 07:04
女装って何のこと？
275:デフォルトの名無しさん
02/06/26 09:19
「 Haskell を 1.25 倍使うコピー本」でどうだ。
売り子が女装でなくてじょせーだと嬉しい、ってオイ＞漏れ
276:K
02/06/26 20:00
>>273
うちのことだな＞東大工学部の一部
講義で教えてもらうまで名前も知らなかった。
日本語の解説書さえあれば使いたい言語なのだが＞Haskell
277:デフォルトの名無しさん
02/06/26 20:52
>>276
みんなそんなもんか。
私は大堀先生に感化されてＭＬ使ってる。
278:デフォルトの名無しさん
02/06/27 00:01
>>275
女婿だと嬉しいの？
279:!275
02/06/27 00:48
うん、嬉しい。
出来ればレイヤーさんきぼ。
280:デフォルトの名無しさん
02/06/27 22:54
最近のCPUは、条件分岐がたくさんあると頻繁に
分岐予測ミスが発生してストールであぼーんな訳ですが、
関数型言語って手続き型に比べてその辺どうなの？
ガードの存在って影響ある？
CMOVccとかSETccとか使ってくれるのかな。
281:275
02/06/29 11:01
>>280
予測が当たりまくるタイプの条件分岐なら、
問題無いという話を，漏れは聞いたことがある．
で，外れまくってイヤソなタイプのコードもあって，
例えばブレゼンハムのアルゴリズムは，結構イヤソだ，
という報告も聞いたことがある．
漏れの直感ではイヤソなタイプという気がする．
GHC はバージョンupが烈しいんで，最近の奴は
自分にはようわからん．ココは Haskell 板なんで
Haskell の話と思ったが，もしかして strict な
奴の話も必要 ?
282:デフォルトの名無しさん
02/06/29 17:29
>>280
SETｃｃって何？
判定と分岐を分離して、間に命令をはさむDeleySlotの一種のような
ものと勝手に想像したがどう？
283:Super Combinator
02/07/01 00:39
SETcc: 条件付き定義命令。
CMOVcc: 条件付き移動命令。
if (条件)
var = X;
} else {
var = Y;
}
を
var = Y;
if (条件) var = X; // SETcc or CMOVcc
に。
もちろんvarはregister割り当てされてるのな。
284:デフォルトの名無しさん
02/07/01 02:19
ARMとかに最初っからついてるやつですな。
x86にも最近のはついてるときいて感心した私。
っていうか、関数型言語って naiveな実装だと closure作りまくりで
予測分岐も糞もない、って気がするんだけどだめ?
ちゃんとかりかり tuning する、GHCみたいのだといいかんじになるのかも
しれないけど。よくわからん。
結論: 関数型言語は dataflow machineに実装しよう(ネタ)
285:デフォルトの名無しさん
02/07/01 07:52
>>284
ネタとは言い切れん。
いい加減に今のアーキテクチャでのクロック向上ってのも物理的限界が
見えてきたしね。
286:デフォルトの名無しさん
02/07/01 15:16
>>285
そうだそうだ。(煽)
ついでに非同期って正義 ?
Crusoe の内部論理では活かされてるとか
聞いたことがあるけど ＞ 非同期
287:デフォルトの名無しさん
02/07/11 09:01
URLﾘﾝｸ(univ.ygu.ac.jp)
URLﾘﾝｸ(www.microsoft.com)
288:デフォルトの名無しさん
02/07/11 09:14
URLﾘﾝｸ(www.mail-archive.com)
盛り上げれ
289:石敢當
02/07/11 21:56
GHC 5.04 がリリースされました。
290:デフォルトの名無しさん
02/07/12 01:40
さっそくビルド、あげ！
291:デフォルトの名無しさん
02/07/16 00:36
質問くんで、すいません。
どなたかLinar Typeというものが、どんなモノか教えてもらえませんか？
「論文紹介：How to Declare an Imperative」
URLﾘﾝｸ(www.is.titech.ac.jp)
で見た限り純粋関数型言語でIOや状態を扱うのに
将来有望そうな理論（技術？）に見えました。
URLﾘﾝｸ(citeseer.nj.nec.com) のどこかとかが参考になりそうですが
どれが良いのやら。さっぱり。
だれか基礎と応用の両方を教えていただけないでしょうか？
お願いします。
292:デフォルトの名無しさん
02/07/16 03:03
っていうか、まずその紹介されてる論文の、その章を見れば良いじゃん。(^^;
そしたら、そこからreferされてる論文を次に読むとか…
（citeseerがOKなら英語でOKだよね。）
とりあえず、すでにHaskellを知ってるなら、Cleanって言語の
uniqueness typingって仕組みを使ってみるのが吉かと。
URLﾘﾝｸ(www.cs.kun.nl)で合ってる？＞もっと詳しい人
293:デフォルトの名無しさん
02/07/16 10:17
linear logic (線形論理) ね。
論理にヨワい自分は岩波の 2 冊本
「コンピュータサイエンス入門」
で、やっとこ様相論理に辿り付いたトコなんで
有意義な助言はできんが...
とりあえずロジックに関してどれくらいわかってます ?
>>291
294:デフォルトの名無しさん
02/07/16 16:29
分からないんだったらまずはぐぐりなさい。
URLﾘﾝｸ(www.google.co.jp)
295:デフォルトの名無しさん
02/07/16 16:30
又は、
URLﾘﾝｸ(www.google.co.jp)
296:デフォルトの名無しさん
02/07/16 22:58
どうして、そんなに遅いの？
297:デフォルトの名無しさん
02/07/16 23:06
>>296
それは言える…
CleanとかMLとかは速いらしいのに！
298:名無しさん＠Ｅｍａｃｓ
02/07/16 23:37
Haskellは生成されたバイナリよりも、
コンパイラ自体がhaskellで書かれてる
ことによる遅さがちょっとイラつかせる。
また勉強中の身だから偉そうなことは
いえないですね。失礼しました。
299:デフォルトの名無しさん
02/07/16 23:44
Cleanもそうです。
300:291
02/07/17 03:36
沢山のレスありがとうございます。
>>292
英語は、辞書が在れば何とか読めるという程度です。
「uniqueness typing」ですか。Cleanの特徴の一つらしいですね。
評価するたびに違う(多様?)型を生成するというぐらいしか知りません。
参照透明性は確保されそうですが、使いやすいの？
というぐらいの認識しかありません。もう少し調べてみます。
>>293
私も論理に弱いです。
Linear Ligicと言われても、使った公理は無くなる。
つまり公理の有る無しで状態を表すようにするという位しか
わかっていません。
この認識も間違っているかもしれませんし・・・
つたない英語力と乏しい知識を総動員して何か判りやすい文章、本、論文
は無いかとあさっているという状態です。
>岩波の 2 冊本「コンピュータサイエンス入門」
ですか今度、大きい本屋に行ったときでも見てみます。
>>294
日本でも沢山の所が研究しているんですねー。
みてみます。
301:デフォルトの名無しさん
02/07/17 17:54
>>298
それはグラスゴ大-MSRのサイモン教授のコンパイラの話 ?
手軽に遊ぶには、HUGS とかシャルメル大のコンパイラが
おすすめ。
>>300
キーワードは「非古典論理」「数理論理学」といったとこだ。
まとまった解説がウェブには無い（記号が、紙媒体だと圧倒的に
見やすい）のと、ちょい高価だったりなので、そのテの本が
揃った図書館を確保できないと辛いかも。
岩波のそれは時相論理という論理の解説がメイン。
（線形論理も時相論理も様相論理といわれる論理の
一種）線形論理の解説書は一冊だけらしい。
IPSJ の学会誌とか研究報告が見れるんなら↓あたりが手頃そうだ。
URLﾘﾝｸ(www.ipsj.or.jp)
URLﾘﾝｸ(www.ipsj.or.jp)
302:デフォルトの名無しさん
02/07/17 21:02
>>297
＞CleanとかMLとかは速いらしいのに！
non-strict な ML と、strict な Haskell を
比較すんなよ (;_;) せめて LazyML とか
303:291
02/07/17 23:57
>>294
国立奈良工業高等専門学校の先生のページに
論理型言語ですが時相と線形理論に関する論文載っていました。
URLﾘﾝｸ(kaminari.scitec.kobe-u.ac.jp)
少し判った気がします。
でも、これを如何いうふうに関数型言語に輸入すればいいのやら。
あと、下の本知っている人いますか？
線型論理入門 竹内 外史
URLﾘﾝｸ(www.amazon.co.jp)
304:291
02/07/18 00:00
>>301
>岩波のそれは時相論理という論理の解説がメイン。
そうなんですか。買おうかな。
>IPSJ の学会誌とか研究報告が見れるんなら↓あたりが手頃そうだ。
学術誌は・・・。大学生のころは読めたのにね。
地元の大学言ってみような？如何しようかな？
305:デフォルトの名無しさん
02/07/18 03:04
> non-strict な ML と、strict な Haskell を
逆
306:名無しさん＠Ｅｍａｃｓ
02/07/18 05:03
なんでいつもMLとHaskellはいがみあるばかりなんですか？
CとC++
JavaとC#
PerlとRuby
他にもそういうの多いですがね。
307:デフォルトの名無しさん
02/07/18 10:17
>>306
そういう低次元な話にもっていくな。
308:302
02/07/18 18:30
>>305 トチった。ｼｸｼｸ
>>306
別に、いがみあう必要ないじゃん。Standard ML では、
引数は適用される前に評価される、Haskell では、
普通はそうじゃない、ってダケの話。
他のヤツだって。.NET 使いたいなら C# 、
ケータイ用アプレットが作りたいなら Java とか、
現実、選択肢は広く持っていたほうが楽しいん
だからさ。
309:デフォルトの名無しさん
02/07/18 20:45
Haskellってnamespace無いの？
310:デフォルトの名無しさん
02/07/18 22:13
>>309
たぶん module 機構がソレ。
Haskell98 仕様書の 5 節、
じぇんとるいんとろの 11 節。
URLﾘﾝｸ(www.haskell.org)
URLﾘﾝｸ(www.haskell.org)
311:デフォルトの名無しさん
02/07/19 00:57
>310
あ、ほんとだ。ｻﾝｸｽｺ
312:デフォルトの名無しさん
02/07/19 01:13
>>308
SMLでも遅延評価でますよね。
Hsakellほど積極的では無いですが。
313:デフォルトの名無しさん
02/07/19 01:46
>JavaとC#
>PerlとRuby
この変は似たもの同士だからだろ？
314:哲板過去ログから
02/07/19 17:42
哲学板「論理なぜなにスレッド」の最後のレス
URLﾘﾝｸ(mentai.2ch.net)
114 名前： 考える名無しさん 投稿日： 02/03/08 02:04
「論理学」スレの過去ログから。
229 名前： 考える名無しさん 投稿日： 01/12/10 18:21
論理学の基本的教科書とは何ですか？
様相論理とか線形論理を一通り学びたいのですが。
英語のものでいいものを教えてください。
230 名前： ↑ 投稿日： 01/12/10 18:39
A.S. Troelstra, Lectures Linear Logic, CSLI Lecture Notes 29 (1991）
線形論理の入門書で、線形論理のゼロからを勉強できる本です。線形論理導入のモチベーシ
ョンから始まって、様々なヴァリエーションの線形論理とそれらの性質、代数的、圏論的モデル、
proofnetと、基本的な部分はかなり幅広くおさえてあり、そしてとても解りやすいです。しかも周辺
のトピックも広く紹介されているので、その辺を調べながら読めば、線形論理に限らず、証明論
の勉強になるのではないか、と思います。ただし、大きな問題は、GirardによるLinear Logicのオ
リジナル論文（その他、その後のLinear Logic関係のあらゆる論文）と記法が紛らわしい、というこ
と。嫌でも混同しやすいLinear Logicの記号なのに、同じ記号を別の意味で読み替えたりしなけ
ればならず、かなり厄介ですので、それは覚悟の上でどうぞ。
231 名前： ↑訂正 投稿日： 01/12/10 18:43
A.S. Troelstra, Lectures on Linear Logic, CSLI Lecture Notes 29 (1991）
URLﾘﾝｸ(www.amazon.co.jp)
315:314続き
02/07/19 17:43
>>314-315続き
235 名前： 考える名無しさん 投稿日： 01/12/12 17:18
URLﾘﾝｸ(www.amazon.co.jp)
をかいなさい。
242 名前： 考える名無しさん 投稿日： 02/01/06 15:37
>>229
いまどきならTroelstraとかHughes-Cresswell（古臭いっ）よりこっちがいい。
非古典論理を統一的に学べます．
URLﾘﾝｸ(www.amazon.co.jp)
日本語なら小野寛晰先生の本がおすすめ。
244 名前： 考える名無しさん 投稿日： 02/01/10 02:32
>>242
おいおい、Hughes-Cresswell の第二版は 1996年に出たばかりだぞ。
なんかがらりとかわって別の本みたいになってると思ったけど、違うっけ？
今どきで、お手軽で様相論理絡みの非古典論理というなら、俺は、
URLﾘﾝｸ(www.amazon.co.jp)
これをすすめたい。安いし、哲学の話もそれなりに多く書いてあるから、
この板の人向きと思うが。
316:291
02/07/21 09:40
おひさしぶりの291です。
私にとって言語（英語）の壁は厚いので
そんな立派な本は、ちょっと・・・
という感じです。
とりあえず「コンピュータサイエンス入門」と「線型論理入門」は買いました。
ゆっくり勉強したいと思います。
317:デフォルトの名無しさん
02/07/21 13:30
あーまてまて。^^; 最終目的にもよるが、linear typeの勉強をするのに、
linear logicの教科書まで読破する必要はないべ。（してもいいけど）
俺もlogicのほうは耳学問程度だが、linear typeのほうは
関連する研究で論文を発表できたぐらいには理解してる…つもり。
それよりもプログラム理論のお勉強のほうが重要かも。大堀先生の
「プログラミング言語の基礎理論」って教科書なんかどうだ。
線形型までいってないけど、それ以前に線形でない普通の型の理論を
理解しないと。
本を読むにしても、何も予備知識がないときついだろうから、以下で概説。
もし説明が下手で余計に混乱させちゃったらスマソ
318:317
02/07/21 13:41
HaskellとかMLとか使ってれば、普通の型は知ってることにしていいよな。
言語によっていろいろと書き方は違うが、たとえばintだったら整数だし、
floatやrealだったら浮動小数だし、int -> floatだったら
整数から浮動小数への関数だし、int * floatとか(int, float)とかは
整数と浮動小数の組だし、要するに値を分類してるわけだ。
で、線形型ってのは普通の値の分類をもっと細かくして、
その値を使う「回数」の情報まで付け加えた型なんだ。
テキストだと書きづらいが、int ->1 floatとか
int ->0 floatとかint ->ω floatとか。
それぞれ、「１回だけ呼び出される関数」「決して呼び出されない関数」
「何回でも呼び出させる関数」の型。
319:317
02/07/21 13:51
で、そんなのが何の役に立つかというと、いろいろとあって
・もう「決して使わない」ことがわかった値はゴミなので、ガベコレできる
・式の遅延評価をするときに、「1回しか使わない」とわかっている値は
後のために覚えなくても良いので、オーバーヘッドを減らせる
・逆に「必ず1回は評価される」ことがわかってる式は、そもそも
遅延評価しなくて良いので、やっぱりオーバーヘッドを減らせる
・同じように、「必ず1回は実行される」ことがわかってる副作用は、
（Haskellのモナドみたく）遅延しなくても良いので、MLみたく
その場で直ちに実行できる(?)
って感じ。最後のは俺がよく知らないので、Cleanとかに詳しい人がいたら
フォローをきぼんぬ。
320:Super Combinator
02/07/21 14:00
>>316
竹内外史の本はかなり手ごわい。
321:317
02/07/21 14:04
最後にlogicとの関係だが、linear logicっていう「命題を使える回数」も
考慮した論理があって、linear typeも元々はそこから派生したそうな。
どんな論理かというと、よくある説明なんだが、
命題P = 「あなたは120円を持っている」
命題Q = 「コーラを買える」
命題R = 「お茶を買える」
とおいて、Pと「PならばQ」と「PならばR」の3つが成り立っているとする。
すると、普通の論理ならPを2回ほど使って「QかつR」を結論できてしまうわけだが、
120円でコーラとお茶の両方が買えるってのはおかしいよな。
だから、そういう「使ったらなくなる」ものを考えに入れて、
「命題Pは一回しか使えない」みたいな性質も考慮できるようにした論理が
linear logicというわけだ。上の例だと、Qを結論することはできるし、
それとは別個にRを結論することもできるが、「QかつR」を同時に
結論することはできない。
322:317
02/07/21 14:11
と、これぐらい知っていれば、後はCleanを使ってみるなり、
上のほうのWadlerのチュートリアルを読んでみるのが
（linear logicの教科書を読破するよりは）手っ取り早いと
思うんだが、どう？ もちろん、特定の目的じゃなくて
一般教養としてなら、linear logicの勉強もいいかもしれないけど。
もし英語が苦手だと最初は大変かもしれんが、この手の
（わりと）新しい話を少しでも突っ込んで調べようと思ったら、
何でも英語は避けて通れないと思われ。っていうか、下手な
日本語の解説よりも、上手な英語の説明のほうがわかりやすいかと。
323:Super Combinator
02/07/21 15:24
andとorに分配法則が成り立つのと成り立たないのと二種類ある、
それがlinear logic。>>321みたいなのを特にresource logicと呼ぶことがある。
324:317
02/07/21 15:39
ええと、323さんはなんでそんな風に思った？^^;
嘘を教わっているか、思い違いをしてそうなので、
例のInformation & Computationをのっとった、Girardの
オリジナルの論文を読むと吉かと思われ。
Girardの「しゃべる」英語は激しいフランス訛りで、
発表を聞いてても個人的に話をしても言ってることが
すげーわかりにくいが（笑）、上の論文はわりとわかりやすい。
325:覚え違いスマソ
02/07/21 15:43
誤: Information and Computation
正: Theoretical Computer Science
326:291
02/07/21 23:32
どうも291です。
みなさんの親切なレスが貰えてうれしいです。
>>319
論文読んでもlinear typeの構造が判ったような気がするというレベル
で止まっていました。なるほど。
linear type関連の論文て意外と少ないような気がしたので、そのバックにある
linear logicを勉強すればlinear typeのことが判るかな？という安易な動機しか
なんですけどね。
でも記号の操作のしかた忘れたなー。完璧に。
あとCleanですか？Downはしてますけど、使ったとき無いです。
うーんCleanも勉強すべきなのかな？
327:291
02/07/22 01:02
>大堀先生の「プログラミング言語の基礎理論」
この本は持っています。
読んでいますし、3割ぐらいは理解しているつもりです。
型推論も基礎となるアイデアも理解しているつもりです。
>上のほうのWadlerのチュートリアルを読んでみるのが
「Linear types can change the World!」は読んでいます
（20ページ程度の文書なら、英語でも読む気がするんですがね。）
でも、この論文は、317さんの解説のやつとは少し違うかな？
328:293,301
02/07/24 11:54
あ、論理カゼを吹かせてしまったのは自分だ。スマソ m(_ _)m
Wadler の解説に目を通してみました。World 型の
ような、捨てたり複製しちゃいけないとかいう値を
導入するための仕掛けが線形型ってことですね。
monad の解説 "Imperative functional programming"
の 4 節にある、評価順序を保証するためだけにある、
受け渡されるだけで値は運ばない変数 w を表面に
引っ張り出して活用する、という感じなのでしょうか。
↑これは激しく勘違いかも。
上の >>319 で説明されてるところは、Haskellコンパイラ
方面で研究されてる必須性解析やら更新回避解析やらを
プログラマが明示できる/しないといけない、と感じたん
ですが、どうでしょうか。
329:デフォルトの名無しさん
02/07/24 23:14
Cleanに関するページのようです。
Cleanってすごいですね。
URLﾘﾝｸ(sky.zero.ad.jp)
330:デフォルトの名無しさん
02/07/25 22:22
URLﾘﾝｸ(www.sysj.co.jp)
331:デフォルトの名無しさん
02/07/26 13:33
藁藁
332:デフォルトの名無しさん
02/07/26 18:49
>>329のサイト、ブラウザで画像もJavaScriptもOFFにしてたら、トップページから中に入れない。
しかたないからHTMLソース見てみたら…
＞<!--
＞こういっちゃなんだけど、人のページのソースを見るのはどうかと思いますよ。
＞そういう人は今後このサイトには来ないようにして下さい。ええ。
＞-->
ｺﾜｲﾖｰ
333:332
02/07/26 18:59
あ、上の書き込みだけだと中傷にしか見えませんね。スマソ。
初心者の僕にはとても勉強になりました。つーか、大堀先生の本が読めなくて
ちょっとへこんでたんですけど、書評読んだらすこし元気が出てきました。
がんばるぞー。
334:デフォルトの名無しさん
02/07/26 19:22
>>333
わかんなければソース見てもいいと思うぞ。勉強になる。
あっちが見られる様な媒体で見られたくないものを置いている方が悪いんだから。
335:デフォルトの名無しさん
02/07/26 19:53
(゜д゜)＜あらやだ！
URLﾘﾝｸ(www.amazon.co.jp)
未だ全部読んでないのに、
Haskell:the Craft of Functional Programming
の第三版が出ちゃった！
……と思ったら日付が、
336:デフォルトの名無しさん
02/07/26 20:04
スゲ～
二度と見に行くかよ、と思わせるためにやってるとすれば、
とっても効果的だ。
337:デフォルトの名無しさん
02/07/27 00:35
>>335
俺も一瞬そう思った
338:デフォルトの名無しさん
02/07/27 00:49
age toku yo
339:デフォルトの名無しさん
02/07/27 01:15
<!--
すぐに出せるようにと思ったんで、
今後の更新予定とかをコメントでつけてましたが、
それらは全部削除しました。
まあ確かにそんなものをつけるべきではないのかもしれませんね。
-->
コメント変わった？
ここ読んでる？
340:デフォルトの名無しさん
02/07/27 01:35
>>329
の書き込みは要するに自作自演書き込みって事でしょ。
341:デフォルトの名無しさん
02/07/27 01:35
世間が狭いだけでは
342:デフォルトの名無しさん
02/07/27 09:03
>>339
削除した理由が、
「まあ確かにそんなものをつけるべきではないのかもしれませんね。」
誰かに注意を受けたと取るのが一番か。
343:デフォルトの名無しさん
02/07/27 09:34
書評も的を射ていないっぽ
344:デフォルトの名無しさん
02/07/27 14:07
スレ違い。
345:デフォルトの名無しさん
02/07/27 18:13
CLEANを紹介したのはエライが、
自作自演とか、偉そうにWeb作ってるのはイクナイ。
346:デフォルトの名無しさん
02/07/27 23:11
なぜ自作自演？
とか書くと、これも自作自演と勘違いされるのだろうか？
>偉そうにWeb作ってるのはイクナイ
作っている分だけ偉いです。
ヒガミはイケナイネ。
347:デフォルトの名無しさん
02/07/28 08:06
Ｃｌｅａｎのページ作ってる奴はここを読んでるやうだな。
Ｃｌｅａｎってば名前しか知らなかったので、ページ作ってくれたのは非常に
よろしいと思う。イイ。
だけど、自分の理解が怪しいこととかまで、無理して書いてないかの？
斜めにしか読んでないが、なんか外してるところがある気がちょっとする。
>>339とかもどうかと思われ。
348:デフォルトの名無しさん
02/07/28 08:29
Haskellの話をしよ～ぜ。
349:デフォルトの名無しさん
02/07/29 00:25
Haskell がメインの開発言語になってる会社ってありますか？
350:デフォルトの名無しさん
02/07/29 08:46
>>349
Galois Connections
URLﾘﾝｸ(www.galconn.com)
351:デフォルトの名無しさん
02/07/29 10:31
もし、今後 Haskell 本とか書くヒトが居たら、是非
「本書の内容の正否・当否についての質問・意見は、明確で
具体的な理由をつけて、匿名ではなく、hoge@hoge.jp まで
お願いします。また、これら以外のことに関する本書への
批判・評論は刑法230条又は231条等に触れる恐れがあり
ますのであくまでも自己責任でお願い致します。」
とでも、表 2 カバー裏あたりに書いとけば良いかも :-)
352:デフォルトの名無しさん
02/07/29 10:38
>>351
なんだそれは。
Ｃｌｅａｎのページ作った人ですか？
突っ込まれたから、ぼやいている？
Haskellのページとかschemeのページは前からあるけど、
だれも苦情は言わないし、ありがとうしか言わない・・ですが？
353:デフォルトの名無しさん
02/07/29 10:38
「本書の内容の正否・当否についての質問・意見は、明確で
具体的な理由をつけて、匿名ではなく、hoge@hoge.jp まで
お願いします。また、これら以外のことに関する著作者への
批判・評論は刑法230条又は231条等に触れる恐れがあり
ますのであくまでも自己責任でお願い致します。」
こうだな、正確には。
354:デフォルトの名無しさん
02/07/29 10:52
>>351
バイアスかけるのは止めてね
Haskellのスレだし。
355:デフォルトの名無しさん
02/07/29 11:30
>>351
おまえ私怨か？
356:デフォルトの名無しさん
02/07/29 13:33
>>351マンセー（ｗｗ
357:デフォルトの名無しさん
02/07/29 17:34
Haskeﾙﾝ
358:デフォルトの名無しさん
02/07/29 20:55
ああ、DUAL!ってやつ？
359:デフォルトの名無しさん
02/07/29 23:02
?
360:デフォルトの名無しさん
02/07/30 18:13
>>352
ぼやきか・・・
それはもしかしたらイタイ発言ではなかろうか
361:332
02/07/30 20:28
なんか俺のカキコのせいで荒らされちゃってますね、スレの皆さんごめんなさい。
もう夏休みに入ってるって事をすっかり忘れてました。
362:デフォルトの名無しさん
02/07/31 00:54
>>361
お前のような万年厨も問題だがな
363:デフォルトの名無しさん
02/07/31 02:40
>>362
ハー。
人の振り見て・・・ということで。
364:デフォルトの名無しさん
02/07/31 17:02
>>363
厨
365:石敢當
02/08/02 22:28
Haskell 98 Report が本になるみたいですね。
366:デフォルトの名無しさん
02/08/02 23:01
>>365
母さんソース
367:デフォルトの名無しさん
02/08/02 23:08
じゃ、誰かものすごい勢いで日本語版も
出版してくれよな。
368:デフォルトの名無しさん
02/08/03 08:55
気づいたら最初のスレが立ってから一年過ぎてる。
最初のころはHaskellスレ限定コテハンも何人かいて妙にまたーりとしていた
気がするのだが、最近廃れっぷりが激しいな。最初のころのような勢いも無いし。
懐 古 う ざ い
よね。
すまん。逝ってくる。
369:デフォルトの名無しさん
02/08/03 09:25
ネタがないんじゃよー
誰かお遊びで作ったプログラムとか貼ってくれませんか？
370:デフォルトの名無しさん
02/08/03 15:03
関数型言語初心者です。
Haskellでクイックソートのコードを以前見かけて、こんなにシンプルになるのかと感動しました。
では、バブルソート(二重for文で大小比較の単純なやつ)はどうなるのでしょうか。
iとjを引数にして二重に再帰を繰り返し、takeやdropで切り貼りするしか無いのでしょうか？
もっと効率のいいやり方があるのでは、と思うのですが…
371:デフォルトの名無しさん
02/08/04 05:06
>>370
それらしいものを書いてみようとしたら
選択ソートとバブルソートが混ざったような中途半端なものになった。
bubbleSort :: Ord a => [a] -> [a]
bubbleSort xs = bs xs []
bs [] _ = []
bs [x] rest = x : bs rest []
bs (x1:x2:xs) rest = bs (min x1 x2 : xs) (max x1 x2 : rest)
つか効率を気にすればするほど選択ソートっぽくなると思う。
372:デフォルトの名無しさん
02/08/04 05:20
このスレってほとんどコード出てきてないのな。
373:デフォルトの名無しさん
02/08/04 07:27
Haskellは犬ですか？
374:デフォルトの名無しさん
02/08/04 13:54
Haskellerと言ってもその程度。
375:370
02/08/04 16:19
何故>>371でソートになるのか悩んで、紙に書いてようやく理解しました。
最小値を取り出して、それを x : bs rest [] で先頭に結合しているわけですか。
bs xs i j なんて関数を作って手続き型そのままにやろうとした俺とはえらい違いです。敬服。
376:370
02/08/07 22:54
数日間が空いてはっと気付く…
>>371のコードですと、要素数に比例してスタックを消費してしまいませんか？
(半端な知識ですが、末尾再帰になってなく見えます。書き直せないところが厨ですが…)
関数型言語の場合、スタック消費は気にしない方がいいのでしょうか。
377:デフォルトの名無しさん
02/08/10 10:05
>>376
関数型言語では基本データ構造のリストが再帰的（末尾再帰ではない）に
定義されているわけで、そもそもスタックを消費しまくることを前提に
作られているでしょうから、スタックの消費をあまり気にしなくていい言語と
して使えるはず。
Haskell のような遅延評価が基本の言語では、自然な再帰のアルゴリズムの
プログラムを、末尾再帰のアルゴリズムのプログラムに書き換えることも、
計算のオーダーが変わるようなもの以外は、あまり、気にすることはない
気がします。
378:デフォルトの名無しさん
02/08/10 11:42
よく関数型言語で Xs, とかYsってvariableなんだけど、なんでXsなの？
この最後のＳはどっからでてきたの？Ｘ，Ｙ，Ｚ，Ｗ，Ｖとかでいいじゃん。
Ｓなんてつけなくても
379:デフォルトの名無しさん
02/08/10 12:14
x:xs
複数形のsです。
380:日曜Haskellerオヤジ
02/08/11 06:22
ものすごい久々です、
現在はプログラミング基礎論の勉強がてら一緒に Haskell もお勉強モードな土日です。
>>368
特に初心者がやるときには、英語を勉強しつつ Haskell の勉強もしようとすると
忙しくなりすぎて、とりわけ社会人だと極度のんびり勉強モードになってしまいます。
そうすると、どうしてもネタが尽き気味になりますよね、
和書の入門書がぜひとも欲しいところです。
大学院の学生さんたちの誰かが執筆してくれればいいんですが、だれか書きませんかね？
Haskell は離散数学とか圏論とかとセットにすると非常に面白い本ができると思うのですがどうでしょう？
あと、圏論の専門本も是非とも欲しいところですね、これも本当にない、
まったくと言って良いほど本がない、あっても絶版ばかりで手に入りません。
シュプリンガーフェアラーク出版の「代数学とは何か」に書かれてあるのが、
手に入りかつ、知っている範囲なのですが、
これは数学の専門書でプログラマには少々というかかなりの難解ぶりです。
自分がなんとか読めそうと感じられる範囲では、
ここ URLﾘﾝｸ(www.etl.go.jp)
にあるんですが、これも内容を充実して製本された本が欲しいところです。
初心者向きといえば、以前工科大のページがあったんですが
消滅してしまっているようです、越田センセまた何かページつくってくれないかな・・