【アンチ】関数型言語は使えない【玩具】
レス数が1000を超えています。これ以上書き込みはできません。
0001デフォルトの名無しさん
2011/11/08(火) 18:06:57.51玩具として、研究者や学生の自己満足として、
教科書や黒板を賑わすアクセサリーとして、
あるいは頭の体操としての価値は認める。
だが、仕事ではほとんど使い物にならない。
やれば作れる、実際に作った、そんな言い分は聞き飽きた。
主要なソフトウェアのほとんどは非関数型で書かれている。
関数型がプチブームだが、爆発的に採用が増えているとも考えられない。
いずれ関数型のブームは去るだろう。
仮に関数型が生き残ることがあったとしても、
手続的な言語における一部の機能としてだろう。
0002デフォルトの名無しさん
2011/11/08(火) 18:33:19.43アイちゃんアイちゃん
0003デフォルトの名無しさん
2011/11/08(火) 18:40:07.750004デフォルトの名無しさん
2011/11/08(火) 18:50:44.56業務の手順等も全く関数的でない。
「まずこれをやって、それからこうして、
それでこうなるから、これをこうする」的な考え方をするのが普通の人間。
もしそれを自動化するプログラムを書こうとした場合、
それを素直に書ける言語のほうが普通は楽にできる。
仮に関数型のほうが簡潔に書けたとしても、
関数型に脳内変換しなければならない時点で負担は大きい。
関数型なら生産性が向上するという主張は、
一部個人ではそういうこともありうるが
社会全体としてはむしろ生産性の低下につながる。
関数型が使えないのは頭が悪いからだというのは、まぁある程度正しい。
だったら頭の良い人が自己満足で使っていればよいのであって、
他人様を巻き込む必要はない。
0005デフォルトの名無しさん
2011/11/08(火) 19:06:26.34感染した研究員はどのスレッドにも同じコピペを
繰り返すといった症状が報告されています。
研究員によると思われる書き込みがあっても
近づかないようにしてください。
京都大学
0006デフォルトの名無しさん
2011/11/08(火) 19:09:22.90http://toki.2ch.net/test/read.cgi/cafe60/1270834077/
0007デフォルトの名無しさん
2011/11/08(火) 19:12:56.72クライアントアプリケーションに関数型の適用は不適切だと思う
Webサーバアプリは大きく見ればフィルタと見なせるから
組みやすさは別として関数型が使える分野だと思う
使ったことはないが
0008デフォルトの名無しさん
2011/11/08(火) 19:49:17.34よって関数型言語は流行りようがない
0009デフォルトの名無しさん
2011/11/09(水) 10:29:21.690010デフォルトの名無しさん
2011/11/09(水) 10:41:44.92流行らないから安心しろ。
分かる人間だけが細々と使っていき、その成果が手続き型に取り込まれていくだけ。
もし流行るなら、もっとマシな世界になってる。
0011デフォルトの名無しさん
2011/11/09(水) 14:46:59.29言語訓練のために立てたものです。
アイと研究員とのやり取りに利用するスレッドなので、
関係者以外は書きこまないで下さい。
京都大学霊長類研究所
0012デフォルトの名無しさん
2011/11/09(水) 15:18:41.53スレタイ間違ってるよwww
誤：【アンチ】関数型言語は使えない【玩具】
正：【アンチ】関数型言語が使えない【玩具】
0013デフォルトの名無しさん
2011/11/09(水) 17:56:57.42CやRubyより覚える事少ないと思うんだが。。。
0014デフォルトの名無しさん
2011/11/09(水) 18:01:16.240015デフォルトの名無しさん
2011/11/09(水) 18:06:08.13>>1は典型的なハスケラ症の患者
>366 名前: デフォルトの名無しさん Mail: sage 投稿日: 2011/10/26(水) 12:25:43.06
>>>365
>それはハスケラ特有の症例で、心の病の一つ
>
>ハスケルという言語を使っていると、世の中のあらゆる事柄すべてが
>ハスケルを中心に廻っているように見えるらしい
>従って、あらゆる関数型言語は静的実行かつ静的型付けでなければならないし、
>遅延評価が常識であり、一切の副作用は認めようとしない
>
>ハスケラにとって関数型言語とはハスケルのことであり、
>その窓から見える世界が彼らのすべて
誤：【アンチ】関数型言語は使えない【玩具】
正：【アンチ】ハスケルは使いものにならない【玩具】
0016デフォルトの名無しさん
2011/11/09(水) 18:18:50.26プログラム書くのはそういう人達だけじゃないからな
0017デフォルトの名無しさん
2011/11/09(水) 18:25:43.240018デフォルトの名無しさん
2011/11/10(木) 04:51:27.64一次関数二次関数習ってれば、十分覚えられるだろ
0019デフォルトの名無しさん
2011/11/10(木) 11:31:32.54にある言語を使えるわけがないわな。
0020デフォルトの名無しさん
2011/11/10(木) 11:54:04.26学習コストと暗記量は比例しない。
覚えることが少なくても
使いこなすのが難しければ
学習コストは高い。
0021デフォルトの名無しさん
2011/11/10(木) 12:04:22.150022デフォルトの名無しさん
2011/11/10(木) 13:21:47.56使いこなす事も簡単だと思うけど。。。。
自分、yesコマンドとか、haskellでは作れても、Cやrubyで書けへんねん
0023デフォルトの名無しさん
2011/11/10(木) 13:22:34.25せやな
0024デフォルトの名無しさん
2011/11/10(木) 16:37:17.80それを言っちゃ。。。。
お里が知れる。
0025デフォルトの名無しさん
2011/11/10(木) 22:18:12.24無限ループ内でひたすらyes\n出力してフラッシュじゃだめなん？
0026デフォルトの名無しさん
2011/11/10(木) 22:26:04.37こんな感じ？ 恥ずかしながらyesコマンドって初めて知った
0027デフォルトの名無しさん
2011/11/10(木) 22:30:08.560028デフォルトの名無しさん
2011/11/10(木) 23:02:36.21ごめん。
たぶん、作れる。
作り方もそれで合ってると思う。
確実に作れないのはクイックソートをCでは作れないなw
配列でってだけで、どうすれば良いのか分からんw
昔、Cのクイックソート読んだけど、全然何やってるのか分からんかったｗｗｗ
>>26
Haskellの入門書（日本人の書いた「入門Haskell」の方）に乗ってて、ちょっと前に、コマンドライン版じゃんけんゲームのテスト用に思い出しながら書いた
じゃんけんゲームは別にCでもRubyでも書けるんだけどね…
0029デフォルトの名無しさん
2011/11/12(土) 15:55:12.09別に間違ったことは言ってないだろ。
Common LispのほうがSchemeより使いやすいと感じる。
Schemeは覚えることは少ないが、理論に走りすぎ、
ミニマム主義が度を越していて、再帰を強要しすぎで、
実用性ではCommon Lispより劣る。
Common Lispは関数型のような手続き型だと言えなくもないが、
あれくらい節操が無くて何でもありのほうが
過剰にテクを要求されないので書きやすい。
0030デフォルトの名無しさん
2011/11/12(土) 16:52:47.340031デフォルトの名無しさん
2011/11/12(土) 17:43:17.92>だったら頭の良い人が自己満足で使っていればよいのであって、
そのロジックなら「頭の良い」人が集まる会社は関数型を使うべきだよね
個人的には、その意味で「頭の良い」人はプログラマ人口の50%を超えると思う
0032デフォルトの名無しさん
2011/11/12(土) 18:00:45.24> そのロジックなら「頭の良い」人が集まる会社は関数型を使うべきだよね
え？その論理能力で関数型分かってるとか自称するの？
対偶を取っても、「頭の良い人は関数型を使える」であって、「使うべきだ」にはならんぜ？
書いてからそれ思った
言い訳をすると、使えるなら使う方が良いというのは
「だったら〜使っていればよい」から読み取れないこともないよね
0034デフォルトの名無しさん
2011/11/12(土) 18:11:47.45色々な言語や環境を使ってみて自分で評価するのは大事なことだよね。
でも、「使うべき」という言葉からは、微妙に排他的なニュアンスを感じなくもない。
昔のオブジェクト指向もそうだったけど、これから盛り上がろうという言語や環境は
得てして独善的になったり排他的、攻撃的になったりしがちだから、
気をつけたほうがいいかもね。
俺自身が「使うべき」と主張してる訳じゃないからな、一応言っておくと
0036デフォルトの名無しさん
2011/11/12(土) 18:21:45.24あ、すまん、勘違いしてた。吊ってくるわ。
0037デフォルトの名無しさん
2011/11/12(土) 18:24:11.18誤った用法：
>これから盛り上がろうという言語や環境は
>得てして独善的になったり排他的、攻撃的になったりしがちだから、
正しい用法：
>ハスケラは
>得てして独善的になったり排他的、攻撃的になったりしがちだから、
0038デフォルトの名無しさん
2011/11/12(土) 18:28:39.88ただし、Haskellのコードが本当に正しいのかは疑問が残る。
証明うんぬんとか言うが、全てのコードが正しさを証明されているわけじゃあるまい。
ましてや、仕様自体の無矛盾性まで証明されているわけでもあるまい。
0039デフォルトの名無しさん
2011/11/12(土) 18:50:51.29[一般] なぜ関数型言語は普及しないか - プログラミング日記
言語を利用するための条件は以下の３つになると思う。つまり、言語が普及するための条件とも考えられる。
* 使用するための必要条件を満たしているか
* その言語を使用するメリットがあるか
* デメリットはないか
0040デフォルトの名無しさん
2011/11/12(土) 21:24:20.760041デフォルトの名無しさん
2011/11/12(土) 22:27:12.33ツールでUML生成してニヤニヤするのがいいんじゃないか
0042デフォルトの名無しさん
2011/11/12(土) 22:46:00.020043デフォルトの名無しさん
2011/11/13(日) 05:32:45.92メモリ消費が予測不能すぎ
ML系のほうが扱いやすいよ
0044デフォルトの名無しさん
2011/11/13(日) 21:02:35.86ってか、関数型のメリットってオブジェクトを持たない（状態を持たない）から
変数周りでバグが出にくいってメリットがあるんじゃないの？
後は型推論とか可読性とか
javaが読み辛いすぎるだけの気もするけれど
0045デフォルトの名無しさん
2011/11/13(日) 22:11:33.57DB操作とかどうすんの
0046デフォルトの名無しさん
2011/11/13(日) 22:14:19.990047デフォルトの名無しさん
2011/11/13(日) 22:32:08.950048デフォルトの名無しさん
2011/11/13(日) 22:33:33.26君がstatもselectもepollも使ったことがないのは分かった
0049デフォルトの名無しさん
2011/11/13(日) 22:38:06.81もしかしてC関数にポインタを渡せるかを心配してるの？
HaskellやOCamlなら当然できるよ
0050デフォルトの名無しさん
2011/11/13(日) 23:07:00.75http://www.nslabs.jp/haskell-rdbms.rhtml
>>46
キャッシュにしか残ってなかった
http://webcache.googleusercontent.com/search?q=cache:qYwvNDCRuyEJ:ja.doukaku.org/195/nested/+haskell+%26%26+unix%E3%82%B3%E3%83%9E%E3%83%B3%E3%83%89+%26%26+%22tail+-f%22&cd=1&hl=ja&ct=clnk&gl=jp
自分が書いたじゃんけんプログラム見ればわかりやすいと思うけど、３１行より前は関数的、後は手続的に書かれてる
http://codepad.org/9mTpxBrA
一方で、自分が書いた独自自然数（と、それで計算するための関数・演算子は、すごく簡単に書ける
http://codepad.org/0WvSpM7o
手続的な処理が特に苦手と言うわけでもない
手続的な処理は、手続型言語と大差ないってだけ
0051デフォルトの名無しさん
2011/11/14(月) 00:17:41.49てきとーに書いたら手続き型っぽいコードになった
let rec tail_f filename where =
let c_in = open_in filename in
let size = (Unix.fstat (Unix.descr_of_in_channel c_in)).Unix.st_size in
seek_in c_in where;
Stream.iter print_char (Stream.of_channel c_in);
flush stdout;
close_in c_in;
Unix.sleep 1;
tail_f filename size
let tail_f filename = tail_f filename 0
let _ = tail_f "foo.txt"
0052デフォルトの名無しさん
2011/11/14(月) 00:37:33.17せめてfilenameじゃなくてc_inを渡す感じにすりゃいいのに。毎回opencloseする意味ないし、selectで待機できるだろ
0053デフォルトの名無しさん
2011/11/14(月) 00:38:48.61「手続き型言語で関数型言語っぽい記述もできる」の両方が真なら、
本質的な違いは制約の多さだけだな。
0054デフォルトの名無しさん
2011/11/14(月) 00:42:35.64細部が重要だ
破壊的代入のたびに一々 := だの ! だの書く気にならなんよ
0055デフォルトの名無しさん
2011/11/14(月) 00:57:02.17どうしてこんなキーワードがあるの？
http://d.hatena.ne.jp/kazu-yamamoto/20080904/1220495854
より、引用を抜粋（ややこしいｗ）
ちゃぶ台をひっくり返すようなまとめ
「なぜ Haskell は重要か」の一部を翻訳して、この記事のまとめとします。
(関数型言語と)同じ程度とは言えないが、命令を並べる方式でも抽象化していくとこはできる。
命令型言語では、新しいキーワードと標準ライブラリを導入することで抽象化する。
たとえば、多くの命令型言語は、プログラマーがループを実現する仕事から解放されるように、少しずつ動作が異なる複数のキーワードを用意している。
しかし、命令型言語は、命令を並べる方式に基づいているため、そこから完全に逃れることはできない。
命令型言語では、命令の並びに対し、抽象化のレベルを上げる唯一の方法は、さらなるキーワードや標準関数の導入である。
そして、言語はゴチャゴチャになる。
引用を抜粋、終わりｗ
まさに、OOPの事だな。
http://codepad.org/0WvSpM7o
のコードでは、dataと、deriving (Eq,Ord,Show,Read)、あと|（OR演算子だったり、ガードだったり）以外は、言語としてのキーワードは使ってない。（機能としては、パターンマッチも使ってるけど）
そのまま、数学の定義を持ってきてるだけ
手続型言語だと、キーワードはこんなに少なくできない
0056デフォルトの名無しさん
2011/11/14(月) 00:58:09.83まあ、キーワード少ないのは変わらないか
0057デフォルトの名無しさん
2011/11/14(月) 01:02:12.12制御構文がムダに多いのは自然言語もそうだし、別に問題ないだろ。
制御構文が異常に多くなって呪文みたいになった言語なんてPerlくらいしか知らんよ。
0058デフォルトの名無しさん
2011/11/14(月) 01:37:08.54関数型とか関係なくselectじゃ待てんだろ
0059デフォルトの名無しさん
2011/11/14(月) 01:38:17.26そうは言うが、例えばRubyの入門書を読んだだけでは>>55と同じ動作のコードを書けるようにならない。
入門書では、Haskellと同じ抽象度を表現できるキーワードが揃ってない事になる。
が、このコードはプログラミングHaskellという入門書を読破もしてない自分が書いたものだ。
この差は、何だろうな。
一方で、副作用のある処理をしようとすると、HaskellでもHoogleなどで調べる回数が極端に増える。
関数型でも手続型でも、副作用がキーワードを生んでいる。とも言えるのかもしれない。
0060デフォルトの名無しさん
2011/11/14(月) 02:03:44.72int select(int nfds, fd_set *readfds, fd_set *writefds,
fd_set *exceptfds, struct timeval *timeout);
最後の引数が何か分かるか？
0061デフォルトの名無しさん
2011/11/14(月) 02:04:44.790062デフォルトの名無しさん
2011/11/14(月) 02:05:11.690063デフォルトの名無しさん
2011/11/14(月) 02:13:05.99GNU coreutils のsrc/tail.c が実例だ。 俺が書く必要はかけらもないな。
0064デフォルトの名無しさん
2011/11/14(月) 02:54:24.92通常のファイルには役に立たない
（ファイルの終端に達してもファイルディスクリプタは読み取り可能として扱われるから）
0065デフォルトの名無しさん
2011/11/14(月) 11:05:06.23inotifyはLinux限定ですよ
0066デフォルトの名無しさん
2011/11/14(月) 12:45:42.64言わばヤブ医者がいっぱい病院立てている状態。当然頭のわるい奴には
最新の医学なんて理解できないからいつまでも古い治療法を続けている。
そんな状態では高度な医学は流行っていないと観測される。
おれはどんなに少数派でも最新の医学を理解している医者のいる病院にいきたいな。
0067デフォルトの名無しさん
2011/11/14(月) 12:57:52.66名ばかり最新では困ります
0068デフォルトの名無しさん
2011/11/14(月) 13:26:51.812chも書き込むのに資格が要らないんだが、気付いて無かったようだ。
0069デフォルトの名無しさん
2011/11/14(月) 17:17:44.25「OOP？デザインパターン？馬鹿じゃねーの？ｗｗｗ」って雰囲気を
醸し出してるから。
そりゃ関数型言語以外のプログラマには反発されるよね。
0070デフォルトの名無しさん
2011/11/14(月) 17:27:02.04俺英語の感覚が染み付いてるからウープって読んじゃうわー
俺英語の感覚が染み付いてるからー
0071デフォルトの名無しさん
2011/11/14(月) 17:51:18.58ああ、本物のプログラマーは・・・とか、そんな感じのね
本当は、初心者でも割と簡単に複雑なプログラム組めるのにね・・・
初心者がいきなり初日にLength関数作れる言語って、Haskellに限らず、（多分）関数型言語だけだよ
0072デフォルトの名無しさん
2011/11/14(月) 18:16:45.990073デフォルトの名無しさん
2011/11/14(月) 18:22:37.65○○は仕事で普通に使うこれが仕事の標準の道具だ。
○○は豊富なライブラリが揃っていて環境もある。おまけに、つかいては
わんさかいる。
こんなところだろうよ。
0074デフォルトの名無しさん
2011/11/14(月) 18:23:22.850075デフォルトの名無しさん
2011/11/14(月) 18:31:48.61初心者が初日で？
0076デフォルトの名無しさん
2011/11/14(月) 18:40:09.43誤：関数型が広まらないのは、難しいからじゃなくて
「OOP？デザインパターン？馬鹿じゃねーの？ｗｗｗ」って雰囲気を
醸し出してるから。
そりゃ関数型言語以外のプログラマには反発されるよね。
正：ハスケルが広まらないのは、難しいからじゃなくて
「OOP？デザインパターン？馬鹿じゃねーの？ｗｗｗ」って雰囲気を
醸し出してるから。
そりゃハスケラ以外のプログラマには反発されるよね。
0077デフォルトの名無しさん
2011/11/14(月) 19:16:50.67def length(x):
n = 0
while x != []:
n += 1
x = x[1:]
return n
関数型スタイル（？）
def length(x): return reduce(lambda n,_: n + 1, [0] + x)
0078デフォルトの名無しさん
2011/11/14(月) 19:20:20.630079デフォルトの名無しさん
2011/11/14(月) 19:30:21.820080デフォルトの名無しさん
2011/11/14(月) 19:31:59.55size()メソッドが既にあるだろう。 使うだけならなんで自分で実装する必要があるんだよ
0081デフォルトの名無しさん
2011/11/14(月) 19:34:01.28def length(xs): return sum([1 for _ in xs])
カレーの圧勝だな
0082デフォルトの名無しさん
2011/11/14(月) 19:38:40.50そもそも再帰しなくても標準ライブラリでデータのリストを扱う手続き型言語にもってくるから話がおかしくなる。
手続き型言語が持ってる、集合の最もシンプルなインタフェースは
Javaでいう Iterable だろうが、Javaでこれを生で扱う機会がそもそも多くないからな。
0083デフォルトの名無しさん
2011/11/14(月) 19:50:26.83再帰なんて使ってない件
0084デフォルトの名無しさん
2011/11/14(月) 19:52:55.38全要素のスキャンを行ってるのは同じだろうに。
組み込み演算子ならOK、って理屈は、javaなら標準ライブラリにsizeがあるってのとどう違うんだ？
0085デフォルトの名無しさん
2011/11/14(月) 20:14:48.29C#er なので 再帰はなるべく避けようと思います
っていったら何言われるかわからなくて怖い
0086デフォルトの名無しさん
2011/11/14(月) 20:18:48.08lengthはあくまで一例であって、そういう機能を自分で実装する際に
どれだけ楽に書けるかに注目している。
・Javaプログラマ
標準ライブラリにsizeがある、で思考停止。
基本的にライブラリの機能を呼び出す事しか考えないドカタ気質。
0087デフォルトの名無しさん
2011/11/14(月) 20:21:32.700088デフォルトの名無しさん
2011/11/14(月) 20:22:02.96よく分からんけど車輪の再発明が好きなの？
0089デフォルトの名無しさん
2011/11/14(月) 20:22:52.840090デフォルトの名無しさん
2011/11/14(月) 20:23:43.46ライブラリに無い機能があったらどうする？という当然の可能性を考慮できないのがドカタ。
0091デフォルトの名無しさん
2011/11/14(月) 20:29:18.41pyths n = [(x,y,z) | x <- [1..n], y<-[1..n], z<-[1..n], x^2+y^2 == z^2]
0092デフォルトの名無しさん
2011/11/14(月) 20:34:02.47vimとかemacs とかいじってます
0093デフォルトの名無しさん
2011/11/14(月) 20:40:42.37楽しい言語スレだね
書き出しは私
他の言語だとどうなん？って聞いたらScalaやOCaml、Python、Javaが出た
Rubyが真っ先に来ると思ってたけど、結局来なかった
0094デフォルトの名無しさん
2011/11/14(月) 20:42:49.64護身完成してるから
0095デフォルトの名無しさん
2011/11/14(月) 20:50:16.730096デフォルトの名無しさん
2011/11/14(月) 23:50:49.66int[] array = new int[100];
配列というのは当然、領域を確保する時にサイズを指定するわけです。
array.size() というものがなければ、どうやってサイズを取得するのでしょうか。
int getSize(int[] array) {
...
}
この関数を再帰でもループでも、size() を使わずにどうやって書きますか？
教えてください。
0097デフォルトの名無しさん
2011/11/15(火) 00:01:09.69int n = 0;
for (int i: array) n++;
0098デフォルトの名無しさん
2011/11/15(火) 00:01:33.820099デフォルトの名無しさん
2011/11/15(火) 00:02:51.07int n = 0;
for (int i = 0; i < array.size(); i++) n++;
0100デフォルトの名無しさん
2011/11/15(火) 00:07:21.91nil と cons cell がリストというデータ構造を定める基本要素です。
同様に、先頭番地と要素数が配列というデータ構造を定める基本要素です。
0101デフォルトの名無しさん
2011/11/15(火) 00:13:35.34証拠は？使われていますと言われても納得できない
0102デフォルトの名無しさん
2011/11/15(火) 00:14:58.67public boolean hasNext() {
return cursor != size();
}
0103デフォルトの名無しさん
2011/11/15(火) 00:16:37.070104デフォルトの名無しさん
2011/11/15(火) 02:02:35.82関数型言語のは配列でもリストでもなく、要素の「集合」で、要素数は遅延評価になってる部分集合を評価して解決しないと判明しない。
手続き型言語のデータコンテナと比較するのがそもそも間違い。
0105デフォルトの名無しさん
2011/11/15(火) 02:43:21.25横からツッコミを入れるけど、自分の知っている「集合」の定義とは、
・互いの要素は重複しない
・要素間に順序は存在しない
というもの
>>104の言う関数型言語では、(リストではなくて)集合を直に表現できるの？
自分の知っている関数型言語(ML, Haskell)では、集合はライブラリとして実装されている
少なくとも、>>77,81,91 のコードは(集合ではなくて)リストだよ
もしよろしければ、その(集合を扱える)関数型言語の名前を教えてくれ
0106デフォルトの名無しさん
2011/11/15(火) 03:03:42.400107デフォルトの名無しさん
2011/11/15(火) 03:50:05.92このメリットは重複の可否や順序の有無に依存しない(無限リスト, 無限配列, 無限集合など)
0108デフォルトの名無しさん
2011/11/15(火) 05:14:02.76OOPはキーワードを少なくできないって？
HaskellやML系よりSmalltalkのほうがキーワード数はずっと少ないよ。
関数型言語の人達がOOPを腐すときには大抵、OOPへの理解の浅さが見え隠れする。
これって、OOPの人達に迷惑なだけでなく、関数型言語の人達にとってもマイナスだよ。
0109デフォルトの名無しさん
2011/11/15(火) 05:19:01.30> 初心者がいきなり初日にLength関数作れる言語って、Haskellに限らず、（多分）関数型言語だけだよ
そういう態度が反発を食っているということに気付かないのかなあ？
その論理でいうなら、初心者がいきなり初日にDriveACarを書けるのはLOGO系だけだよ。
でもそんなの当たり前だろ。その言語のパラダイムにドンピシャな例題出したって、恥ずかしいだけ。
0110デフォルトの名無しさん
2011/11/15(火) 05:25:51.29効率悪いね。マトモなプログラマならMichener&Bresenham使うでしょ。
関数型言語の人って、O(n^2)のアルゴリズムがあるのにO(n^3)のアルゴリズムを平気で使うの？
0111デフォルトの名無しさん
2011/11/15(火) 05:29:54.34初日でリングバッファの実装できるかな？
Smalltalkでは初日の初心者にも簡単に実装できたぞ。
0112デフォルトの名無しさん
2011/11/15(火) 05:53:56.66恥ずかしながら、マージソートがどういう動きするのか分からなくて、アルゴリズムの本で期待される動きを見てからHaskellで実装できるという低レベルさなんだが・・・
リングバッファと言うのも、同じく知らない。
どういう動きを期待されてるものなの？
0113デフォルトの名無しさん
2011/11/15(火) 05:56:30.97すまんね
マジで初心者なんで、まんま直感的に書いただけ。
効率的なアルゴリズムがあるなら教えて下しあ
0114デフォルトの名無しさん
2011/11/15(火) 06:41:25.48関数型言語の人は1から順に指を折って数えないと、数字すら理解できないんだよ
0115デフォルトの名無しさん
2011/11/15(火) 06:43:32.950116デフォルトの名無しさん
2011/11/15(火) 06:43:55.15○ 大半のコンピュータが
0117デフォルトの名無しさん
2011/11/15(火) 10:16:09.12let pyths n = [(a*a-b*b, 2*a*b, a*a+b*b) | a <- 1--n; b <- 1--(a-1)]
0118デフォルトの名無しさん
2011/11/15(火) 11:29:59.93大きさ不定を表す場合は
size = -1を あてればいいじゃん
全要素対象の演算でループ回数を予測できなきゃ最適化できへんやろ
0119デフォルトの名無しさん
2011/11/15(火) 11:30:34.93ドヤ顔してるところ申し訳ないんだけど、そのアルゴリズムは
ピタゴラス数を求めるアルゴリズムじゃないんだ……
だから x^2 + y^2 = z^2 を満たさない解も出すんだよ……
馬鹿な君には難しい話かもしれないけど……
http://en.wikipedia.org/wiki/Midpoint_circle_algorithm
http://dencha.ojaru.jp/programs_07/pg_graphic_09a1.html
0120デフォルトの名無しさん
2011/11/15(火) 13:00:55.81最初はラフにスケッチを作って、綿密に作品にしていく作業ということを
グレアムが言ってるけど、そうゆう作り方は関数型じゃ普通だもんな。
十年以上も前のことを追いついて騒いでるだけって見えるよ。
0121デフォルトの名無しさん
2011/11/15(火) 15:29:19.66お前、真性のおばか？
乱択アルゴリズムとか使ったことないの？
ダメだこりゃｗ
0122デフォルトの名無しさん
2011/11/15(火) 15:30:48.34> 最初はラフにスケッチを作って、綿密に作品にしていく作業ということを
君はこれをリファクタリングと呼ぶのか。
たぶん、君は一生関数型だけを使っていたほうがいいよ。
たのむから他の言語は使わないでくれ。尻拭いする側の身にもなってみろｗ
0123デフォルトの名無しさん
2011/11/15(火) 18:58:03.23自分は、初心者じゃないプログラマがhaskell覚えれば、すごいものを簡単に作れるんじゃないかと期待してるんだが。。。
0124デフォルトの名無しさん
2011/11/15(火) 19:15:14.11haskell だと簡単？
組み合わせ回路、順序回路、配線それぞれに整数遅延を自由に設計でき
コンストラクタで回路要素を一個10文字程度で定義
ワイヤードORはアリっていう仕様
0125デフォルトの名無しさん
2011/11/15(火) 19:21:28.56>組み合わせ回路、順序回路
「プログラミングHaskell」に演習レベルのがあるね。
0126デフォルトの名無しさん
2011/11/15(火) 19:37:03.66その方法はこれより速いの？
ちょっと書いてみてよ。このくらいなら簡単でしょ？
let rec range x y step = if x > y then [] else x :: range (x + step) y step
let pyths n = [(a*a-b*b, 2*a*b, a*a+b*b) |
a <- range 1 n 1;
b <- range ((a mod 2)+1) (a-1) 2]
let pyths_all n m =
let xs = [(k*x,k*y,k*z) | (x,y,z) <- pyths n; k <- 1--m] in
xs @ [(y,x,z)| (x,y,z) <- xs]
0127デフォルトの名無しさん
2011/11/15(火) 19:45:15.920128デフォルトの名無しさん
2011/11/15(火) 19:48:56.98いや、元コード書いたの俺じゃねーし
で、ちょっとコード書いてみてよ
まさかFizzBuzzレベルのコードが書けないわけでもないんだろ？
0129デフォルトの名無しさん
2011/11/15(火) 19:52:48.960130デフォルトの名無しさん
2011/11/15(火) 19:55:08.72http://en.wikipedia.org/wiki/Midpoint_circle_algorithm
0131デフォルトの名無しさん
2011/11/15(火) 19:57:15.750132デフォルトの名無しさん
2011/11/15(火) 20:02:36.94http://openfmi.net/snippet/detail.php?type=snippet&;id=8
0133デフォルトの名無しさん
2011/11/15(火) 20:41:19.49よく見ろｗ
HaskellじゃなくてOCamlだｗ
0134デフォルトの名無しさん
2011/11/15(火) 21:52:27.59関数はMLしかわかりませんが．．．
回路一個＝関数一個として
遅延がある時点で
任意の関数fは遅延Dfの数だけd * d通りの状態を持つ
ことと等価でないといけないはずですが(3入力ならd*d*d)
純粋な関数型じゃイメージしにくいです
（でないと順序回路や入力の変化に対応できないはずです）
0135デフォルトの名無しさん
2011/11/15(火) 22:13:39.02とっかかりとして、apache module はあるのでしょうか。
mod_haskell は 0.1 だそうですが、これは安定しているでしょうか。
0136デフォルトの名無しさん
2011/11/15(火) 22:25:37.40SMLでよければ、Programing in Standard ML に3ページほどの解説があるよ。
http://www.cs.cmu.edu/~rwh/introsml/
高階関数と無限リスト(シーケンス)を応用した純粋な関数型プログラムで、
副作用は一切使われていない。コードはこんな感じ。
fun RS ff (S : wire, R : wire) =
let
fun X n = nor gate (zip (S, Y))(n)
and Y n = nor gate (zip (X, R))(n)
in
Y
end
0137デフォルトの名無しさん
2011/11/16(水) 02:23:43.520138デフォルトの名無しさん
2011/11/17(木) 17:23:01.92しかし、その割には衆人に受け入れられないし、
強力にアピールするようなものが生まれてこない。
関数型言語は簡単だと主張する人は、嘘を言ってるつもりはないだろう。
しかし、難しいと感じる人が実際に大勢いて、実際に社会で活用される機会を比較すれば
明らかに見劣りしているという現実は受け容れるべきだ。
全部S式で考えるから簡単だという意見も時々耳にするが、これは論外。
人間の自然な思考は手続型であり、それをS式思考に転換ことに成功すれば簡単だろうが
実際にその転換に成功する人は多くない。
だからこそ、広く受け容れられるに至っていないのだから。
0139デフォルトの名無しさん
2011/11/17(木) 17:52:23.56コストがかかるんだから。純真無垢の何もしたことがない人と
手続きの育った人を比べると、素直な髪の毛と
寝ぐせがついた髪の毛をセットするときの違いのようなものさ。
要は、わからないようになった人って多くは寝癖。その寝ぐせが
作るときの中心になってんだから、保守的になるのは普通だよ。
squeak界隈でも、プログラマより子供のほうが理解が速いという事は
あるらしいからね。
難しいと嘆くより、頭が硬くなって（あなたにとって）目新しいもの
を否定する頭の硬さに老化の兆しを感じて嘆いたほうがいいと思うな。
0140デフォルトの名無しさん
2011/11/17(木) 18:13:02.910141デフォルトの名無しさん
2011/11/17(木) 18:50:12.080142デフォルトの名無しさん
2011/11/17(木) 19:24:59.030143デフォルトの名無しさん
2011/11/17(木) 19:30:09.12関数型の良いとこ取りをしつつ、関数型の悪いところを無視してるってこと
良いとこさえ真似れば関数型そのものは用済み
0144デフォルトの名無しさん
2011/11/17(木) 19:55:59.630145デフォルトの名無しさん
2011/11/17(木) 20:16:40.16関数型はそーゆーのを知ってる人のための言語なのか
象牙の塔専用言語ということが証明されたね
0146デフォルトの名無しさん
2011/11/17(木) 21:38:15.43# the next line restarts using tclsh \
exec tclsh "$0" "$@"
proc mylength {x} {
length2 $x 0
}
proc length2 {x c} {
if {$x == {}} {
return $c
} else {
length2 [lreplace $x 0 0] [incr c]
}
}
puts [mylength {1 2 3 4}]
0147146
2011/11/17(木) 21:50:49.11(define (mylength x)
(length2 x 0))
(define (length2 x c)
(if (null? x)
c
(length2 (cdr x) (+ c 1))))
;Schemeで書けばこうなる
;関数型は得意なことならスッキリ書ける
;関数型だから関数型らしいものだけ書けば無敵
;普通のプログラマは簡単に窓を表示できたり、
;テキスト処理に便利な関数や強力な正規表現が用意された言語を使えばいい
0148デフォルトの名無しさん
2011/11/17(木) 21:54:42.44schemeと比べるために末尾再帰にしたのか
0149デフォルトの名無しさん
2011/11/17(木) 22:37:32.77をそなえた手続き言語欲しい
0150デフォルトの名無しさん
2011/11/17(木) 23:04:02.07http://hibari.2ch.net/test/read.cgi/tech/1196257692/
でも技術を磨こうとしたら、勉強したほうがいいよ。
>>149
関数オブジェクトや関数ポインタがあればある程度は高階関数の代用は
できそうなんだけどね。手続きがどれもこれもpascal/cの子供ばかりだから
毛並みの違う手続きも現れても良さそうなのにね。
0151デフォルトの名無しさん
2011/11/17(木) 23:04:38.090152デフォルトの名無しさん
2011/11/17(木) 23:21:28.94一部の読んだ人って大学の輪講とかで使ってんのかな。
0153デフォルトの名無しさん
2011/11/17(木) 23:43:34.950154デフォルトの名無しさん
2011/11/17(木) 23:49:37.01DB構築なんかも初めてのパッケージだとか言いながら、ネットで(勿論英語サイトを)調べながらちゃっちゃと組んでたw
0155デフォルトの名無しさん
2011/11/17(木) 23:58:14.99複数のプログラミング言語を使った後に読んだが、計算モデルの意味が解って、その言語に適したコーティングをやり易くなった。
0156デフォルトの名無しさん
2011/11/18(金) 00:13:05.80なるほど、僕も複数の言語使ってるけど、参考になります。その言語
言語で適した書き方あるもんね。
0157デフォルトの名無しさん
2011/11/18(金) 04:11:37.15スイスの海軍並に役に立つな。
0158デフォルトの名無しさん
2011/11/18(金) 08:59:35.09つ Oz
0159デフォルトの名無しさん
2011/11/18(金) 09:12:59.88適した書き方、もあるが
解決したい問題→どの問題領域か？→どの計算モデルが適しているか？→どの言語が適しているか？
の見極めが早くなるので、読んどいた方が後々楽。
勿論、「最適言語」にも幅があるので、効果/追加リソースが大きいのを選ぶことになる。
0160デフォルトの名無しさん
2011/11/18(金) 13:34:00.62プログラミングは問題解決型の領域だけじゃないぜ？
0161デフォルトの名無しさん
2011/11/18(金) 13:53:38.26世間の仕事の９割以上はそういった、単純な事務処理だから別に問題ではない。
その手の仕事だけやる分には、このスレに書きこむ必要もないだろう。
0162デフォルトの名無しさん
2011/11/18(金) 13:59:30.67一兵卒の意見だな
0163デフォルトの名無しさん
2011/11/18(金) 14:33:56.69問題解決領域を見極めた方法がわかりやすい本だよ
といえば、
問題解決のパラダイムに囚われた考え方。そんなんだけじゃないぜ？
と
どの問題でも大差なく扱える問題は自分でなれた言語でやれば良い話。
>>159のサジェスチョンを全く理解してないってことだと思う。
0164デフォルトの名無しさん
2011/11/18(金) 17:49:54.58問題解決パラダイムに染まりきってるね。
問題解決以外はどの言語でも大して変わらんとか、分かりやすいドカタ思考だ。
0165デフォルトの名無しさん
2011/11/18(金) 18:06:24.27うーん。。。 この人って 問題解決パラダイムのこと書いてたら、
それしか頭にないと思う人だろうか？お気の毒な頭脳をお持ちなのね。
0166デフォルトの名無しさん
2011/11/18(金) 18:07:42.85>>159-161のながれを...
0167デフォルトの名無しさん
2011/11/18(金) 21:41:13.950168デフォルトの名無しさん
2011/11/18(金) 22:12:35.82一連の書き込みを、自分ともう一人だけがしてると思ってんじゃないかな？
0169デフォルトの名無しさん
2011/11/19(土) 04:49:42.630170デフォルトの名無しさん
2011/11/19(土) 10:48:46.88丁寧に書くと>>163は>>161,162の皮肉だって。 なんで流れを読まないんだろう。
0171デフォルトの名無しさん
2011/11/19(土) 10:50:37.86日本語お上手ですねw
0172デフォルトの名無しさん
2011/11/19(土) 12:35:11.07Rubyで書いてみたいな…けどHaskellわかんないんだ
JavaとPythonなら分かるんだけど、どんなコードだったの？
0173デフォルトの名無しさん
2011/11/19(土) 18:15:42.25C#にはnullとかいうのがあるらしい。
クソめんどうくさかった。
0174デフォルトの名無しさん
2011/11/19(土) 20:37:19.00public static List<Integer[]> pyths (int n) {
List<Integer[]> list = new ArrayList<Integer[]>();
for (int x = 1; x <= n; x++) {
for (int y = 1; y <= n; y++) {
for (int z = 1; z <= n; z++) {
if (x * x + y * y == z * z) {
list.add(new Integer[] {x, y, z});
}
}
}
}
return list;
}
0175デフォルトの名無しさん
2011/11/19(土) 23:04:29.52pyths n = [(x,t,z) | x <- [1..n], y <- [1..n], z <- [1..n], x^2 + y^2 == z^2]
0176デフォルトの名無しさん
2011/11/20(日) 00:20:09.18yの代わりにtが混入してる。
0177172
2011/11/20(日) 02:00:52.12おｋ把握
def pyths(n)
(1..n).flat_map{|x|(1..n).flat_map{|y|(1..n).map{|z|[x,y,z]}}}.select{|x,y,z| x**2 + y**2 == z**2 }
end
こんなもんかなあ、Rubyだと。
0178デフォルトの名無しさん
2011/11/20(日) 02:54:00.73def pyths(n)
(1..n)
.to_a
.combination(3)
.select{|x,y,z|x*x+y*y==z*z}
end
0179172
2011/11/20(日) 02:59:41.990181デフォルトの名無しさん
2011/11/20(日) 19:48:27.46結局、何を求めるプログラムなわけ？
関数型言語って人が見て何をやってるのか分からない言語じゃないのか？
0182デフォルトの名無しさん
2011/11/20(日) 19:57:20.800183デフォルトの名無しさん
2011/11/20(日) 20:27:28.370184デフォルトの名無しさん
2011/11/20(日) 20:53:48.340185デフォルトの名無しさん
2011/11/20(日) 21:19:26.49それぞれの熟練プログラマが書いたら効率は
そんなに変わらなくね？
アセンブラとかなら変わるだろうけど
違うとしたら、178が何をやってるのか理解するのに勉強が
必要だというぐらいだろ
0186デフォルトの名無しさん
2011/11/20(日) 23:21:58.23＞ 関数型言語って人が見て何をやってるのか分からない言語じゃないのか？
それは手続き型言語
0187デフォルトの名無しさん
2011/11/21(月) 00:40:13.63関数は 資材を加工する機械に通してる感じ。
0188デフォルトの名無しさん
2011/11/21(月) 01:07:17.13関数型は未だにパッと見でわからないです。
0189デフォルトの名無しさん
2011/11/21(月) 01:08:58.40手続き型は積み重ね
0190デフォルトの名無しさん
2011/11/21(月) 02:42:58.91時間の流れは一方的、開いた系で現実的
関数型言語は量子力学
時間の流れは存在せず、閉じた系で理論的
0191デフォルトの名無しさん
2011/11/21(月) 03:23:52.64関数型は整理
0192デフォルトの名無しさん
2011/11/21(月) 07:42:39.76関数型は羅列
0193デフォルトの名無しさん
2011/11/21(月) 08:02:53.73元ネタが見つからないのでわからないのですが、int しか使わない縛りとかあったのでしょうか。
List<Integer[]> list = new ArrayList<Integer[]>();
for (int x = 1; x <= 100; x++)
for (int y = 1; y <= 100; y++) {
double z = Math.sqrt(x * x + y * y);
if (z <= 100 && (int) z == z) list.add(new Integer[] { x, y, (int) z });
}
0194デフォルトの名無しさん
2011/11/21(月) 08:26:01.80それ、間違い。浮動小数点数の扱いに慣れてない？
0195デフォルトの名無しさん
2011/11/21(月) 08:30:13.710196デフォルトの名無しさん
2011/11/21(月) 08:36:50.090197デフォルトの名無しさん
2011/11/21(月) 08:46:16.00Prologには既にブームの兆しがあるし、関数型の周辺に
猛烈な勢いで関心が拡がって、渉猟されてる感がある。
0198デフォルトの名無しさん
2011/11/21(月) 08:48:26.52Erlang人気は意外だった。
0200デフォルトの名無しさん
2011/11/21(月) 09:32:35.99理解するのに勉強が必要って…どれも必要だろう
0201デフォルトの名無しさん
2011/11/21(月) 10:25:56.50まんま、ピタゴラス数を求める関数でんがな
パッと見で分かってるじゃん
0202デフォルトの名無しさん
2011/11/22(火) 02:11:23.03当然関数型でも解りやすいのと解りにくいのがある。
Perlの変態コードだってパッと見わからんでしょ。
それに手続き型に何年親しんでから、関数型をどれくらいやったのか？
単なる慣れの要素もある
0203デフォルトの名無しさん
2011/11/22(火) 05:13:59.50その勉強量が違うだろ
多くの人が知らない概念を使ってる場合、
その多くの人は新たに勉強する必要がある
知ってる場合は勉強する必要はない
0204デフォルトの名無しさん
2011/11/22(火) 12:55:21.67関数型でわかりにくいというのはどこを指してるのか？
(reduce .. (filter .. (map .. (map ....
もなぁーど ...
基本は再帰を乗り越えなアカンっていうのはある。関数型で
バッドノウハウだと思ってるのは、末尾再帰くらいかも。
0205デフォルトの名無しさん
2011/11/22(火) 15:35:23.14カッコも再帰も最小限ですむよ
0206デフォルトの名無しさん
2011/11/22(火) 16:09:47.64ハスケルだったらね。ポイントフリーのほうが楽なこと多いよね。
あれで必要以上に複雑なことしなければ、誰だって使えるようになるでしょうよ。
0207デフォルトの名無しさん
2011/11/22(火) 17:12:14.500208デフォルトの名無しさん
2011/11/22(火) 19:41:54.440209デフォルトの名無しさん
2011/11/22(火) 20:10:56.45６４ビットOSが普及すれば、スクリプトより楽な巻子型言語が普及・・・して欲しいなぁ…
関数型言語って、基本的に簡単だけど、要求スペックも無限のメモリ、無限のクロックなんだよね・・・
通常アプリでメモリやクロック、スレッドを気にしなくてよくなったら、普及すると思うんだ
0210デフォルトの名無しさん
2011/11/22(火) 20:11:45.59o関数
0211デフォルトの名無しさん
2011/11/22(火) 20:20:11.59それを解消するためのアルゴリズｌムであり、末尾再帰なんだと思う
0212デフォルトの名無しさん
2011/11/22(火) 20:30:08.07現実を無視しちゃいかんよ
0213デフォルトの名無しさん
2011/11/22(火) 21:00:40.610214デフォルトの名無しさん
2011/11/22(火) 21:15:40.50人は手続型で思考する。
だから、先入観の無い子供でも
関数型は手続型より難しいと感じる。
S式や再帰を強調し、ほら簡単だろと言うから
関数型は嫌われてメジャーになれない。
0215デフォルトの名無しさん
2011/11/22(火) 21:37:40.15一方数学というのは思考を簡約できる道具なわけで
手続きに関数の表現を盛り込んでいくのがいいと思う
0216デフォルトの名無しさん
2011/11/22(火) 21:41:57.490217デフォルトの名無しさん
2011/11/22(火) 21:48:11.680218デフォルトの名無しさん
2011/11/22(火) 21:57:05.12中？高？で関数を教えたほうがいいかもしれん
0219デフォルトの名無しさん
2011/11/22(火) 21:59:19.130220デフォルトの名無しさん
2011/11/22(火) 23:01:53.480221デフォルトの名無しさん
2011/11/22(火) 23:09:42.98UMLで設計するんじゃなくて、DFDで設計したらいいんだよね？
0222デフォルトの名無しさん
2011/11/22(火) 23:23:19.230223デフォルトの名無しさん
2011/11/22(火) 23:30:49.75オフサイドルールの面も大きいと思う
0224デフォルトの名無しさん
2011/11/22(火) 23:35:06.030225デフォルトの名無しさん
2011/11/22(火) 23:51:03.48MLをディスってるんですか？
0226デフォルトの名無しさん
2011/11/22(火) 23:54:47.57ポイントフリーは読みにくい型エラーの温床になるから
あんまりやらないようにしてるんだけど
0227デフォルトの名無しさん
2011/11/22(火) 23:55:21.01<+>とか.|.とか>>=とか
0228デフォルトの名無しさん
2011/11/23(水) 00:24:00.14(.).(.)
0229デフォルトの名無しさん
2011/11/23(水) 03:27:23.65そうそう、だいたい奇天烈演算子大会になってるよね。
で、演算子の字面見ても殆どイメージ湧かないし。
いや、別に二項演算子が嫌いなわけじゃないけど、セルフドキュメント性が低すぎる。
0230デフォルトの名無しさん
2011/11/23(水) 05:48:44.62でも、なぜか
x = x+1
等しくないよ？という入門者の意見の多いこと多いこと…
この段階では、関数型言語の方が自然らしい
0231デフォルトの名無しさん
2011/11/23(水) 05:59:42.50都市伝説なのではないか。
0232デフォルトの名無しさん
2011/11/23(水) 06:46:58.39Haskell使いの目指すところが手続的な個所も関数的に書こうとする事だからね…
そこが、ちょっと珠に傷って気はする
手続的に書く方が自然なところは手続的に書いて、関数的に書く方が自然なところは関数的に書けば良いのに、とは思うよ
関数的に書ける所では、デッドロックとか考える必要なくて、簡単に並列化できるし、手続的に書く方が自然なところは普通に手続的に書けるんだしさ
0233デフォルトの名無しさん
2011/11/23(水) 06:51:12.91でも「三角形のこの頂点のx座標y座標は動かせないよ」と言っても
どうして？と言われるぞ…
0234デフォルトの名無しさん
2011/11/23(水) 06:52:20.60居た
ｘとｙの値を交換するってので、
temp = x
x=y
y=temp
ってするじゃない？
何でtempが必要なのか。いくら説明しても分からない奴がいた。
メモリの仕組みも習ってるはずなのに、理解できないらしい。
多分、メモリの仕組みそのものが理解できてない。
関数型言語の場合
タプルで受け取って、そのまま交換すればいい
swap (x,y) = (y,x)
これなら、そういうレベルの人でも分かるだろう。
・・・と、思いたいｗ
0235デフォルトの名無しさん
2011/11/23(水) 06:54:08.09動かす（新しい座標を返す）関数作ればいいだけだろ
0236デフォルトの名無しさん
2011/11/23(水) 06:55:17.51それが日本語で普通に考えた時のやり方と全然違っていても
あくまでハスケルっぽいほうが自然なんだよ。
同じように、ハスケラが言う関数プログラミング的というのは
ハスケルっぽく書いてあるということで、MLとかLISPとかで
スマートに書いてあっても、それは関数プログラミング的じゃないんだよ。
0237デフォルトの名無しさん
2011/11/23(水) 06:56:36.72手続き型でもswapぐらい普通に実装できるが。
def swap(x,y):
return y, x
0238デフォルトの名無しさん
2011/11/23(水) 06:58:55.33そんなので騙せるのは大人だけだよ。
新しい三角形をつくったって、元の三角形は動いてない。
0239デフォルトの名無しさん
2011/11/23(水) 07:25:25.55日本語とか以前として、算数/数学っぽく書けるって感じかな
数学に国境はないから、日本とか外国とか関係ない
0240デフォルトの名無しさん
2011/11/23(水) 07:28:40.77それを教えてない段階で疑問持たれる訳で
関数型言語は数学ベースだから、そう言う疑問を持たれにくいし、疑問への回答も論理的
(こう言う機能が有るよ!!ではない)
0241デフォルトの名無しさん
2011/11/23(水) 07:30:44.56それが、後から元の三角形が必要になった時の利点
(手続き型だと新しい三角形を作る前に保存してないといけない)
0242デフォルトの名無しさん
2011/11/23(水) 07:44:58.98教えてない？
あんたが知らないだけでしょｗ
関数型の人ってどこまでジコチューよｗｗ
0243デフォルトの名無しさん
2011/11/23(水) 07:46:05.59それじゃ子供どころか大人も騙せないぞｗ
それで説明できたつもりでいるようだから、関数型はダメなんだよ
0244デフォルトの名無しさん
2011/11/23(水) 07:48:17.33叩く方も含めてほぼ100%関数型言語ユーザと思われ。
関数型言語の「メリット」は説明されなくても分かってるのでは。
Haskellでグラフのデータ構造を定義する上手い方法はあるのだろうか。
class Node {
Set<Node> edges;
...
};
普通のオブ指手続き言語ならこれだけの話だが。
0245デフォルトの名無しさん
2011/11/23(水) 07:48:25.78ハスケルじゃ関数名や変数名はつけないのか？
mapとかfoldとかfilterとかは世界共通の言葉なのか？
ハスケラのジコチューっぷりは世界共通なのか？
0246デフォルトの名無しさん
2011/11/23(水) 08:21:07.82俺はハスケラじゃないんで分からんけど、それってHaskellじゃ難しいの？
データ構造の定義に手続き型とか関係なさそうだが……
0247デフォルトの名無しさん
2011/11/23(水) 08:35:38.33edges への破壊的代入が出来ないとしたら？
0248デフォルトの名無しさん
2011/11/23(水) 08:37:53.790249デフォルトの名無しさん
2011/11/23(水) 09:52:48.08デフォルトじゃできないだけで。
0250デフォルトの名無しさん
2011/11/23(水) 11:07:12.02>>230
っ PASCAL
っ COBOL
他にも手続き型で代入演算子が = でない言語はあったと思うぞ
>>234
それも最近の言語は x,y = y,x と書けたりするからなあ
0251デフォルトの名無しさん
2011/11/23(水) 11:46:48.72分かるまで、ハノイの塔を実際にやらせてみるとか、どうだろうね。
0252デフォルトの名無しさん
2011/11/23(水) 11:47:34.34y = x
x = y
と書いたらもちろん意図した結果にはならないので、なぜこう書いたらダメなのか
というのはどのみち理解しないといけないような
変数と値のセマンティックスは値型／参照型云々でも違ってくるので
初心者にとってはそう簡単じゃないのでは
エイリアシングからくる初心者にとっては不可思議な問題を
とりあえず考えなくともよいという意味では、参照透明だと確かにわかりやすいのかも
0253デフォルトの名無しさん
2011/11/23(水) 13:05:31.01y = x
x = y
と書くのは例えばどんなとき？
僕分からないんで教えて下さい。
0254デフォルトの名無しさん
2011/11/23(水) 13:12:03.820255デフォルトの名無しさん
2011/11/23(水) 13:13:14.580256デフォルトの名無しさん
2011/11/23(水) 13:13:58.34え、そこから英語で躓くのかよ
変数や関数に対した英単語でないだろ
0257デフォルトの名無しさん
2011/11/23(水) 13:16:56.56関数を書くのは関数型言語の方が楽
手続きを書くのは手続き型言語の方が楽
ってだけじゃねーの？
0258デフォルトの名無しさん
2011/11/23(水) 13:27:23.12たかが map のために functor が必要になるのと
たかが代入のために monad が必要になるのと
究極の選択。マシな方を選べ。ってだけじゃね？
0259デフォルトの名無しさん
2011/11/23(水) 13:29:13.690260デフォルトの名無しさん
2011/11/23(水) 13:29:44.44参照透明性は要らん。言語に強制されるのは邪魔なだけ。
0261デフォルトの名無しさん
2011/11/23(水) 13:30:55.700262デフォルトの名無しさん
2011/11/23(水) 13:32:17.070263デフォルトの名無しさん
2011/11/23(水) 13:32:31.160264デフォルトの名無しさん
2011/11/23(水) 13:33:26.590265デフォルトの名無しさん
2011/11/23(水) 13:33:38.460266デフォルトの名無しさん
2011/11/23(水) 13:39:17.710267デフォルトの名無しさん
2011/11/23(水) 13:40:57.320268デフォルトの名無しさん
2011/11/23(水) 13:41:25.890269デフォルトの名無しさん
2011/11/23(水) 13:43:40.500270デフォルトの名無しさん
2011/11/23(水) 13:49:24.410271デフォルトの名無しさん
2011/11/23(水) 13:56:39.61もうこのスレもおしまいかも。もともとフレーマー用だから
いいっか。
0272デフォルトの名無しさん
2011/11/23(水) 13:57:50.700273デフォルトの名無しさん
2011/11/23(水) 13:58:58.14参照透明性って、プログラマの責任で保証するというのでも
大した手間じゃないような気がするんだよな。
言語として副作用を持たないということは本当にメリットなのか？
デメリットの方が大きい気がする。
純粋だってのは認めるが、それは数学的な美学の問題。
プログラマの利益にならなきゃプログラミング言語としては使えないだろ。
0274デフォルトの名無しさん
2011/11/23(水) 13:59:04.58元々質（）の低いスレで何言ってんだか
いいっか。
0275デフォルトの名無しさん
2011/11/23(水) 13:59:32.66参照透明性って、プログラマの責任で保証するというのでも
大した手間じゃないような気がするんだよな。
言語として副作用を持たないということは本当にメリットなのか？
デメリットの方が大きい気がする。
純粋だってのは認めるが、それは数学的な美学の問題。
プログラマの利益にならなきゃプログラミング言語としては使えないだろ。
0276デフォルトの名無しさん
2011/11/23(水) 14:00:33.800277デフォルトの名無しさん
2011/11/23(水) 14:38:01.16最適化をしようと思ったら、末尾再帰でないものでも無理にでも末尾再帰
のフォームに変換しないといけないけど、それは言語の文法上の話じゃなくて
コンパイラやインタプリタより下層の制約から来てる。そこからバッドノウハウ
臭さがある。そんな制約なしにどんな再帰でも最適化されるようなものだったら
末尾再帰にこだわらなくてもいいだろうしね。
0278デフォルトの名無しさん
2011/11/23(水) 14:46:48.58ほとんどの人は相手にしないんだと思う。やっぱり情動の制御
できるように前頭葉を鍛えなきゃ。頑張ってリハビリしたほうがいいよ。
0279デフォルトの名無しさん
2011/11/23(水) 14:49:42.96どうしよう、これ．．．
0280デフォルトの名無しさん
2011/11/23(水) 15:16:18.58逆に考えるんだ。
そもそも call を jmp に置き換えるのが末尾再帰除去であり、
末尾再帰除去の中で call が自分自身を呼び出している場合がループなのだ。
つまり、手続き型言語の連中が当たり前のように使っている
ループという制御構造それ自体がバッドノウハウなのだ。
彼らはバッドノウハウだと思っていないようだが。
0281デフォルトの名無しさん
2011/11/23(水) 15:20:47.900282デフォルトの名無しさん
2011/11/23(水) 15:22:29.65ーーーー壁ーーーー
プログラマが末尾再帰に書けば除去してくれるのが関数型言語
ーーーー壁ーーーー
末尾再帰を除去できない変わりに破壊的代入とループ構文を導入して
プログラマが手作業で末尾再帰除去できるようにしたのが手続き型言語
0283デフォルトの名無しさん
2011/11/23(水) 15:28:14.170284デフォルトの名無しさん
2011/11/23(水) 15:33:50.460285デフォルトの名無しさん
2011/11/23(水) 15:36:18.410286デフォルトの名無しさん
2011/11/23(水) 16:03:18.11おれも息を吐くが如く、末尾再帰にはお世話になってるけど、この話と
手続きのループとは話は別かな。
手続きのループに慣れ過ぎると、悪癖プログラマっぽいものしかいなくなる。
少なくともそれで関数をやるとね。せいぜいiterateにしてくれよと言いたく
なるけど、副作用の世界が絡んでるから一対一対応じゃない部分があるよね。
見た目も下品なループなんて抹殺すればいいが。藁
0287デフォルトの名無しさん
2011/11/23(水) 16:05:25.18Haskell より速いし
0288デフォルトの名無しさん
2011/11/23(水) 16:25:00.920289デフォルトの名無しさん
2011/11/23(水) 16:32:58.550290デフォルトの名無しさん
2011/11/23(水) 17:16:32.58速い？
ghciは確かに遅いが、ghcでコンパイルした後だとLLじゃ話にならん速さだぞ？
0291デフォルトの名無しさん
2011/11/23(水) 17:23:31.95初心者ポンと出されて
一日でどこまで作れるようになるかコンテストがあったら
手続きのほうが強そう
0292デフォルトの名無しさん
2011/11/23(水) 17:28:20.56全くのプログラミング処女を捕まえて、教える場合と、クセのついたプログラマ
が学ぶ場合と違ってくるからな。変なクセがある分関数童貞の手続きプログラマ
のほうが、プログラミング処女より物分りが悪いってことはよくあるみたいだが。
0293デフォルトの名無しさん
2011/11/23(水) 17:32:52.58具体例も無しに言われても。。。
0294デフォルトの名無しさん
2011/11/23(水) 17:36:07.39例えば？
0295デフォルトの名無しさん
2011/11/23(水) 17:41:50.82純粋指向の人達には軽く見られるけど、習得はし易い部類かと
0296デフォルトの名無しさん
2011/11/23(水) 17:44:26.35言語レベルでは知らんぷりしてるだけじゃん。
「臭いものに蓋」で、副作用による依存性の問題に
正面から向き合ってないよね。
0297デフォルトの名無しさん
2011/11/23(水) 17:47:27.76「うわ、何アイツ、キモ・・・」
「ｹﾝﾛﾝ!ｹﾝﾛﾝ!」
「なんか臭いし・・・関わらないようにしようぜ」「そうね・・・」
0298デフォルトの名無しさん
2011/11/23(水) 17:49:00.65ハスケルで有名なプログラムって、グラディウスとかパールとか
既存のプログラムの書き直しばっかりじゃん
0299デフォルトの名無しさん
2011/11/23(水) 17:52:27.80「またあんなこと言ってるけど」
「いいよ、あいつにはリストの長さを求めるプログラム書かせとくからｗｗｗ」
「そりゃ大仕事だなｗｗｗｗ」
0300デフォルトの名無しさん
2011/11/23(水) 17:56:20.95教える経験のある人たちからはそうゆう話は時々出てくるくらい
だけど、違うと思うならそれでもいいよ。ずぶの素人より知ってるほうが
難しく感じるっていう話は、多少ショッキングだろうから。
しかしながら、この手のパターンはよくある話なんだよね。
0301デフォルトの名無しさん
2011/11/23(水) 17:56:54.90例えば？
0302デフォルトの名無しさん
2011/11/23(水) 17:58:08.890303デフォルトの名無しさん
2011/11/23(水) 17:59:22.730304デフォルトの名無しさん
2011/11/23(水) 18:00:14.49それはプログラミングではなく計算理論も合わせて教える場合だろう。
0305デフォルトの名無しさん
2011/11/23(水) 18:01:49.68それはどんな言語、どんなパラダイムでもそうなの。
ハスケルだけ特別、関数型だからみたいな事を言うから小馬鹿にされるの。
0306デフォルトの名無しさん
2011/11/23(水) 18:02:06.25なまじっか知ってるために、自分の頭にある今までの学習パターンに当てはめる
が実は、当てはめたら沼に入るパターンも多いからさ。
プログラミングで変なクセがついたら矯正しづらいってのもよく知られてる
けどな。だいたい学習の王道は、副作用もできる関数型から始めるほうが、
いいからね。手続きから始めると、データ構造まで到達して使えるようになるのに
負担が大きいしね。
0307デフォルトの名無しさん
2011/11/23(水) 18:02:23.560308デフォルトの名無しさん
2011/11/23(水) 18:02:31.42× 最適化をしようと思ったら、末尾再帰
○ 実用的な大きさのデータを扱おうとしたら、要末尾再帰
0309デフォルトの名無しさん
2011/11/23(水) 18:03:22.48誰がハスケルを取り上げてそんなことを書いた？
さすがに、これ見た時アホちゃう？と思ったよ。
0310デフォルトの名無しさん
2011/11/23(水) 18:03:50.40少なくとも数学的帰納法をすんなり理解できるところまで教育を受けてないと無理でしょ。
0311デフォルトの名無しさん
2011/11/23(水) 18:03:57.09さっきからその特徴的な改行はなんなの？
0312デフォルトの名無しさん
2011/11/23(水) 18:04:45.130313デフォルトの名無しさん
2011/11/23(水) 18:05:45.07高校生レベルならOKってことだね。それがわからんというのは
プログラミングするにしても、資材を並べるだけしかできないと思うよ。
論理的に考える素養がなさそうだからね。
0314デフォルトの名無しさん
2011/11/23(水) 18:07:37.11いや、アホはおまえｗ
「初心者のほうが、かえって理解が早いことがある」なんてことは
構造化プログラミングの時にも、
アメリカの初等教育でLOGOが流行した時にも、
オブジェクト指向が普及しはじめた時にも、
同じことが言われていた。
関数型だからとか、もうアフォとしか言いようがない。
0315デフォルトの名無しさん
2011/11/23(水) 18:07:58.42いや、普通にパソコン好きな少年なら、
高校生レベルになる前にとっくに「クセ」がついてるでしょ。という意味です。
0316デフォルトの名無しさん
2011/11/23(水) 18:08:35.80完全にカルト信者だｗ
0317デフォルトの名無しさん
2011/11/23(水) 18:08:42.76そういう気持ち悪い言い回しするから友達いなくなるんだよ。
0318デフォルトの名無しさん
2011/11/23(水) 18:09:21.240319デフォルトの名無しさん
2011/11/23(水) 18:10:35.32頭悪いな。違ったものをすでにみにつけてるものよりか何もないほうが
吸収が良いことがあるという事から、ずぶの素人とすでにやってる人が
学ぶのでは違う。と書いてるんだが。いい加減、わけのわからん早とちり
で勝手に都合よく解釈するのは。。。馬鹿な奴にアホと言われても
屁とも思わんよ。鼻で笑ってるだけだから。
くだらんやつ相手にするのも暇な時間だけにしなきゃ。
0320デフォルトの名無しさん
2011/11/23(水) 18:12:30.16その仮定が適切なのか、ちょっとわからんし、一般的だとは思えないよね。
共通のコンセンサスがないというのだけはわかったが。
0321デフォルトの名無しさん
2011/11/23(水) 18:12:37.44ご本人達は本気で信じているのだということを思うと可哀想でならない。
カルトって怖いね。
0322デフォルトの名無しさん
2011/11/23(水) 18:12:50.12中途半端に頭いいからはてなあたりででかい口叩いちゃう系の。
0323デフォルトの名無しさん
2011/11/23(水) 18:12:55.95だから、一般論としてそういう話があるのは一向に構わないけど、
それと「素人は関数型の方がよい」という主張が繋がらないということでしょ
0324デフォルトの名無しさん
2011/11/23(水) 18:14:54.310325デフォルトの名無しさん
2011/11/23(水) 18:15:48.71作ってからだな。
0326デフォルトの名無しさん
2011/11/23(水) 18:18:18.61そ。関数型のところに「構造化言語」「LOGO」「LISP」「Java」どれでも当てはまる。
もっと一般化すると、
空手とかで他の道場で変なクセつけた中学生よりも、
はじめて空手を習う小学生のほうが教えやすい。
あたりまえだってｗ
0327デフォルトの名無しさん
2011/11/23(水) 18:18:30.480328デフォルトの名無しさん
2011/11/23(水) 18:18:59.53逆に、整数型が当たり前のように多倍長な言語で入ってしまうと、
そういう事を気にしなければいけない言語に慣れるのは大変だと思う。
手続き型言語の中で言えば、ポインタやメモリ管理なども同じ問題。
Java→C と C→Java のどちらが「二番目の言語」を覚える障壁が低いのか。
関数型言語の方が、手続き型言語よりも高水準だね。より抽象度が高いという意味で。
そこはそうだと思う。
それ以外の話、使う人のレベルがどうとか、初学者にとってどうとか、そんなのは議論の余地大有り。
0329デフォルトの名無しさん
2011/11/23(水) 18:19:18.48うるさい氏ね
0330デフォルトの名無しさん
2011/11/23(水) 18:20:06.65そうだな！君は正しいよ！！
0331デフォルトの名無しさん
2011/11/23(水) 18:22:03.03これなら小学生でもわかる。
「10の階乗とはnの階乗ならn-1の階乗で、1の階乗や0の階乗なら1なんだよ。」
これを小学生が聞いたら「ﾊｧ?」ってなる。
0332デフォルトの名無しさん
2011/11/23(水) 18:22:27.82知ってたら絶対「なんでこんな面倒なこと覚える必要があるの？」
って気になって習得に集中できない
メリットを聞いても「参照透過性がむにゃむにゃ……」みたいな説明しかしてくれないし
0333331
2011/11/23(水) 18:23:18.61「10の階乗とはnの階乗ならn-1の階乗にnかけたもので、1の階乗や0の階乗なら1なんだよ。」
0334デフォルトの名無しさん
2011/11/23(水) 18:24:14.28手続き型を知らないひとにはIO Monadをどう説明するの？
結局は参照透明性ムニャムニャになるでしょｗ
だって、それが本当の理由なんだから
0335デフォルトの名無しさん
2011/11/23(水) 18:25:02.450336デフォルトの名無しさん
2011/11/23(水) 18:25:36.09うるさい氏ね
0337デフォルトの名無しさん
2011/11/23(水) 18:25:46.80そう。それ実はかなり重要なところだと思う。
手続き型言語でも closure なんかは当たり前に取り込まれるけど、
map や filter といったところは、手続き型言語専門の人にとっても簡単。
fold をスッと納得できるかどうか。そこが壁だね。
0338デフォルトの名無しさん
2011/11/23(水) 18:28:03.15知らなかったら疑問に思わないから、「面倒だな、でもそういうもんなのかな」
って学習するんじゃないかな
可哀想だけど
0339デフォルトの名無しさん
2011/11/23(水) 18:28:25.24まさかHaskellさんですか？
0340デフォルトの名無しさん
2011/11/23(水) 18:28:59.35> 関数型言語の方が、手続き型言語よりも高水準だね。より抽象度が高いという意味で。
ぷ
お前が言う抽象度ってのはラムダ抽象だけだろｗ
世の中には他にも色々な抽象があるんだよ。
例えば、関数型言語は高階述語論理よりも抽象度が高いのか？
0341デフォルトの名無しさん
2011/11/23(水) 18:32:01.99機械語としての0,1ビット列から、より遠くに離れている方が抽象度が高いという意味です。
0342デフォルトの名無しさん
2011/11/23(水) 18:33:39.700343デフォルトの名無しさん
2011/11/23(水) 18:34:32.320344デフォルトの名無しさん
2011/11/23(水) 18:35:03.53そもそもIOモナドの導入は、参照透明性を守りながら入出力をしたいという
言語の表層の問題を解決するために導入されたものであって、
「副作用による依存性」とか難しいことを解決しようとしてる訳じゃないから、その批判は的外れ
0345デフォルトの名無しさん
2011/11/23(水) 18:35:05.73はい
0346デフォルトの名無しさん
2011/11/23(水) 18:35:50.85氏ね
0347デフォルトの名無しさん
2011/11/23(水) 18:36:52.020348デフォルトの名無しさん
2011/11/23(水) 18:39:28.71これでxはintとかに型推論して参照透過扱い、
というのはどう？
0349デフォルトの名無しさん
2011/11/23(水) 18:42:34.800350デフォルトの名無しさん
2011/11/23(水) 18:43:36.250351デフォルトの名無しさん
2011/11/23(水) 18:44:11.05が学ぶ場合と違ってくるからな。変なクセがある分関数童貞の手続きプログラマ
のほうが、プログラミング処女より物分りが悪いってことはよくあるみたいだが。
0352デフォルトの名無しさん
2011/11/23(水) 18:46:02.31不勉強な君たちには理解できないと思うけど。
0353デフォルトの名無しさん
2011/11/23(水) 18:48:16.61勝手にHaskell厨と騒いでるのを見てて、ここは、アホの楽園なのかと・・・。
Haskellは純粋だけにOcamlとかと比べても堅物な言語だから、
その点が容易かどうか。最も、難しいところを置いといても
プログラミングはできるけどね。
OOPとの対比になるけど、Visitorパターンが理解できたら、
無名関数でやってることと同じようなことがOOP言語ならできるけど
OOPでVisitorパターンの位置づけはどうなのかだよ。逆に、
関数型やってる奴のほうが、使えるパターンかもしれんが。
0354デフォルトの名無しさん
2011/11/23(水) 18:52:30.45勝手にHaskell厨と騒いでるのを見てて、ここは、アホの楽園なのかと・・・。
Haskellは純粋だけにOcamlとかと比べても堅物な言語だから、
その点が容易かどうか。最も、難しいところを置いといても
プログラミングはできるけどね。
OOPとの対比になるけど、Visitorパターンが理解できたら、
無名関数でやってることと同じようなことがOOP言語ならできるけど
OOPでVisitorパターンの位置づけはどうなのかだよ。逆に、
関数型やってる奴のほうが、使えるパターンかもしれんが。
0355デフォルトの名無しさん
2011/11/23(水) 18:53:18.61勝手にHaskell厨と騒いでるのを見てて、ここは、アホの楽園なのかと・・・。
Haskellは純粋だけにOcamlとかと比べても堅物な言語だから、
その点が容易かどうか。最も、難しいところを置いといても
プログラミングはできるけどね。
OOPとの対比になるけど、Visitorパターンが理解できたら、
無名関数でやってることと同じようなことがOOP言語ならできるけど
OOPでVisitorパターンの位置づけはどうなのかだよ。逆に、
関数型やってる奴のほうが、使えるパターンかもしれんが。
0356デフォルトの名無しさん
2011/11/23(水) 18:53:34.55勝手にHaskell厨と騒いでるのを見てて、ここは、アホの楽園なのかと・・・。
Haskellは純粋だけにOcamlとかと比べても堅物な言語だから、
その点が容易かどうか。最も、難しいところを置いといても
プログラミングはできるけどね。
OOPとの対比になるけど、Visitorパターンが理解できたら、
無名関数でやってることと同じようなことがOOP言語ならできるけど
OOPでVisitorパターンの位置づけはどうなのかだよ。逆に、
関数型やってる奴のほうが、使えるパターンかもしれんが。
0357デフォルトの名無しさん
2011/11/23(水) 18:54:13.040358デフォルトの名無しさん
2011/11/23(水) 18:55:56.02逆はポール・グレアム始め多く関数型言語覚えてると手続き型言語でも良いプログラマになると聞くが、どっちが本当なんだぜ？
0359デフォルトの名無しさん
2011/11/23(水) 18:57:06.36o多くの優秀なプログラマが
0360デフォルトの名無しさん
2011/11/23(水) 18:57:13.35勝手にHaskell厨と騒いでるのを見てて、ここは、アホの楽園なのかと・・・。
Haskellは純粋だけにOcamlとかと比べても堅物な言語だから、
その点が容易かどうか。最も、難しいところを置いといても
プログラミングはできるけどね。
OOPとの対比になるけど、Visitorパターンが理解できたら、
無名関数でやってることと同じようなことがOOP言語ならできるけど
OOPでVisitorパターンの位置づけはどうなのかだよ。逆に、
関数型やってる奴のほうが、使えるパターンかもしれんが。
0361デフォルトの名無しさん
2011/11/23(水) 18:57:22.09勝手にHaskell厨と騒いでるのを見てて、ここは、アホの楽園なのかと・・・。
Haskellは純粋だけにOcamlとかと比べても堅物な言語だから、
その点が容易かどうか。最も、難しいところを置いといても
プログラミングはできるけどね。
OOPとの対比になるけど、Visitorパターンが理解できたら、
無名関数でやってることと同じようなことがOOP言語ならできるけど
OOPでVisitorパターンの位置づけはどうなのかだよ。逆に、
関数型やってる奴のほうが、使えるパターンかもしれんが。
0362デフォルトの名無しさん
2011/11/23(水) 18:57:48.58勝手にHaskell厨と騒いでるのを見てて、ここは、アホの楽園なのかと・・・。
Haskellは純粋だけにOcamlとかと比べても堅物な言語だから、
その点が容易かどうか。最も、難しいところを置いといても
プログラミングはできるけどね。
OOPとの対比になるけど、Visitorパターンが理解できたら、
無名関数でやってることと同じようなことがOOP言語ならできるけど
OOPでVisitorパターンの位置づけはどうなのかだよ。逆に、
関数型やってる奴のほうが、使えるパターンかもしれんが。
0363デフォルトの名無しさん
2011/11/23(水) 18:58:10.25勝手にHaskell厨と騒いでるのを見てて、ここは、アホの楽園なのかと・・・。
Haskellは純粋だけにOcamlとかと比べても堅物な言語だから、
その点が容易かどうか。最も、難しいところを置いといても
プログラミングはできるけどね。
OOPとの対比になるけど、Visitorパターンが理解できたら、
無名関数でやってることと同じようなことがOOP言語ならできるけど
OOPでVisitorパターンの位置づけはどうなのかだよ。逆に、
関数型やってる奴のほうが、使えるパターンかもしれんが。
0364デフォルトの名無しさん
2011/11/23(水) 19:00:52.26勝手にHaskell厨と騒いでるのを見てて、ここは、アホの楽園なのかと・・・。
Haskellは純粋だけにOcamlとかと比べても堅物な言語だから、
その点が容易かどうか。最も、難しいところを置いといても
プログラミングはできるけどね。
OOPとの対比になるけど、Visitorパターンが理解できたら、
無名関数でやってることと同じようなことがOOP言語ならできるけど
OOPでVisitorパターンの位置づけはどうなのかだよ。逆に、
関数型やってる奴のほうが、使えるパターンかもしれんが。
0365デフォルトの名無しさん
2011/11/23(水) 19:04:21.81理由は簡単なんだ、アルゴリズムを理解するのにschemeやML系というのは
すごく助けになる。特に木構造の理解には良いし。
だけど、手続き型というのは、文法ノイズが多いことでアルゴリズムを理解
するときに、混同したりということも起こりえるから。そんなこんなで、
データ構造を扱うのが気楽にできるというのもあって、扱う問題に対して
適切なデータ構造とアルゴリズムを選択できるという利点があるからだよ。
感覚的にわかってたら、C++のSTLだってJavaのCollectionだって扱う感覚
が分かるってことからだよ。
0366デフォルトの名無しさん
2011/11/23(水) 19:06:03.07退散する。キモいもん・・・・。
0367デフォルトの名無しさん
2011/11/23(水) 19:09:15.35勝手にHaskell厨と騒いでるのを見てて、ここは、アホの楽園なのかと・・・。
Haskellは純粋だけにOcamlとかと比べても堅物な言語だから、
その点が容易かどうか。最も、難しいところを置いといても
プログラミングはできるけどね。
OOPとの対比になるけど、Visitorパターンが理解できたら、
無名関数でやってることと同じようなことがOOP言語ならできるけど
OOPでVisitorパターンの位置づけはどうなのかだよ。逆に、
関数型やってる奴のほうが、使えるパターンかもしれんが。
0368デフォルトの名無しさん
2011/11/23(水) 19:09:24.40勝手にHaskell厨と騒いでるのを見てて、ここは、アホの楽園なのかと・・・。
Haskellは純粋だけにOcamlとかと比べても堅物な言語だから、
その点が容易かどうか。最も、難しいところを置いといても
プログラミングはできるけどね。
OOPとの対比になるけど、Visitorパターンが理解できたら、
無名関数でやってることと同じようなことがOOP言語ならできるけど
OOPでVisitorパターンの位置づけはどうなのかだよ。逆に、
関数型やってる奴のほうが、使えるパターンかもしれんが。
0369デフォルトの名無しさん
2011/11/23(水) 19:10:48.96勝手にHaskell厨と騒いでるのを見てて、ここは、アホの楽園なのかと・・・。
Haskellは純粋だけにOcamlとかと比べても堅物な言語だから、
その点が容易かどうか。最も、難しいところを置いといても
プログラミングはできるけどね。
OOPとの対比になるけど、Visitorパターンが理解できたら、
無名関数でやってることと同じようなことがOOP言語ならできるけど
OOPでVisitorパターンの位置づけはどうなのかだよ。逆に、
関数型やってる奴のほうが、使えるパターンかもしれんが。
0370デフォルトの名無しさん
2011/11/23(水) 19:30:57.75そして、正々堂々と>>350
0371デフォルトの名無しさん
2011/11/23(水) 19:35:49.640372デフォルトの名無しさん
2011/11/23(水) 19:49:34.85独善の極みだな
吐き気がする
おまえみたいのが関数型の普及を妨げていることに気付け
0373デフォルトの名無しさん
2011/11/23(水) 19:55:05.79いや、>>350書いたのHaskellerの自分なんですが…
0374デフォルトの名無しさん
2011/11/23(水) 20:00:04.02勝手にHaskell厨と騒いでるのを見てて、ここは、アホの楽園なのかと・・・。
Haskellは純粋だけにOcamlとかと比べても堅物な言語だから、
その点が容易かどうか。最も、難しいところを置いといても
プログラミングはできるけどね。
OOPとの対比になるけど、Visitorパターンが理解できたら、
無名関数でやってることと同じようなことがOOP言語ならできるけど
OOPでVisitorパターンの位置づけはどうなのかだよ。逆に、
関数型やってる奴のほうが、使えるパターンかもしれんが。
0375デフォルトの名無しさん
2011/11/23(水) 20:00:10.35勝手にHaskell厨と騒いでるのを見てて、ここは、アホの楽園なのかと・・・。
Haskellは純粋だけにOcamlとかと比べても堅物な言語だから、
その点が容易かどうか。最も、難しいところを置いといても
プログラミングはできるけどね。
OOPとの対比になるけど、Visitorパターンが理解できたら、
無名関数でやってることと同じようなことがOOP言語ならできるけど
OOPでVisitorパターンの位置づけはどうなのかだよ。逆に、
関数型やってる奴のほうが、使えるパターンかもしれんが。
0376デフォルトの名無しさん
2011/11/23(水) 20:00:47.78理由は簡単なんだ、アルゴリズムを理解するのにschemeやML系というのは
すごく助けになる。特に木構造の理解には良いし。
だけど、手続き型というのは、文法ノイズが多いことでアルゴリズムを理解
するときに、混同したりということも起こりえるから。そんなこんなで、
データ構造を扱うのが気楽にできるというのもあって、扱う問題に対して
適切なデータ構造とアルゴリズムを選択できるという利点があるからだよ。
感覚的にわかってたら、C++のSTLだってJavaのCollectionだって扱う感覚
が分かるってことからだよ。
0377デフォルトの名無しさん
2011/11/23(水) 20:01:44.27勝手にHaskell厨と騒いでるのを見てて、ここは、アホの楽園なのかと・・・。
Haskellは純粋だけにOcamlとかと比べても堅物な言語だから、
その点が容易かどうか。最も、難しいところを置いといても
プログラミングはできるけどね。
OOPとの対比になるけど、Visitorパターンが理解できたら、
無名関数でやってることと同じようなことがOOP言語ならできるけど
OOPでVisitorパターンの位置づけはどうなのかだよ。逆に、
関数型やってる奴のほうが、使えるパターンかもしれんが。
0378デフォルトの名無しさん
2011/11/23(水) 20:02:05.78勝手にHaskell厨と騒いでるのを見てて、ここは、アホの楽園なのかと・・・。
Haskellは純粋だけにOcamlとかと比べても堅物な言語だから、
その点が容易かどうか。最も、難しいところを置いといても
プログラミングはできるけどね。
OOPとの対比になるけど、Visitorパターンが理解できたら、
無名関数でやってることと同じようなことがOOP言語ならできるけど
OOPでVisitorパターンの位置づけはどうなのかだよ。逆に、
関数型やってる奴のほうが、使えるパターンかもしれんが。
0379デフォルトの名無しさん
2011/11/23(水) 20:02:43.18勝手にHaskell厨と騒いでるのを見てて、ここは、アホの楽園なのかと・・・。
Haskellは純粋だけにOcamlとかと比べても堅物な言語だから、
その点が容易かどうか。最も、難しいところを置いといても
プログラミングはできるけどね。
OOPとの対比になるけど、Visitorパターンが理解できたら、
無名関数でやってることと同じようなことがOOP言語ならできるけど
OOPでVisitorパターンの位置づけはどうなのかだよ。逆に、
関数型やってる奴のほうが、使えるパターンかもしれんが。
0380デフォルトの名無しさん
2011/11/23(水) 20:05:11.95勝手にHaskell厨と騒いでるのを見てて、ここは、アホの楽園なのかと・・・。
Haskellは純粋だけにOcamlとかと比べても堅物な言語だから、
その点が容易かどうか。最も、難しいところを置いといても
プログラミングはできるけどね。
OOPとの対比になるけど、Visitorパターンが理解できたら、
無名関数でやってることと同じようなことがOOP言語ならできるけど
OOPでVisitorパターンの位置づけはどうなのかだよ。逆に、
関数型やってる奴のほうが、使えるパターンかもしれんが。
0381デフォルトの名無しさん
2011/11/23(水) 20:06:55.40勝手にHaskell厨と騒いでるのを見てて、ここは、アホの楽園なのかと・・・。
Haskellは純粋だけにOcamlとかと比べても堅物な言語だから、
その点が容易かどうか。最も、難しいところを置いといても
プログラミングはできるけどね。
OOPとの対比になるけど、Visitorパターンが理解できたら、
無名関数でやってることと同じようなことがOOP言語ならできるけど
OOPでVisitorパターンの位置づけはどうなのかだよ。逆に、
関数型やってる奴のほうが、使えるパターンかもしれんが。
0382デフォルトの名無しさん
2011/11/23(水) 20:09:24.66ほら、>>350
0383デフォルトの名無しさん
2011/11/23(水) 20:09:27.45OOPのVisitorパターンが冗長だって仄めかされたから？
0384デフォルトの名無しさん
2011/11/23(水) 20:10:13.380385デフォルトの名無しさん
2011/11/23(水) 20:10:20.730386デフォルトの名無しさん
2011/11/23(水) 20:11:43.84じゃあとりあえず >>244で。
0387デフォルトの名無しさん
2011/11/23(水) 20:12:06.470388デフォルトの名無しさん
2011/11/23(水) 20:15:17.67勝手にHaskell厨と騒いでるのを見てて、ここは、アホの楽園なのかと・・・。
Haskellは純粋だけにOcamlとかと比べても堅物な言語だから、
その点が容易かどうか。最も、難しいところを置いといても
プログラミングはできるけどね。
OOPとの対比になるけど、Visitorパターンが理解できたら、
無名関数でやってることと同じようなことがOOP言語ならできるけど
OOPでVisitorパターンの位置づけはどうなのかだよ。逆に、
関数型やってる奴のほうが、使えるパターンかもしれんが。
0389デフォルトの名無しさん
2011/11/23(水) 20:15:49.70勝手にHaskell厨と騒いでるのを見てて、ここは、アホの楽園なのかと・・・。
Haskellは純粋だけにOcamlとかと比べても堅物な言語だから、
その点が容易かどうか。最も、難しいところを置いといても
プログラミングはできるけどね。
OOPとの対比になるけど、Visitorパターンが理解できたら、
無名関数でやってることと同じようなことがOOP言語ならできるけど
OOPでVisitorパターンの位置づけはどうなのかだよ。逆に、
関数型やってる奴のほうが、使えるパターンかもしれんが。
0390デフォルトの名無しさん
2011/11/23(水) 20:16:10.27勝手にHaskell厨と騒いでるのを見てて、ここは、アホの楽園なのかと・・・。
Haskellは純粋だけにOcamlとかと比べても堅物な言語だから、
その点が容易かどうか。最も、難しいところを置いといても
プログラミングはできるけどね。
OOPとの対比になるけど、Visitorパターンが理解できたら、
無名関数でやってることと同じようなことがOOP言語ならできるけど
OOPでVisitorパターンの位置づけはどうなのかだよ。逆に、
関数型やってる奴のほうが、使えるパターンかもしれんが。
0391デフォルトの名無しさん
2011/11/23(水) 20:17:45.50>Haskellでグラフのデータ構造を定義する上手い方法はあるのだろうか。
これ悩むんだよね
前やった時はとりあえず計算量無視で関数を作ってみて
あとで速度が必要なところだけ定義は同じで内部でSTモナドを使った関数に置き換えた
木構造がシンプルに書けるといっても破壊的代入がないと
大規模なデータではシンプルなコードは実用的な速度が出ない
実用的な速度を出すには手続き型と同じような書き方を回りくどい方法でとらないといけない
あと大規模データを延々と処理し続けるようなプログラムだと
遅延評価は思いがけないところでメモリリークを起こしやすいように思う
そしてそれを見つけるのが困難
スクリプト的な使い方には非常によいと思う
でも、実用的にはOCamlくらいがいいんじゃないかな
HaskellはType Classや構文が羨ましいけどね
0392デフォルトの名無しさん
2011/11/23(水) 20:17:45.63勝手にHaskell厨と騒いでるのを見てて、ここは、アホの楽園なのかと・・・。
Haskellは純粋だけにOcamlとかと比べても堅物な言語だから、
その点が容易かどうか。最も、難しいところを置いといても
プログラミングはできるけどね。
OOPとの対比になるけど、Visitorパターンが理解できたら、
無名関数でやってることと同じようなことがOOP言語ならできるけど
OOPでVisitorパターンの位置づけはどうなのかだよ。逆に、
関数型やってる奴のほうが、使えるパターンかもしれんが。
0393デフォルトの名無しさん
2011/11/23(水) 20:17:48.48ん、若田
ただな。問題は、自分がプログラミングHaskell読み終わってない初心者なんだなｗ
使用例とか、どういう動きを期待されてるのか知らないと、書けんw
教えてくれｗ
0394デフォルトの名無しさん
2011/11/23(水) 20:18:44.86勝手にHaskell厨と騒いでるのを見てて、ここは、アホの楽園なのかと・・・。
Haskellは純粋だけにOcamlとかと比べても堅物な言語だから、
その点が容易かどうか。最も、難しいところを置いといても
プログラミングはできるけどね。
OOPとの対比になるけど、Visitorパターンが理解できたら、
無名関数でやってることと同じようなことがOOP言語ならできるけど
OOPでVisitorパターンの位置づけはどうなのかだよ。逆に、
関数型やってる奴のほうが、使えるパターンかもしれんが。
0395デフォルトの名無しさん
2011/11/23(水) 20:20:24.62あ、大丈夫
typeで独自の型を作るところまではやってるから、後は何とか出来ると思う
あの薄さの入門書でどこまで出来るかやってみたいんだ
0396デフォルトの名無しさん
2011/11/23(水) 20:20:45.35勝手にHaskell厨と騒いでるのを見てて、ここは、アホの楽園なのかと・・・。
Haskellは純粋だけにOcamlとかと比べても堅物な言語だから、
その点が容易かどうか。最も、難しいところを置いといても
プログラミングはできるけどね。
OOPとの対比になるけど、Visitorパターンが理解できたら、
無名関数でやってることと同じようなことがOOP言語ならできるけど
OOPでVisitorパターンの位置づけはどうなのかだよ。逆に、
関数型やってる奴のほうが、使えるパターンかもしれんが。
0397デフォルトの名無しさん
2011/11/23(水) 20:21:05.68勝手にHaskell厨と騒いでるのを見てて、ここは、アホの楽園なのかと・・・。
Haskellは純粋だけにOcamlとかと比べても堅物な言語だから、
その点が容易かどうか。最も、難しいところを置いといても
プログラミングはできるけどね。
OOPとの対比になるけど、Visitorパターンが理解できたら、
無名関数でやってることと同じようなことがOOP言語ならできるけど
OOPでVisitorパターンの位置づけはどうなのかだよ。逆に、
関数型やってる奴のほうが、使えるパターンかもしれんが。
0398デフォルトの名無しさん
2011/11/23(水) 20:27:37.78type Graph = ([Int], [(Int, Int)])
ソース
http://www.shido.info/hs/haskell9.html
0399デフォルトの名無しさん
2011/11/23(水) 20:28:29.440400デフォルトの名無しさん
2011/11/23(水) 20:32:22.080401デフォルトの名無しさん
2011/11/23(水) 20:35:33.47そのグラフからエッジを一本削除してください
0402デフォルトの名無しさん
2011/11/23(水) 20:37:34.15ごめん
エッジを削除ってのは、どういう動作なの？
>>395=>>398なの
全く分からんでググった
0403デフォルトの名無しさん
2011/11/23(水) 20:38:17.390404デフォルトの名無しさん
2011/11/23(水) 20:47:09.45回りくどいって言うが、IORefはOCamlのrefとほとんど同じだよね
名前が長くて鬱陶しいのは認めるけど、実用性をうんぬんするような違いではないと思う
しかし自分が普段使ってない言語の実用性が低く見えるのはある程度仕方ないんだろうな
俺も「OCamlってマルチコア対応してないのにどうやって実用プログラム書けるんだろう」とか思うし
0405デフォルトの名無しさん
2011/11/23(水) 20:49:13.56いや、グラフとか、エッジを削除とかの用語が分からんだけ
マージソートも、コードなしのアルゴリズムの本で組めたから
（「アルゴリズムのキホン」とか言う、これで手続型言語で組めるのかいな？という舐めきった本）
0406デフォルトの名無しさん
2011/11/23(水) 20:50:11.420407デフォルトの名無しさん
2011/11/23(水) 20:51:47.78いや、それは関数型特有の独善性だから。
勝手に一般化しないでくれ。迷惑だ。
0408デフォルトの名無しさん
2011/11/23(水) 20:51:58.75そんな初心者が書けたら、どうする？
0409デフォルトの名無しさん
2011/11/23(水) 20:53:57.210410デフォルトの名無しさん
2011/11/23(水) 20:54:12.610411デフォルトの名無しさん
2011/11/23(水) 20:54:37.55だから、マジ初心者なんだってば
0412デフォルトの名無しさん
2011/11/23(水) 20:55:48.62関数型の独善性って？関数型ユーザの独善性って言いたいの？
それこそ不用意な一般化だろ。同意できないならそうとだけ言えばいい
0413デフォルトの名無しさん
2011/11/23(水) 20:55:53.020414デフォルトの名無しさん
2011/11/23(水) 20:56:21.700415デフォルトの名無しさん
2011/11/23(水) 20:57:50.880416デフォルトの名無しさん
2011/11/23(水) 20:57:59.46え、Pythsはピタゴラス数であって素数じゃないけど・・・・
手続型の人が怖がってるんですか?
初心者Haskellerに？
0417デフォルトの名無しさん
2011/11/23(水) 20:59:17.38バーカ、おまえが先に一般化をしたんだろ
他人の一般化を批判する権利はない
自分だけが特別だと思ってる関数型厨の典型だな
0418デフォルトの名無しさん
2011/11/23(水) 21:03:52.84え、グラフ理論（？）とHaskellの動作原理に何の関係が…
と、言うか、動作原理は理解してない。・・・と思ってる
0419デフォルトの名無しさん
2011/11/23(水) 21:04:38.43なにそれ。互いのミスを指摘しあうのは議論なら当然だろ
「お前が先に間違えたから俺の勝ちな」とか言っても始まらんよ
あと何か一般化が無条件で悪いと思ってる？
0420デフォルトの名無しさん
2011/11/23(水) 21:10:13.08>回りくどいって言うが、IORefはOCamlのrefとほとんど同じだよね
型がクドくなる
0421デフォルトの名無しさん
2011/11/23(水) 21:10:32.290422デフォルトの名無しさん
2011/11/23(水) 21:11:57.63まぁunsafeなんちゃらつかえばいいんだけど
0423デフォルトの名無しさん
2011/11/23(水) 21:14:28.17使った端から到達不能になるから
O(n)でいいんじゃない？
0424デフォルトの名無しさん
2011/11/23(水) 21:18:09.84Haskellの有名なやつを念頭に置いてる？
あれは遅延リストだから空間計算量は訳分からんことになる
最悪O(n log n)かもしれない
同じことを正格なリストか配列でやればO(n)
in-placeのクイックソートを実装すればもちろん追加メモリは定数で済む
0425デフォルトの名無しさん
2011/11/23(水) 21:18:52.60グラフの説明とエッジ削除の説明は・・・
0426デフォルトの名無しさん
2011/11/23(水) 21:19:26.720427デフォルトの名無しさん
2011/11/23(水) 21:20:19.93ここはお前の勉強部屋じゃない
0428デフォルトの名無しさん
2011/11/23(水) 21:21:48.63まともなデータ構造の教科書を買うか借りるかぐぐる
0429デフォルトの名無しさん
2011/11/23(水) 21:24:32.310430デフォルトの名無しさん
2011/11/23(水) 21:26:00.820431デフォルトの名無しさん
2011/11/23(水) 21:27:34.40せめて、手続型言語のコードは出ないんでしょうか?
0432デフォルトの名無しさん
2011/11/23(水) 21:41:57.794種類のノルムを定義して
それぞれについてダイクストラ
結果に応じて条件分岐して
各エッジに容量を設定して
最大フロー問題
0433デフォルトの名無しさん
2011/11/23(水) 21:43:06.45関数型言語の検証ができないじゃないか
自分は文法に惚れただけで、実用可能かどうかははっきりしてないんよ
このスレが検証にうってつけだと思ったんだけどな・・・
0434デフォルトの名無しさん
2011/11/23(水) 21:45:11.51要はグラフ理論知らないだけだろ？勉強不足。
0435デフォルトの名無しさん
2011/11/23(水) 21:46:09.65ハスケルではつらそうな例を考えて見ました
0436デフォルトの名無しさん
2011/11/23(水) 21:51:59.91いやだから・・・
マジ初心者だから、ダイクストラから分からんのよ…
一応、ググったらCのコード出てきて、typeすら使う必要ないっぽいけど・・・
ダイクストラ法 Haskellでググったらこんなん出てきてるけど
type Index = (Int, Int)
data Node = Node { cost :: !Int, pos :: !Index, from :: !Index }
deriving (Show, Eq, Ord)
ソース
http://haskell.g.hatena.ne.jp/route150/20100502/1272792417
こういうのを、自分はちゃんと自分で書きたいんだよ
んで、手続型言語のソースが一向に出ないのも、説明が出ないのも何でよ・・・
0437デフォルトの名無しさん
2011/11/23(水) 21:53:04.780438デフォルトの名無しさん
2011/11/23(水) 21:54:34.050439デフォルトの名無しさん
2011/11/23(水) 21:56:10.02そうよ
手続型だろうが、関数がら多だろうが、それを知らなきゃ書けんのよ
マージソートのときは、Haskellでは分かっても、手続型言語で書き方分からんかった（いや、配列じゃなくてリストで作れってなら、今なら作れるけどさ）
色々やったよ
CもRubyもJavaもSmalltalkまでやったさ
0440デフォルトの名無しさん
2011/11/23(水) 21:56:56.67なら、それがHaskellで書くヒントになるから書いてほしい
0441デフォルトの名無しさん
2011/11/23(水) 21:57:41.76「グラフというデータ構造を知らないんだから書けるわけないだろ、教えてくれないそっちが悪い」ってか？
それお花畑すぎねえか？
0442デフォルトの名無しさん
2011/11/23(水) 21:59:16.59勉強してから来てくれ
0443デフォルトの名無しさん
2011/11/23(水) 21:59:48.77だから双方向リストでいいって。
末尾に O(1) で要素を add できる。
末尾要素を O(1) で remove できる。
末尾要素を O(1) で取得できる。
一つ前の要素を O(1) で辿れる。
これを満たすデータ構造を作れ。
0444デフォルトの名無しさん
2011/11/23(水) 22:01:39.78グラフ知らない人に
オーダー記法使って話しかけるなｗｗ
0445デフォルトの名無しさん
2011/11/23(水) 22:03:14.950446デフォルトの名無しさん
2011/11/23(水) 22:04:09.59代入なんて効率のためにあるようなもんだし
0447デフォルトの名無しさん
2011/11/23(水) 22:04:46.76ふむ、ちょい頑張ってみる
酔っぱらってきてるから、明日とか明後日になるかもだけど、作ってみるよ
0448デフォルトの名無しさん
2011/11/23(水) 22:05:32.970449デフォルトの名無しさん
2011/11/23(水) 22:07:21.87うい、無限のメモリと無限のクロックがあれば最強
だから、個人的には６４ビットOSの普及がHaskell普及のカギかな?とか思ってみたり
CからC++、さらにLLへと流れてきた延長で
0450デフォルトの名無しさん
2011/11/23(水) 22:08:27.370451デフォルトの名無しさん
2011/11/23(水) 22:09:02.87いや、書くよ
今日書けるか自信がないだけ
何つーても初心者（少なくともHaskellはｗ）な上に、酒がまわってきた
0452デフォルトの名無しさん
2011/11/23(水) 22:10:27.57という人が双方向リストを作るのに明日か明後日になる。
それがHaskell
0453デフォルトの名無しさん
2011/11/23(水) 22:11:16.27ぶっちゃけ、コード書くのは楽だけど、LLとはどっこいどっこいだとして、やっぱメモリ食うもんよ
クロックの方は、腐ってもコンパイラだから、LLより速いんだけど（Rubyの後でHaskellやってたから、マジビビった）
0454デフォルトの名無しさん
2011/11/23(水) 22:12:00.17いや・・・
入門書で挫折してるから…
覚えた言語の数が問題じゃないんですぜ？
0455デフォルトの名無しさん
2011/11/23(水) 22:13:05.76それで、32ビットOSが64ビットOSになるのに合わせて、搭載されるメモリが2^32倍になるのかな？
0456デフォルトの名無しさん
2011/11/23(水) 22:13:12.990457デフォルトの名無しさん
2011/11/23(水) 22:13:43.78あ、ついでだけど、双方向リストって英語でなんて書くの？
関数名＆ファイル名にしたいんだけど
0458デフォルトの名無しさん
2011/11/23(水) 22:14:46.47そりゃそうだろ。ソースを見て写経してもいいが意味ないし
0459デフォルトの名無しさん
2011/11/23(水) 22:15:28.200460デフォルトの名無しさん
2011/11/23(水) 22:16:02.160461デフォルトの名無しさん
2011/11/23(水) 22:18:45.420462デフォルトの名無しさん
2011/11/23(水) 22:22:52.94実用的にはそこまで要らないだろうけど、末尾再帰使わんと、４GBじゃ不足する場面もあるんよね…
末尾再帰よりはループの方が素直なんよ
（そういえば、Haskellにもfor関数あるっポイんだが、使い方分からん…。副作用のある関数で使うモナドの糖衣構文do内の引数なし再帰は実質、ラベル付きGotoだから、困るわけではないんだけど…）
自分でfor関数作った方が速いんじゃろか…
（doが付く関数内でしか使わんけど）
0463デフォルトの名無しさん
2011/11/23(水) 22:23:24.900464デフォルトの名無しさん
2011/11/23(水) 22:25:09.62たぶん…
かなり稀な方だと自覚してる
ウザがられるの分かってるけど、Haskellが一番しっくり来たんで絶賛宣伝中
逆効果かも知れんけど、その時は、真のHaskellerが何とかしてくれると（ｒｙ
0465デフォルトの名無しさん
2011/11/23(水) 22:27:35.06名前欄にHaskellSamuraiとか入れとくといいよ
0466デフォルトの名無しさん
2011/11/23(水) 22:28:02.88ksg
0467デフォルトの名無しさん
2011/11/23(水) 23:33:13.410468デフォルトの名無しさん
2011/11/23(水) 23:35:21.30メモリ足りない時とかI/Oの帯域幅が重要な時とか。
0469デフォルトの名無しさん
2011/11/24(木) 00:34:25.910470HaskellSamurai
2011/11/24(木) 00:43:21.42data DList f l = Null | DList f l
deriving (Eq, Ord, Show, Read)
そもそも、双方向リストってのが、どういう動きするのかが分からんのだもん・・・
一応、自分の作った双方向リスト（か分からない何か）の使用例
>Null
Null
>DList Null Null
DList Null Null
>DList 1 (DList 2 Null)
DList 1 (DList 2 Null)
>DList (DList Null 2) 1
DList (DList Null 2) 1
0471デフォルトの名無しさん
2011/11/24(木) 00:57:08.04空リスト
空リストの空リスト
通常のリストと同じ方向にリスト作成
通常のリストと逆方向にリスト作成
これを使ってO(1)で結果が返るadd関数やremove関数作を作れるかはまだ分からない状態
0472デフォルトの名無しさん
2011/11/24(木) 01:01:08.94それを使ってrmapとかrconsとか実装してみればいい。
0473デフォルトの名無しさん
2011/11/24(木) 01:03:59.62これでも読んどけ。
0474デフォルトの名無しさん
2011/11/24(木) 01:51:33.02懐かしいなあ、俺とかプログラミング始めたの小学生のときだわ
初めての言語はBASICだったが
仮に初めてが関数型言語だったとしたら、さんすうの知識でやれたんだろか？
0475デフォルトの名無しさん
2011/11/24(木) 04:47:55.03なるほど、ハスケラってメンヘラなんだな
0476HaskellSamurai
2011/11/24(木) 06:42:56.06双方向リストモドキを定義しなおし、そのhead関数も定義してみた
data DList a = Null | DList (DList a) a (DList a)
deriving (Eq, Ord, Show, Read)
dhead (DList Null x _) = x
dhead (DList xs _ _) = dhead xs
使用例
*Main> dhead (DList (DList Null 2 Null) 1 (DList Null 3 Null))
2
0477デフォルトの名無しさん
2011/11/24(木) 07:22:27.25> OCamlってマルチコア対応してないのにどうやって実用プログラム書けるんだろう
Unix.fork または ocamlmpi
0478デフォルトの名無しさん
2011/11/24(木) 14:40:24.150479デフォルトの名無しさん
2011/11/24(木) 15:05:22.400480デフォルトの名無しさん
2011/11/24(木) 17:35:22.41それ、２分木だろ
全然双方向リストになってねえよ
0481デフォルトの名無しさん
2011/11/25(金) 16:17:52.04流れは良くわからんが
そも双方向リストは単純に再帰定義できないからhaskellでは素直に書けないよ
双方向リストを実装したライブラリというのも、俺は見たことないな
どうしても使いたいなら頭を捻るか、STモナドやIOモナドに入れて対応しよう
再帰定義できないデータ型としては例えば他に両端キューやハッシュテーブルがあるけど、
haskellの両端キューは特別な木で実装されてるし（前者）、
haskellのハッシュテーブルはIOモナドの中でしか使えない。（後者）
そして普通はハッシュテーブル使うぐらいなら再帰定義可能な平衡二分探索木を使うようだね
haskellのやり方というのはそういうものだ
0482デフォルトの名無しさん
2011/11/25(金) 16:51:50.46分かりやすく二行でまとめると、
・手続き型言語やLisp/ML等の大半の関数型言語 --> 双方向リストやハッシュが「自然に書ける」
・Haskell --> 再帰定義やモナドといった「面倒な手法を駆使しなければ」表現できない
ということですかな
0483デフォルトの名無しさん
2011/11/25(金) 17:13:22.23他の関数型言語がそれらを自然に書けるかどうかは不勉強なんで良くわからんな
ただ、双方向リストで必要な参照型と、ハッシュテーブルで必要な破壊的代入は、どっちもhaskellが生理的に嫌ってる部分だからね
その両方を簡単に扱える言語であればどちらも自然に書けるはずだよ
モナドはともかく、再帰定義が『面倒な手法』というのは手続き的な発想だな
むしろhaskellは再帰を愛しているからこそ、できる限りそれだけで対応したがる、というのが正しい
あんまり変わらない？ うん、まあ、そうかもしれんね
0484デフォルトの名無しさん
2011/11/25(金) 17:35:37.07るんだから。
小学校に上がる2年前にタッチタイピング、1年前にLISPで数の概念を教えて
中学卒業前に偏微分まで独学させたらおもしろい子供になると思う。学校では
数学を習うから手続き型も覚えるし、かなりちょうど良いんじゃないかな。
あと小学校で習う筆算の＋−×÷の記法って特殊だよね。あとそろばん習って
いる人は今は少ないかもしれないけど、そろばん流暗算も特殊だよね。
余談だけど子供には読み書きもしっかりやらせたいと思っている。とくに書きは
意識的にやらせないと覚えないので意識的にやらせる。プログラミングの習得って
早ければ早いほどプログラミング歴が長くなって、時間感覚が豊富になるよね。
15歳からプログラミングを始めて18歳で考えるプログラミングや世間に対する
とらえ方と6歳からプログラミングを始めて18歳で考えるプログラミングや世間に
対するとらえ方はまったく違うものになるだろうね。15歳から始めたヤツは27歳
ぐらい必要だろうし。早くても24歳ぐらいは必要だろうなあ。これは読みと書きにも
言えること。数学はそういう時間感覚があるのか、知らん。
>>230
x = x+1ってx <== x+1の省略記述だよね、厳密には。教育言語のPascalがx := x+1なん
だっけ？
>>231
躓きはしないけど「うん？」とはなっていたなあ。
>>232
慣用句だと思って暗記して使うしかないけどなあ。9.9割はパターン認知処理で問題が
起きないので忘却曲線を意識してすべて暗記すればいいと偉い先生が言っていたよ。
>>236
日本語の算術的に考え方で言うとそろばんと升とかの方が歴史は長いんじゃないの？
近代化のために江戸時代的なものを脱ぎ捨てて今があるけど。
0485デフォルトの名無しさん
2011/11/25(金) 18:10:20.80日本の教育システムは、採点し易いか否かを優先してるから、論理性は教える方も解ってないからなあ。
0486デフォルトの名無しさん
2011/11/25(金) 18:47:52.51アメリカの教育って今の日本の教育並にウンコだっただけでしょ。
あとプログラミングの教育って相当難しいんじゃないかな。おまえら、
中高でかなり時間割り当てられているはずだけど、古文、漢文自作できるか？
あとA4二枚の英作文できるか？
>>321
選民思想なのかわからないが、人が選択肢している時点で合理的な判断をして
いるから合理性は出てくるだろうなあ。
>>331
それただ教えてもらっていないだけでしょ。今の数学の教科書みたいに二段飛び、
三段飛び当たり前だときついけど、小中高のすべて合わせて1,500ページの教科書を
渡して中1まで進めれば勝手に独学して進めるヤツは結構いると思うよ。
>>338
あいさつの概念、作文の概念、読書の概念、算数の概念、活版印刷の概念とか一々
やったら子供は逃げ出すだろうなあ。空手や柔道みたいに型を教えて、何年後かに
分かればいいだけ。
>>474
数学が得意で国語が不得意だったけどベーマガのBasicコードを写しているだけだったな。
付属のリファレンスを読んでみたけど、関数？(学校で習った関数だよな？)？だった。
市の図書館に行っても小難しい本しかないし、ネットもなかったらフリーソフトを
手に入れる手段もなかった。万単位のお金を払ってプログラミング言語を買う概念なんて
なかったし、そのソフトを仮に大奮発で買うとテキストを買うのは無理だからなあ。
やっぱり本でどうやって引き込んでいくかが大事な気がする。プチゲーム(ジャンケン
ゲーム等)を組ませつつ、数理的な問題も組ませつつ引き込んで行く。
80年代がマイコン全盛なんだっけ？子供向け本も多かったんだろうけど、今はそうい
うのが少ないんだろうなあ。子供向けではないけど個人のWebページで言語入門みたい
なのがあるからそういうのでアナルファックの味とか覚えるのかな。
0487デフォルトの名無しさん
2011/11/25(金) 18:59:04.95論理性も教えるためにゆとり教育ができたんだけどね。小学校は熱心だったようだけど、
中高は一部の先生がボイコットしちゃったたみたいだね。まあ、ゆとり以前に
週5授業とか、予算と教員に教材仕込む時間を設けなかったりとか、色々と問題があった
し、ゆとり導入前にマスゴミが学校をガンガン叩いて劇場化して、教員が教えられない
状況を作っちゃったからどうしょうもないんだけどね。子供に一番良くないのは親が
教員を疑うことと教員が自信を持って教えられる環境がなくなることらしい。
アメリカのデータだとインディアン部族の教育が体罰あるらしいが、体罰したからって
変な子供になるわけではないらしい。文明先進民族の白人が勝手に「体罰は良くない」と
注意し始めて、インディアン自身が白人が言っていることの方が正しいと思ってしまって、
教え方にブレが生じて、荒れ始めたらしい。日本は家庭体罰に行政介入できるようになっ
ちゃったから家庭教育しづらいわ。子供の人権を盾にやりたい放題させるのは子供自身にも
本当に良くないと思うわ。まあ、この流れは当分止まらないんだろうけどなあ。
0488デフォルトの名無しさん
2011/11/25(金) 19:12:30.73Cであったり、Javaであったり、.netであったり、Perlであったり、Pythonであったり、
RubyであったりだとCの実行速度を持ちつつ、VM上で動くのでOSを環境依存もなく、
Windows対応もよく、文書整形向きでワンライナーもしやすく、可読性もよく、日本人が
作った最強言語と錯覚させる恐れがある。個人戦でVSで戦ったら実際の所はどうなんだろ。
トーナメントつくって議論して勝敗決めていこうか。
0489デフォルトの名無しさん
2011/11/25(金) 19:25:39.380490デフォルトの名無しさん
2011/11/25(金) 19:48:23.59双方向はそう幽霊だよね。学習用と見たときな明確に欠点かなと思ってる。
スペシャリストとジェネラリストに分けたら、Haskellはスペシャリストなん
だよ。Ocamlはまだジェネラリストの顔を持ってる。
手続きが書きやすいかどうかは知らないけど、lispで構造体を使って双方向
リストを作ってみたら、いささかCと変わらん感じがする部分は出てくるよ。
どうしてもポインタ操作で破壊的操作が必要だからね。木構造はHaskellは
大変扱いやすいんだけどなぁ。HaskellというよりML系はというほうが適切か。
だから、木構造を上手に活用する方法を考えだすんだろうね。
HaskellでSICPの後継が欲しいってのもSICPスレで読んだけど、Haskellじゃ
どうしても途方もなくめんどくさくなる章があるんだよな。それがHaskell
の限界だと思ってるよ。限界を超えようとして頑張ってる人たちも多いけど
大変だよね。その頑張ってる人たちがいるから並行処理に魅力があるんだけ
どな。
0491デフォルトの名無しさん
2011/11/25(金) 19:52:29.200492デフォルトの名無しさん
2011/11/25(金) 20:04:12.520493デフォルトの名無しさん
2011/11/25(金) 20:09:39.54see >>473
0494デフォルトの名無しさん
2011/11/25(金) 22:05:39.70こっからhaskell 覚えてメリットある？
0495デフォルトの名無しさん
2011/11/25(金) 22:32:25.61O(log(N))の平衡木を使わなけゃならんの？
どうして双方向リストを使わずに
単方向リストや配列を使わなけゃならんの？
0496デフォルトの名無しさん
2011/11/25(金) 22:40:34.57べつにハッシュマップや双方向リストを使いたければ使えば良いよ
そのかわりpersistentなデータ構造にはならないってだけ
0497デフォルトの名無しさん
2011/11/25(金) 22:55:32.69効率の良いデータ構造をモナドの外で使えないのは不便じゃないの？
0498デフォルトの名無しさん
2011/11/26(土) 00:02:27.090499デフォルトの名無しさん
2011/11/26(土) 00:24:12.60その上で動かす関数型言語がぎこちないのは当然の理屈だな。
0500デフォルトの名無しさん
2011/11/26(土) 00:46:38.190501デフォルトの名無しさん
2011/11/26(土) 00:56:37.11そのためにありとあらゆる工夫をして高速化してるのがOkazakiじゃなかったっけ？
良く言えばすごいけど、Okazaki本は話しか聞いてないから見てないけど、SMLで
かかれてるんだよな？
悪く言えば、純粋のためのバッドノウハウと取られかねない。藁
0502デフォルトの名無しさん
2011/11/26(土) 01:05:55.910503デフォルトの名無しさん
2011/11/26(土) 01:08:08.510504デフォルトの名無しさん
2011/11/26(土) 01:15:18.21んなこたーない。
主流CPUの機械語が全て手続き型なのは紛れもない事実
0505デフォルトの名無しさん
2011/11/26(土) 01:16:55.39http://ja.wikipedia.org/wiki/%E5%91%BD%E4%BB%A4%E5%9E%8B%E3%83%97%E3%83%AD%E3%82%B0%E3%83%A9%E3%83%9F%E3%83%B3%E3%82%B0
宣言型プログラミング
http://ja.wikipedia.org/wiki/%E5%AE%A3%E8%A8%80%E5%9E%8B%E3%83%97%E3%83%AD%E3%82%B0%E3%83%A9%E3%83%9F%E3%83%B3%E3%82%B0
一般に命令型プログラミングは、手続き型プログラミングと同義として扱われる。
0506デフォルトの名無しさん
2011/11/26(土) 01:18:09.14用語がおかしいから意見が食い違う。
機械語は手続き型というより、命令型プログラミングという表現が正しい。
0507デフォルトの名無しさん
2011/11/26(土) 05:14:39.53結局ハスケルの代数データ型は
LISPのcar,cdrのリスト構造の範疇内でしか
データを操作できないってことでOK？
0508デフォルトの名無しさん
2011/11/26(土) 06:32:13.65oka S aki ね
0509HaskellSamurai
2011/11/26(土) 07:08:13.68こんなのも書いてみたけど、双方向リストじゃ・・・ないよね・・・
ジグザグな構造になっちゃうし
data DList a = Null | Prev (DList a) a | Next a (DList a)
deriving (Eq, Ord, Show, Read)
使用例
Prev (Prev Null 1) 2
>Prev (Prev Null 1) 2
Next 1 (Next 2 Null)
>Next 1 (Next 2 Null)
Prev (Prev (Next 3 Null)) 1) 2
>Prev (Prev (Next 3 Null)) 1) 2
うーん・・・
双方向リストの使用例みたいなのが見たい・・・
0510デフォルトの名無しさん
2011/11/26(土) 07:09:42.500511デフォルトの名無しさん
2011/11/26(土) 07:32:40.180512デフォルトの名無しさん
2011/11/26(土) 07:44:33.01>>509
『各要素が左右へのポインタを保持する』という実装にこだわらないなら、
つまり、ただ>>443のインタフェースが欲しいだけなら両端キューを使えばいいよ
ttp://hackage.haskell.org/packages/archive/containers/latest/doc/html/Data-Sequence.html
0513デフォルトの名無しさん
2011/11/26(土) 08:30:49.02『双方向リスト』は再帰定義できないから、
haskellは両端キューを『フィンガーツリー』で実装している
『ハッシュテーブル』は再帰定義できないから、
haskellは連想配列を『平衡二分木』で実装している
というのが正しい
0514デフォルトの名無しさん
2011/11/26(土) 10:57:48.09この後どうなっちゃうの？
0515デフォルトの名無しさん
2011/11/26(土) 11:25:03.90>>496
0516デフォルトの名無しさん
2011/11/26(土) 11:25:19.56連想配列として常にハッシュテーブルが最適とは限らない
なにより一応両方使えるんだから適宜使い分ければよいでしょう
0517デフォルトの名無しさん
2011/11/26(土) 11:38:15.05バカにしてるだろうかね？謎だな。エバンジェリストのところのhaskellの
wikiがgaucheのなのに。
0518デフォルトの名無しさん
2011/11/26(土) 11:41:51.840519デフォルトの名無しさん
2011/11/26(土) 11:49:20.23http://www.haskell.org/haskellwiki/Zipper
ぐぐるとZipperを使えって話があったのでZipperを調べてみた。
0520デフォルトの名無しさん
2011/11/26(土) 12:37:32.56確かに双方向だな
0521デフォルトの名無しさん
2011/11/26(土) 14:07:35.45フィンガーツリーや平衡二分木というのはデータ構造に関する
汎用的なアルゴリズムだから、Haskell固有の概念ではない
実際、二分木による連想配列の実装は手続き型言語でも使われる
これに沿って>>482を書き直すと、
Lisp/ML等の大半の関数型言語 -->
・手続き型言語の経験者であれば、(破壊的代入を用いる事で)
その経験を活かして容易く双方向リストやハッシュを実装できる
・もしも参照透明性が必要であれば、(難解ではあるが)
フィンガーツリーや平衡二分木といったアルゴリズムで実装する事もできる
・どちらを選ぶかはプログラマの判断であり、
処理系からプログラマには「自由」が与えられる
Haskell限定 -->
・双方向リストやハッシュはフィンガーツリーや平衡二分木といった
(難解な)アルゴリズムを用いなければ実装できない
・プログラマは参照透明性の保証を、常に処理系から「強要」される
ということですかな
0522デフォルトの名無しさん
2011/11/26(土) 14:44:19.31MLとかは参照透明性は必要であればプログラマが保証する必要がある
と思いきやUnsafeIOとかあるしな
0523デフォルトの名無しさん
2011/11/26(土) 15:02:03.95といいつつtraceは使うんだけどね
0524デフォルトの名無しさん
2011/11/26(土) 15:16:27.440525デフォルトの名無しさん
2011/11/26(土) 15:20:47.79もちろん破壊的代入をしないスタイルの利点(persistentなデータ構造、
状態に関するバグに悩まされない)は失われるけど、それは当然のトレードオフ
0526デフォルトの名無しさん
2011/11/26(土) 15:25:08.280527デフォルトの名無しさん
2011/11/26(土) 15:26:18.51X: Haskellだと参照透明性が「必ず」保証される
O: Haskellだと参照透明性をプログラマが「必ず」保証しなければならない
X: MLとかは参照透明性は必要であればプログラマが保証する必要がある
O: MLとかはプログラマは参照透明性を保証することもできるし、
保証しないコードも書けるという「自由」がある
0528デフォルトの名無しさん
2011/11/26(土) 15:35:00.67うん。もうちょっと正確に言うと、IOモナドやらIORefやらを使うだけでは
Haskellの参照透過性を壊すことはできない
unsafePerformIOその他の危険な関数を使えば壊せる
0529デフォルトの名無しさん
2011/11/26(土) 15:44:10.23みたいな工夫をしてるの？よくしらんねんけど
0530デフォルトの名無しさん
2011/11/26(土) 16:04:08.75>だからHaskellなら参照透明性を守ったまま破壊的代入ができるんだって
それは「モナドを使えば....」という前提があるわけで、
そのモナドで包んだ範囲内では参照透明性が保証されるという話だろ？
言い換えると、Haskell処理形は参照透明性が保証されたコードしか受け付けないから、
プログラマが(モナドを使って)保証したコードを書いているという事だ
つまり、
Haskell限定 -->
・I/Oや破壊的代入といった参照透明性を阻害する処理については、
すべてモナドを使わなければコードが書けない
Lisp/ML等の大半の関数型言語 -->
・モナドのような難解な概念を持ち出さなくても、自然にコードが書ける
・もちろん>>136のSMLの実例あるように、参照透明性を保証したコードも書ける
ということを意味している
手続き型言語およびLisp/ML等の大半の関数型言語に慣れた、いわゆる普通のプログラマにとって
たかが入出力ですらいちいちIOモナドを使わなければコードが書けないダメ言語が Haskell
0531デフォルトの名無しさん
2011/11/26(土) 16:09:14.950532デフォルトの名無しさん
2011/11/26(土) 16:28:38.67たとえば「読んで; 計算して; 書く」という単純な処理は、
SMLなら以下のような明解なコードになる
（他のML族やLisp族でも同様なコードになる）
let
val x = 読む
val y = 計算 x
in
書く y
end
それがHaskellでは、こんな初歩のプログラミングですら
IOモナドを使わなければコードが書けないだぜ
どこをどう考えても 「Haskellはダメ言語」 だろ
0533デフォルトの名無しさん
2011/11/26(土) 16:29:36.50単にdo書くだけなのに、そんなに手間か？
個人的には手続モードと関数モードを行ったり来たりする感覚
0534デフォルトの名無しさん
2011/11/26(土) 16:35:02.030535デフォルトの名無しさん
2011/11/26(土) 16:41:56.76他人様の作ったモナドを利用するだけの「末端プログラマ」であれば、
それでもいいんじゃね？
0536デフォルトの名無しさん
2011/11/26(土) 17:10:47.30「副作用」とかいう謎の概念を駆使しないといけない言語と比較するなら、
五十歩百歩だろ
0537デフォルトの名無しさん
2011/11/26(土) 17:17:48.900538デフォルトの名無しさん
2011/11/26(土) 17:21:27.86入力して計算して出力するだけなら、それで十分じゃね？
何を無駄にモナド作るんだよ
0539デフォルトの名無しさん
2011/11/26(土) 17:27:14.34そりゃ、アセンブリ以外の手続き型言語は大抵副作用という概念を持っているからな
0540デフォルトの名無しさん
2011/11/26(土) 17:29:36.46Haskellはよく知らんがこんな感じだろ？似たようなもんじゃね
do
x <- 読む
書く y
where
y = 計算 x
0541デフォルトの名無しさん
2011/11/26(土) 17:31:23.33って手続き型言語のこと言ってるんじゃない？
0542デフォルトの名無しさん
2011/11/26(土) 17:31:29.19細かいことを言うとそのwhereはletにしないとxがスコープにないのでエラーになる
do
x <- 読む
let y = 計算 x
書く y
ますます似てる
0543デフォルトの名無しさん
2011/11/26(土) 17:40:02.350544デフォルトの名無しさん
2011/11/26(土) 17:43:37.02純粋関数として定義したものの、あとからその『内部』でIOを扱いたくなった場合、
printfデバッグみたいにここに一行挟んでー、みたいな気楽な使い方は、残念ながら出来ない。
一度IOを持ち込むとsafeなやり方ではその中から出られなくなってしまうから（つまり、関数の返り値の型が変わってしまう）
0545デフォルトの名無しさん
2011/11/26(土) 17:48:45.95printfデバッグに限ってはDebug.Traceを使うけど
0546HaskellSamurai
2011/11/26(土) 17:55:49.14いや・・・
自分が無理に副作用無しの双方向リスト作ろうと奮闘してグダグダにしてるだけ・・・
今月の数学セミナーによると、計算機科学全般の副作用を数学上で再現するためにモナドが生まれたっぽい
つまり、関数型言語のみならず、手続型言語全般の動作を数学上で再現するにはモナドが必要らしい
そういう意味では、モナドでオブジェクト指向も再現できるのかも
そういう意味で、モナドは副作用のない数学の世界に、副作用を再現する概念なんだよね
Haskellのモナドも、良く分からんが、そういう事なんじゃないかと思う
それはともかく、自分は双方向リストはじめ、勉強不足すぎるから、しばらくROMるよ
0547デフォルトの名無しさん
2011/11/26(土) 18:06:31.900548デフォルトの名無しさん
2011/11/26(土) 18:10:16.97その考え方はいただいてやったぜ。
C++のSTLとかも影響受けてるんだよね？
0549デフォルトの名無しさん
2011/11/26(土) 20:01:17.16お互いに不完全だけどね
0550デフォルトの名無しさん
2011/11/26(土) 20:11:11.780551デフォルトの名無しさん
2011/11/26(土) 20:21:34.910552デフォルトの名無しさん
2011/11/26(土) 23:38:28.720553デフォルトの名無しさん
2011/11/27(日) 00:13:35.710554デフォルトの名無しさん
2011/11/27(日) 00:33:36.04状況というやつじゃない？You learn a Haskell ...の最後になんで
Zipperなのかがよく分かる流れだったよ。
0555デフォルトの名無しさん
2011/11/27(日) 01:03:33.62どっちがデフォルトが嬉しい？って話に尽きるのでは
eagerな言語では、Haskellとは逆に遅延評価したい処理をモナドに包んだりするわけでさ
まあ、普通のプログラマである俺にはlazyがデフォルトは厳しいわ
0556デフォルトの名無しさん
2011/11/27(日) 07:02:48.01レベル高すぎて中々書き込めないけど、たまに書き込んでますよ
何ヶ月か前に数学セミナーで圏論の連載が始まるって書いたのも私だったり
(今月号で5回目だから、だいぶ前か)
0557デフォルトの名無しさん
2011/11/27(日) 09:02:38.230558デフォルトの名無しさん
2011/11/27(日) 09:35:18.56>どっちがデフォルトが嬉しい？って話に尽きるのでは
いや、それはHaskellの特徴のほんの一部じゃないか
遅延評価よりも重要なものがいくらでもあると思う
型クラス、純粋さ、インデント構文、マクロとか
0559デフォルトの名無しさん
2011/11/27(日) 09:45:37.550560デフォルトの名無しさん
2011/11/27(日) 09:54:50.500561デフォルトの名無しさん
2011/11/27(日) 09:58:05.99具体的には、閉じ括弧を書かなくて良い場面が多いので、
関数の最後の引数にdoやラムダ式を書いたり、
激しくネストした関数呼び出しを書いたりしても見難くなりにくい
これはコーディングスタイルにかなり影響を与えてると思う
閉じ括弧が少なくなるのはインデント構文だけじゃなくて
$の影響もあるけど
0562デフォルトの名無しさん
2011/11/27(日) 11:20:32.71cleanで代替できるわけか
0563デフォルトの名無しさん
2011/11/27(日) 11:34:04.55横レスだが、個人的には見やすいので助かってる。
プログラミング始めた頃は、これパースしにくいだろ
センス無いなーと思ってたけど、使って行くうちに
インデント以外の事(データ構造とか)で頭を悩ます
ようになったんで、パット見判るのが良い。
0564デフォルトの名無しさん
2011/11/27(日) 12:05:29.29開発が止まってるやんけ
0565デフォルトの名無しさん
2011/11/27(日) 12:05:41.98読みやすくなる。あれだけ括弧のことを言われるlispでも実は
インデントでソースを読んでいるくらい。
0566デフォルトの名無しさん
2011/11/27(日) 14:52:58.70つまりハスケルの開発もすぐ止まっちゃうの？
0567デフォルトの名無しさん
2011/11/27(日) 17:09:30.54インデント構文は忘れた頃にコードに手を入れようとするとひどい目に合う
haskellでも文脈自由構文使う
インデント構文以外選べないpythonは使わない
0568デフォルトの名無しさん
2011/11/27(日) 17:45:13.36「あいつのコード読みにくい。どうしてインデント構文つかわねえんだ」
と陰口叩かれる
0569デフォルトの名無しさん
2011/11/28(月) 00:16:13.44Haskellの場合、関数型言語特有の技術の有効性を検証する目的で作られた一面もあるから、まず開発が止まることはない
0570デフォルトの名無しさん
2011/11/28(月) 00:21:33.60どっちかと言うと、忘れたころに読み直す時にこそ、インデント構文の方が読み直しやすいと思うんだが、痛い目って、手直しでインデントがズレまくるとか？
単に関数にまとめるのが下手なだけちゃうんかと
0571デフォルトの名無しさん
2011/11/28(月) 00:27:44.32でかいファイルの読み込みでしょっぱな困る
コード上は無限リストで一気に全部読み込んでるように見えて、遅延評価で必要になった分ずつ読み込んでいくからメモリがパンクしないのに、遅延評価が無かったら、プログラマの方でメモリがパンクしないように気をつかわにゃならん
0572デフォルトの名無しさん
2011/11/28(月) 00:30:59.170573532
2011/11/28(月) 01:07:30.76しばらく待ってみたが、残念な解答ばかりだな
>>532では明確に書いていなかったけど、もしも「お題」を書くとしたら、
モナドを使わずに「読んで; 計算して; 書く」という処理をHaskellで書きなさい
ここで、ごく単純な逐次処理なのだから、再帰の使用は禁止します
というものになる。後だし条件かもしれないが、それくらいは推測できるだろ？
>>532では「(Haskellじゃ)IOモナドを使わなければコードが書けない」と書いてあるんだから
Haskellのdo記法や>==はモナド向けの構文糖だ
お前等はそんなことも知らないナンチャッテ・ハスケラなのか？
Haskellという言語の表層だけで満足して酔っているお前等は「ドカタ・ハスケラ」だ
0574デフォルトの名無しさん
2011/11/28(月) 01:40:12.960575デフォルトの名無しさん
2011/11/28(月) 02:11:32.120576デフォルトの名無しさん
2011/11/28(月) 05:43:18.62そりゃcleanも同じだ
Haskellだけ特別だと思ってる？
0577デフォルトの名無しさん
2011/11/28(月) 07:35:43.93正格なHaskellなら間違いなくiteratee使うだろ
0578デフォルトの名無しさん
2011/11/28(月) 07:38:25.72>モナドを使わずに「読んで; 計算して; 書く」という処理をHaskellで書きなさい
「モナドを使わずに」なんて妙な条件を読み取れって方が無茶だろｗ
もともと
>SMLなら以下のような明解なコードになる
と書いてあったから、モナドを使って同様に明快なコードになることを示しただけ
0579デフォルトの名無しさん
2011/11/28(月) 07:45:37.09Haskellのdoならすごく読み易くない？
(>>=)やラムダを多用したコードの方が汚く見える
Haskellに限らず逐次実行のための仕組み一般(OCamlの;とかも)を指しているなら、
それなしでどうやってプログラム書くのか
0580デフォルトの名無しさん
2011/11/28(月) 08:09:58.63異論は認める
0581デフォルトの名無しさん
2011/11/28(月) 09:18:03.28>==が>>=のタイポだとしてもお前話にならないから帰っていいよ。
0582デフォルトの名無しさん
2011/11/28(月) 09:43:06.230583デフォルトの名無しさん
2011/11/28(月) 11:25:50.20そもそも「読んで計算して書く」って、それ自体が手順だしな…
手続き的に書くほうが自然だし、ちゃんと要所でそれが出来るのがHaskellなんだし
0584デフォルトの名無しさん
2011/11/28(月) 11:33:31.020585デフォルトの名無しさん
2011/11/28(月) 13:14:13.04副作用のある手続きの中に計算を入れるのは他の言語と大差ない。
0586デフォルトの名無しさん
2011/11/28(月) 15:31:59.75どうしても避けられないところはあるけど、極力避けてるよ。
doの中ってやっぱり手続き臭が強くって、あのクサさは最悪だと感じてるから。
まるで卵の腐った匂いだ。
0587デフォルトの名無しさん
2011/11/28(月) 16:30:50.720588デフォルトの名無しさん
2011/11/28(月) 18:23:53.51だったら手続き型ベース+関数型スタイルでいいだろうとなる。
にもかかわらず関数型マンセーなのは矛盾を感じるな。
>>586 のハスケル原理主義のほうがかえって好感が持てる。
0589デフォルトの名無しさん
2011/11/28(月) 18:31:41.98まさかHaskeller対その他になるとはな。
0590デフォルトの名無しさん
2011/11/28(月) 19:04:37.27HaskellもMLも十分、手続き型言語とのハイブリッドだよ
逐次実行、破壊的代入、複雑な入出力、どれも避けて通れないアプリは多いんだから、
これらをうまく書けないような言語は汎用言語として欠陥がある
>だったら手続き型ベース+関数型スタイルでいいだろうとなる。
それよりも関数型ベース+手続きスタイルが良いと思ってる奴がHaskellとかMLを使ってるだけ
0591デフォルトの名無しさん
2011/11/28(月) 20:29:45.70手続き型「にも」利点があるし、そのほうが書きやすく直感的な処理もある
0592デフォルトの名無しさん
2011/11/28(月) 20:58:07.30できるだけ関数型で書いて、副作用を少なくする
効率やどうしても副作用が必要なところは関数やマクロに閉じ込める
というのが良いと思ってる。
0593デフォルトの名無しさん
2011/11/28(月) 21:52:28.860594デフォルトの名無しさん
2011/11/28(月) 22:15:34.63卵の腐ったのが嫌いな人なんですが、同感です。
最初は、副作用が無い版をつくってチューニングしてだんだん形にしていく。
0595デフォルトの名無しさん
2011/11/28(月) 22:21:54.52デバッグのやりやすさだと思うよ。手続き型の書き方を利用していくと
関数の作用が、複数にまたがるために、エラー箇所の見積もりが面倒になる。
一つくらいだったら、さほど問題はないけど、複数同じようになってみたら
ちゃっちゃと作っていく関数型スタイルを壊すだけになるんだよ。トレース
にしてもプロファイルにしても煮詰める箇所を定めやすい。
だから、一つ一つの関数の作りはシンプルでというのは、自分の中では鉄則。
でも、doなんて多様するとね。。。あとが大変なのよ。
0596デフォルトの名無しさん
2011/11/28(月) 23:37:26.500597デフォルトの名無しさん
2011/11/28(月) 23:49:48.58then
〜
else
〜
と書けないのが悲しい
0598デフォルトの名無しさん
2011/11/28(月) 23:50:44.170599デフォルトの名無しさん
2011/11/29(火) 00:26:59.17この人１７歳でClojureの本を出すらしい。最初の言語はHaskellと言って
るとのこと。
0600デフォルトの名無しさん
2011/11/29(火) 00:29:11.480601デフォルトの名無しさん
2011/11/29(火) 00:31:33.65as a first language would make OOP languages be as difficult to learn
and understand as functional languages are to OOP developers.
My answer, given my experiences, is no.
Learning a functional language first gave me the programming
foundations that I needed to understand OOP and how it compared
to other paradigms.
と答えてるな。
0602デフォルトの名無しさん
2011/11/29(火) 01:06:33.44関数型のおかげでOOPの習得に必要なプログラミングの基礎も身についたお
だから初心者も関数型から入ったらいいお！Prolog最高だお！
ってことか
0603デフォルトの名無しさん
2011/11/29(火) 05:06:14.90Scratchは色々な国の小学生に使われているよ。
しかもSmalltalkで改造されたパーツが小学生間で流通してるよｗ
0604デフォルトの名無しさん
2011/11/29(火) 07:15:13.10Haskell 2010では書けるようになった
0605デフォルトの名無しさん
2011/11/29(火) 10:19:26.34良識人登場
0606デフォルトの名無しさん
2011/11/29(火) 11:46:44.56汎用言語なんてあったか？
0607デフォルトの名無しさん
2011/11/29(火) 12:50:17.46だから。。。何？
0608デフォルトの名無しさん
2011/11/29(火) 19:02:18.260609デフォルトの名無しさん
2011/12/02(金) 02:32:46.15C++だってtemplateは純粋関数型言語だし
まぁあれは構文が腐っているけど
0610デフォルトの名無しさん
2011/12/02(金) 07:46:44.410611デフォルトの名無しさん
2011/12/03(土) 06:10:29.62むしろ、elseなしが書けないわけですが・・・
パターンマッチあるから、困ることもないんだが
0612デフォルトの名無しさん
2011/12/03(土) 09:21:52.540613デフォルトの名無しさん
2011/12/03(土) 22:07:14.99入力のソースを変形して出力するという処理だから関数型に適している
0614デフォルトの名無しさん
2011/12/04(日) 19:41:46.01関数型「のほうが上手く」できるってのは
ずいぶん違う話だぞｗ
0615デフォルトの名無しさん
2012/01/18(水) 12:42:04.490616デフォルトの名無しさん
2012/01/18(水) 14:07:49.720617デフォルトの名無しさん
2012/01/18(水) 18:10:14.27ど真ん中にはショボいトイプログラムしかないけどな。
0618デフォルトの名無しさん
2012/01/18(水) 18:51:15.480619デフォルトの名無しさん
2012/01/18(水) 18:54:56.640620デフォルトの名無しさん
2012/01/18(水) 21:37:38.510621デフォルトの名無しさん
2012/01/18(水) 23:00:49.280622デフォルトの名無しさん
2012/01/18(水) 23:16:20.34人間だっていろいろな言語に対応できたほうが良いだろうに。
関数型は使えないとか、俺は馬鹿ですって言ってるようなもんだ。
0623デフォルトの名無しさん
2012/01/19(木) 01:15:47.03馬鹿の一つ覚えみたいにそればかり使わない
っていうのが一番尊敬出来るし信用出来る
0624デフォルトの名無しさん
2012/01/19(木) 01:16:59.89強制しないってのもな
不況は勘弁
0625デフォルトの名無しさん
2012/01/19(木) 01:17:41.43ｏ布教
0626デフォルトの名無しさん
2012/01/19(木) 04:48:42.830627デフォルトの名無しさん
2012/01/19(木) 07:49:43.56関数型言語使えるなら、コード書いてちょ
0628デフォルトの名無しさん
2012/01/19(木) 21:54:43.61細かなIO制御は難しいが, 高速演算とかならLISPでもできるな
最近はそうでもないが， 高速演算/並列演算を最適化する研究は
FORTRANとLISP中心で行われていた
LISPは関数型じゃないって言ってしまえばそれまでだけど
0629デフォルトの名無しさん
2012/01/19(木) 23:28:34.37語感から推測する限りでは別に関数型と相性が悪いようには思えない
0630デフォルトの名無しさん
2012/01/21(土) 00:44:47.58GCは、関数型言語でしか採用されてないわけじゃないし、
計算速度で言ったら、C言語かFORTRANしかいらないのかってことになるし、
批判が的外れなんだよね。
0631デフォルトの名無しさん
2012/01/21(土) 12:19:36.90どうしてIO制御はメモリ管理のことだと思った？
どっかから謎電波を受信しちゃった？
関数型言語使うやつって、みんなこんな馬鹿ばかりなの？
0632デフォルトの名無しさん
2012/01/21(土) 12:56:53.35×）関数型言語使うやつって、みんなこんな馬鹿ばかりなの？
○）Haskell使うやつって、みんなこんな馬鹿ばかりなの？
0633デフォルトの名無しさん
2012/01/21(土) 13:58:29.84理解出来ないから、使えないことにしたいんだろ。
0634デフォルトの名無しさん
2012/01/21(土) 19:40:42.50構文解析くらいか？
0635デフォルトの名無しさん
2012/01/21(土) 22:14:01.840636デフォルトの名無しさん
2012/01/22(日) 13:12:11.54IO制御を何のことだと思ってるだろう？
謎電波受信かｗ
やっぱ馬鹿だな。
0637デフォルトの名無しさん
2012/01/22(日) 13:52:08.59アホ呼ばわりされてるじゃんw
tail -f じゃないよ？ただのtailだよ？
0638デフォルトの名無しさん
2012/01/22(日) 14:06:08.39ねえ、どうしてIO制御はメモリ管理のことだと思い込んじゃったの？
哂ってあげるから正直に書いてみてごらん？
0639デフォルトの名無しさん
2012/01/22(日) 16:04:04.23あほやの〜ｗ
0640デフォルトの名無しさん
2012/01/22(日) 16:09:50.340641デフォルトの名無しさん
2012/01/22(日) 16:39:50.06自分は＋演算子と同じ動きする演算子を定義しようとして、数字から再定義してペアノの公理（succ)作っちゃったけど、数学とはすごく相性良いね
自然数しか扱えないのを作ったけど、整数・分数への拡張はすぐ出来る自身はある
少数は・・・カウンタブルな無限じゃないから、独自定義は無理かな・・・
柔軟性と実行速度だけなら、ＬＬを上回ってると思うよ
（ghciやrunghcだとＬＬより遅いけど、コンパイルできる形にしてghcで実行ファイルにするとＬＬより１００倍速くらいになる）
あと、ＬＬが得意とする文字列処理はＨａｓｋｅｌｌの方に軍配が上がる
Ｗｅｂ系はＬＬよりＨａｓｋｅｌｌで作ったほうが楽なんじゃなかろうか
構文解析と繋がるけど、こんなブログ記事もある
正規表現を超える
http://d.hatena.ne.jp/kazu-yamamoto/20090309/1236590230
0642デフォルトの名無しさん
2012/01/22(日) 16:51:10.57succで四則演算から再定義して大量の整数演算しても
コンパイルすればLL言語よりも１００倍速くなるのか？
にわかには信じられない話だなあ。
0643デフォルトの名無しさん
2012/01/22(日) 16:51:42.69LLの文字列操作の方がずっと速い（Cで実装されてるし）
0644デフォルトの名無しさん
2012/01/22(日) 17:43:40.79Haskellスレは実用より理論な人が集まってるからなあ
0645デフォルトの名無しさん
2012/01/22(日) 17:58:59.11ただし、同じアルゴリズムに限る
が、頑張ればＬＬと同じアルゴリズムは書けるよ
自分は、アルゴリズムやデータ構造の専門家じゃ無いが、ググレばづぐ出るし、分かりやすい
（それを言ったら、Ｃの（ｒｙ）
0646デフォルトの名無しさん
2012/01/22(日) 22:12:54.54seekしてファイルの末尾から順番に読む程度のコードが書けなくて
理論もクソもあるか
0647デフォルトの名無しさん
2012/01/23(月) 04:55:33.71書けるかどうかじゃなくて、
Haskellでsuccで再定義された四則演算が
LL言語のビルトイン四則演算の１００倍速いのかと
訊いているのだが？
0648デフォルトの名無しさん
2012/01/23(月) 06:27:37.62そんなの、succのが遅いに決まってるだろ
ＨａｓｋｅｌｌのビルトインとＬＬのビルトインを比較しない理由は？
0649デフォルトの名無しさん
2012/01/23(月) 10:10:20.41X 実用、理論
O ルーチンワーク、これから開拓
0650デフォルトの名無しさん
2012/01/23(月) 10:20:33.990651デフォルトの名無しさん
2012/01/23(月) 23:07:48.08じゃあ何のためにsuccを定義するの？
0652デフォルトの名無しさん
2012/01/24(火) 07:03:06.28haskellだと、あらゆるものを抽象化出来るって聞いたから、じゃあ+演算子と同じものを独自実装出来るんかいな？と、作ってたら、数字も抽象化する必要があって、知らん間にsuccになった
ありていに言えば、ただの興味本位だよ
0653デフォルトの名無しさん
2012/01/24(火) 07:05:27.270654デフォルトの名無しさん
2012/01/24(火) 08:28:59.22ただの興味本位ってわけじゃないと思うぞ。
0655デフォルトの名無しさん
2012/01/24(火) 18:49:02.06で、それがどうして「使える」ことにつながるの？
0656デフォルトの名無しさん
2012/01/24(火) 20:45:38.30こういう基本的な関数を定義するのは、別に関数型にかぎらずに、
似たような処理をするところは、同じように書きましょう。
出来れば同じ関数を使いましょうってことで、そうすれば書く量も読む量も減って
メンテナンスしやすくなる。
0657デフォルトの名無しさん
2012/01/25(水) 07:20:58.08?
使えるって？
succ自体は糞の役にもたたんよ？
言語としての抽象度が高いからこそ簡単に書けるんだろうなって書いてて思っただけで
0658デフォルトの名無しさん
2012/01/25(水) 09:25:48.950659デフォルトの名無しさん
2012/01/25(水) 11:18:22.60関数型言語の特徴とは思えんのだが
0660デフォルトの名無しさん
2012/01/25(水) 11:21:01.470661デフォルトの名無しさん
2012/01/25(水) 13:06:55.360662デフォルトの名無しさん
2012/01/25(水) 17:17:09.53別にHaskellである必要は全然ないな
0663デフォルトの名無しさん
2012/01/25(水) 17:34:43.44その上でsuccやadd等を定義すればいいだけ。
typedef unsigned int nat;
nat succ(nat n) {
return n+1;
}
nat add(nat n1, nat n2) {
if ((int)n1)
return add(n1-1, succ(n2));
else
return n2;
}
0664デフォルトの名無しさん
2012/01/25(水) 17:41:51.34それだとunsignedを使ってるから、自然数を自分で定義していない
0665デフォルトの名無しさん
2012/01/25(水) 17:44:43.73じゃあunsignedを取ればいいｗ
まあunsignedがあろうがなかろうが、その構造をsucc関数で構成した上で
addを定義しているのだから、ペアノ自然数の実装として何の問題もない。
0666デフォルトの名無しさん
2012/01/25(水) 17:47:11.800667デフォルトの名無しさん
2012/01/25(水) 17:49:03.600668デフォルトの名無しさん
2012/01/25(水) 17:49:14.670669デフォルトの名無しさん
2012/01/25(水) 17:51:04.11int=32bit とは限らないよｗ
ちなみに扱える自然数の数に上限があるのはHaskell等の関数型言語も同じ。
0670デフォルトの名無しさん
2012/01/25(水) 17:53:25.08君が定義した自然数で2^128を求めてみてよｗ
多倍長整数にマップすれば問題ないが、
例えばHaskellあたりの代数データ型では無理だと思うよｗ
0671デフォルトの名無しさん
2012/01/25(水) 17:58:42.79有限のリソースをもった計算機上で全ての自然数を列挙できないのは別の話
0672デフォルトの名無しさん
2012/01/25(水) 18:01:23.89「自然数とは、0か、自然数の後者である」
をなるべく自然にプログラミング言語に翻訳したものだと思ってたけど違うの？
0673デフォルトの名無しさん
2012/01/25(水) 18:03:28.47if(n == UINT_MAX)exit(-1);
return n+1;
}
これで循環しない
0674デフォルトの名無しさん
2012/01/25(水) 18:51:53.51Haskellは上限無いと思うんだけど、、、
0675デフォルトの名無しさん
2012/01/25(水) 22:22:43.79必ず上限がある。
だから自然数は決して実装できない。
0676デフォルトの名無しさん
2012/01/26(木) 04:49:09.80式の内部表現のグラフノードのポインタのビット数が決まっているからダメ
0677デフォルトの名無しさん
2012/01/26(木) 06:32:42.87「数学と相性が良い」ってのも同様。
MathematicaやMaximaはHaskellより
よっぽど数学寄りだが使い道は限定されている。
構文解析と教育、マの趣味としては活躍する
0678デフォルトの名無しさん
2012/01/26(木) 06:57:37.66+の逆演算である-を使っちゃいかんだろ
+も-も使わず定義汁
自分は元々+演算子の再定義でsucc作ったんだぞ？
つまり、-演算子も同時に再定義してる
0679デフォルトの名無しさん
2012/01/26(木) 07:12:41.65(さすがに=は使わないと定義出来ないんで使うけど)
0680デフォルトの名無しさん
2012/01/26(木) 11:20:15.81つかこんなのC以外なら簡単。
その言語が使えるかどうかの指標にならない
0681デフォルトの名無しさん
2012/01/26(木) 12:12:09.43succ = lambda x : (x,)
pred = lambda x : x if x == zero else x[0]
itr = lambda f, x, y: x if y == zero else itr(f, f(x), pred(y))
add = lambda x, y: itr(succ, x, y)
sub = lambda x, y: itr(pred, x, y)
mult = lambda x, y: itr(lambda z: add(x, z), zero, y)
def quo_and_mod(q, x, y):
r = sub(x, y)
if r == zero: return (succ(q), zero) if x == y else (q, x)
else: return quo_and_mod(succ(q), r, y)
quo = lambda x, y: quo_and_mod(zero, x, y)[0]
mod = lambda x, y: quo_and_mod(zero, x, y)[1]
0682デフォルトの名無しさん
2012/01/26(木) 13:11:29.220683デフォルトの名無しさん
2012/01/26(木) 17:40:08.76ちなみにクロージャは関数型由来じゃないよｗ
0684デフォルトの名無しさん
2012/01/26(木) 21:59:36.020685デフォルトの名無しさん
2012/01/27(金) 04:32:17.58Haskellこそ至高みたいな意見は鼻につく
succが書けた程度で言われると特に
0686デフォルトの名無しさん
2012/01/27(金) 05:57:42.32今でもオブジェクト指向にケチつけてるハスケラがいるねぇｗ
0687デフォルトの名無しさん
2012/01/27(金) 06:02:24.040688デフォルトの名無しさん
2012/01/27(金) 07:52:17.630689デフォルトの名無しさん
2012/01/27(金) 08:45:24.18後出しかよ。
口だけじゃなくてその根拠となってる比較のコードを書いてくれ。
0690デフォルトの名無しさん
2012/01/27(金) 10:25:36.30ほう、>>663のやり方なら整数比較でOKだが、それより簡単なのかｗ
0691デフォルトの名無しさん
2012/01/27(金) 12:17:34.48lt = lambda x, y: sub(y, x) != zero
ne = lambda x, y: gt(x, y) or lt(x, y)
eq = lambda x, y: not ne(x, y)
0692デフォルトの名無しさん
2012/01/27(金) 13:07:52.77この一行をsucc型定義の下に追加するだけ
0693デフォルトの名無しさん
2012/01/27(金) 13:21:01.28いや、Ordはderiveするだけじゃダメだろ
0694デフォルトの名無しさん
2012/01/27(金) 13:21:21.03関数型言語の特徴ではないような
仮に副作用を認めるunsafeHaskellみたいなものが存在しても
同じように書けるだろう
MLやLISPみたいな手続き型の言語に対して関数型言語は参照透明という制約が増えているから
ミスを減らせるとかの利点はあっても簡単にかけるってことはないんじゃないの？
0695デフォルトの名無しさん
2012/01/27(金) 13:22:10.80え、出来てるけど。。。
0696デフォルトの名無しさん
2012/01/27(金) 13:25:37.41え、MLもLispも一般的には関数型言語と言う認知だと思うけど。。。
まさかλ計算由来のラムダが関数型言語由来の機能じゃないとは言わないよね？
0697デフォルトの名無しさん
2012/01/27(金) 13:27:26.39まさか、ラムダ計算が関数型言語由来だとか
馬鹿なことは言い出さないよなw
0698デフォルトの名無しさん
2012/01/27(金) 13:33:20.72いやこのスレの上の方の流れだと
OCamlerがHaskellerを煽ってる感じだったから
0699デフォルトの名無しさん
2012/01/27(金) 14:17:40.620700デフォルトの名無しさん
2012/01/27(金) 14:19:11.80いや、>>663が使っている-はintの-であってnatの-じゃないからOKだろｗ
0701デフォルトの名無しさん
2012/01/27(金) 14:22:01.28全ソースplz
0702デフォルトの名無しさん
2012/01/27(金) 15:03:08.87なんだ。succを自分で書くなんてマゾいこと言うから
全部自分で書くのが好み（お勉強目的）なのかと思ったが、そうでもないの？
だったら>>681は何も書かなくても ==, !=, >, < で比較できる
http://ideone.com/ui1NR
0703デフォルトの名無しさん
2012/01/27(金) 15:48:04.82MLは手続き的だろ
定義すら上から順番に実行（？）される
0704デフォルトの名無しさん
2012/01/27(金) 17:12:45.320705デフォルトの名無しさん
2012/01/27(金) 17:33:38.710706デフォルトの名無しさん
2012/01/27(金) 17:59:32.58ラムダがあれば関数型言語になるなら
今時の言語は大抵関数型言語になっちゃうんだが
perlやPHPやmatlabが関数型言語なのか？
0707デフォルトの名無しさん
2012/01/27(金) 18:54:16.66行単位でシャッフルしたら構文エラー出まくりなんだがｗ
0708デフォルトの名無しさん
2012/01/27(金) 18:59:58.310709デフォルトの名無しさん
2012/01/27(金) 20:44:08.00ラムダが有れば関数型言語とは言ってないだろ
ラムダが関数型言語由来の機能だと言ってるだけだろ
0710デフォルトの名無しさん
2012/01/27(金) 21:22:41.20>>697を100回読み直せ
0711デフォルトの名無しさん
2012/01/28(土) 02:35:31.04> >>699
> MLは手続き的だろ
> 定義すら上から順番に実行（？）される
それは名前のスコープをどう定めているかの問題であって手続き型言語か関数型言語かとは別問題。
OCamlなどのML一族の言語は関数型原理主義の立場から言えば手続き型言語だけれど、関数型言語として認識しているのが（恐らく圧倒的な）多数派。
MLの場合、どうしても必要となればref型の変数を用いた破壊的代入が使えるというだけで、普段はほとんど使用せずに書かれているから。
（バグなどで異常終了した場合のデバッグ用の情報を自分で残したい場合なんかには、ref型への代入があるのはとても便利。
あれがなければ多くのLisp環境みたいに専用のデバッガやトレーサーが用意されてないとMLプログラムのデバッグ作業は難しいと思う）
なお、>>696の
> え、MLもLispも一般的には関数型言語と言う認知だと思うけど。。。
Lisp、特にScheme以外のポピュラーなLispを関数型言語という認識は今では少数派だと思う。
現実のLispプログラミングは昔からPROGフィーチャーをガンガン使った手続き的なコーディングが占める比率が高いからね。
Schemeにもグルーピングのためのbegin式があるが、他のLispにおけるPROGほどには使われているようには見えないし、
高階関数を用いたプログラミングの比率は恐らくSchemeは他のLispよりもかなり高いと思う。
（プログラミングの教科書や参考書を見ても、Scheme以外のLispに対するテキストは高階関数の活用なんかには
それほど力を入れていないのに対して、Schemeプログラミングの教科書は高階関数をどうやって活用するかに相当な比重を
置いて書かれているものが多い。特にIndiana学派の連中が書いたSchemeの教科書や参考書はその傾向が顕著）
0712デフォルトの名無しさん
2012/01/28(土) 03:36:22.86名前のスコーピングだけの問題じゃねーだろ
IOだって副作用なんだからref使わなくても順序は発生する
これ実行してみろよ
let f () = print_endline "aaa"
let _ = f ()
let f () = print_endline "bbb"
let _ = f ()
0713デフォルトの名無しさん
2012/01/28(土) 04:41:28.60マクロは1つのリストしか返せないので複数のトップレベルdefineを
行うマクロを実現するにはbeginは特殊化されてないといけない
CLではどうだったかな
0714デフォルトの名無しさん
2012/01/28(土) 04:42:36.260715デフォルトの名無しさん
2012/01/28(土) 06:36:20.65LispやMLはどうでもいい
0716デフォルトの名無しさん
2012/01/28(土) 07:49:42.20IO に使うファイルハンドラが ref そのものだろ
0717デフォルトの名無しさん
2012/01/28(土) 08:04:14.99out_channelの型は隠蔽されてるからOCaml的にはref型じゃないだろ
それに>>711はそういう意味でref型って言ってないと思うぞ
> MLの場合、どうしても必要となればref型の変数を用いた破壊的代入が使えるというだけで、普段はほとんど使用せずに書かれているから。
それともMLではIOは殆ど使用せずに書かれてるのか？
0718デフォルトの名無しさん
2012/01/28(土) 08:35:57.17だとすると俺には >>712 が何を言いたいのかわからない
0719デフォルトの名無しさん
2012/01/28(土) 08:45:00.13let x1 = e1 in let x2 = e2 in e3
と
let x2 = e2 in let x1 = e1 in e3
で意味が変わるんだよね。
0720デフォルトの名無しさん
2012/01/28(土) 08:47:53.060721デフォルトの名無しさん
2012/01/28(土) 08:52:10.99MLにおいて式が順番に評価されることは
「名前のスコープをどう定めているかの問題」ではない
0722デフォルトの名無しさん
2012/01/28(土) 08:54:27.78let _ = f ()
let f () = print_endline "bbb"
let _ = f ()
これを IO モナドを使って Haskell で書いたら順序の問題が発生しないの？
0723デフォルトの名無しさん
2012/01/28(土) 08:54:57.980724デフォルトの名無しさん
2012/01/28(土) 08:57:03.980725デフォルトの名無しさん
2012/01/28(土) 08:59:50.04誰も順序の問題が発生しないとは言ってない
>>705だと言ってる
0726デフォルトの名無しさん
2012/01/28(土) 09:55:07.42ML(Standard ML)の場合:
let val x=1 in let x=2 in x end end (* Result: 2 *)
let val x=2 in let x=1 in x end end (* Result: 1 *)
Haskell(Gofer)の場合:
let x=1 in let x=2 in x -- Result 2
let x=2 in let x=1 in x -- Result 1
MLは意味が変わるけど、同じくHaskellも意味が変わる
>>720
上で示したように、非正格評価であるHaskellも(スコープの変化に応じて)意味が変わる
>>721の指摘が正しい
おそらく>>719,720は正格評価/非正格評価の意味を誤って解釈していると思われる
0727デフォルトの名無しさん
2012/01/28(土) 09:59:07.38つまり、do記法を構文糖として定義しているHaskellは、
関数型言語であり、かつ手続き型言語でもある、というのが無難な落としどころなのですね
たいへんわかりやすいです
0728デフォルトの名無しさん
2012/01/28(土) 10:04:37.57これはスコープの問題
>>719の例とは違うだろう
0729デフォルトの名無しさん
2012/01/28(土) 10:11:07.62>334 名前: 283 Mail: sage 投稿日: 2011/09/29(木) 18:17:12.26
>>>298,323
>
>FP
> ---- 壁0. 変数の壁 ----
>Haskell
> ---- 壁1. 純粋性(副作用)の壁 ----
>SML/OCaml
> ---- 壁2. 型推論の壁 ----
>Scheme
> ---- 壁3. 末尾再帰最適化/局所定義式の壁 ----
>========<< 越えられない壁 >>========
>Smalltalk/Ruby
> ---- 壁4. 条件判定式の壁 ----
>Perl/Python/JavaScript
> ---- 壁5. クロージャ/ラムダ式の壁 ----
>========<< 越えられない壁 >>========
>C/C++/Java...etc
0730デフォルトの名無しさん
2012/01/28(土) 10:12:46.18ってのは、MLなら
x = M;
N
だが、Haskellなら
#define x (M)
N;
ということだな。
#define の順序を入れ替えても意味は変わらない。
0731726
2012/01/28(土) 10:19:22.14では、変数束縛を隠蔽しないコードの例だ
こちらの例のほうが、(>>726よりも)>>719の例に近いだろうと思う
ML(Standard ML)の場合:
let val x=1 in let val y=2 in x-y end end (* Result: ~1 *)
let val y=2 in let val x=1 in x-y end end (* Result: ~1 *)
Haskell(Gofer)の場合:
let x=1 in y=2 in x-y -- -1
let y=2 in x=1 in x-y -- -1
変数束縛が隠蔽されなければ、MLもHaskellも意味は変わらない
もし反論あるなら、MLとHaskellで結果が変わる(>>719ではない)例の提示をキボン
0732デフォルトの名無しさん
2012/01/28(土) 10:20:21.53do
a <- x
b <- y
return a + b
これは次の構文糖だよ？
x >>= (\a -> y >>= (\b -> return a + b))
順序を関数合成で表すからこそ純粋関数型言語なわけよ
MLは順序を関数以外で表現するから手続き型言語と言われるわけ
0733デフォルトの名無しさん
2012/01/28(土) 10:21:52.71>だが、Haskellなら
>#define x (M)
>N;
>
>ということだな。
>#define の順序を入れ替えても意味は変わらない。
いったい、とことどこを「入れ替えた」の？
日本語として意味不明な文章だ
0734デフォルトの名無しさん
2012/01/28(土) 10:21:58.05前書いたのそのままで良ければ
-- 自然数を定義
data NaturalNum = Zero | PlusOne NaturalNum
deriving (Eq,Ord,Show,Read)
-- 加算を定義
Zero +^ n = n
m +^ Zero = m
m +^ n = inc m +^ dec n
-- 減算を定義
Zero -^ n = n
m -^ Zero = m
m -^ n | m == n = Zero
m -^ n = dec m -^ dec n
-- インクリメント（１＋）を定義
inc n = PlusOne (n)
-- デクリメント（１−）を定義
dec (PlusOne (n)) = n
-- 自然数を独自自然数へ変換
int2NaturalNum 0 = Zero
int2NaturalNum n = PlusOne (int2NaturalNum (n-1))
-- 独自自然数を自然数へ変換
naturalNum2int Zero = 0
naturalNum2int n = 1 + naturalNum2int (dec n)
0735デフォルトの名無しさん
2012/01/28(土) 10:26:57.31$ cat a.txt
#define F(UNIT) print_endline "aaa"
#define UNDER_SCORE F(UNIT)
#define F(UNIT) print_endline "bbb"
#define UNDER_SCORE F(UNIT)
$ cpp a.txt
# 1 "a.txt"
# 1 "<built-in>"
# 1 "<command-line>"
# 1 "a.txt"
遅延評価では何もしない
0736デフォルトの名無しさん
2012/01/28(土) 10:31:13.94ML(Standard ML)で順序を表すには、;(セミコロン)演算子を使う
そして、>>732のような手続きの表現には、;演算子と参照型を組み合わせる
! a x ; ! b y ; a + b
ここで、;演算子は2引数で常に後者を返すという、まさしく関数であるけれど、
はたして>>732の目には、 ;演算子が「関数以外」の何に見えているのだろうか？
0737デフォルトの名無しさん
2012/01/28(土) 10:36:55.32>>719のe1やe2の式中でref型使ってれば変わるよ
0738デフォルトの名無しさん
2012/01/28(土) 10:39:38.95自分で参照型「も」使うって書いてるじゃん
0739デフォルトの名無しさん
2012/01/28(土) 10:42:14.170740デフォルトの名無しさん
2012/01/28(土) 10:43:15.330741デフォルトの名無しさん
2012/01/28(土) 10:47:57.48MLが参照型「も」使うから手続き型であるというのなら、
「関数以外」の do「も」使う Haskell も手続き型ということになるよね
それともHaskellにとってdoは関数なのかな？
その場合、関数doの型定義(定義域と値域)は？
0742デフォルトの名無しさん
2012/01/28(土) 10:52:09.04いや、MLはHaskellのdoの中にずっと居るようなもんだと
思えばそうなのか？
0743デフォルトの名無しさん
2012/01/28(土) 10:55:28.86もちろん二つのref型への代入を入れ替えれば、意味が変わるのは当然の事
そして、Haskellにはそもそもref型が存在しないから、入れ替えを行いようが無い
で、何を言いたいの？
0744デフォルトの名無しさん
2012/01/28(土) 10:58:27.42>>719で結果が変わる（かつ未定義にならない）のはMLが正格評価だから
0745デフォルトの名無しさん
2012/01/28(土) 10:58:47.42関数ではありません
Haskellのdoが(「関数以外」の)構文糖であるように....
0746デフォルトの名無しさん
2012/01/28(土) 11:01:48.64表記法法が違うだけで使ってるのは関数
0747デフォルトの名無しさん
2012/01/28(土) 11:03:49.180748デフォルトの名無しさん
2012/01/28(土) 11:11:49.35＞ x >>= (\a -> y >>= (\b -> return a + b))
Haskell わからんのだけど、これって
(lambda a -> (lambda b -> a + b) y) x
と何がちがうの？
0749デフォルトの名無しさん
2012/01/28(土) 11:13:12.74>>>719で結果が変わる（かつ未定義にならない）のはMLが正格評価だから
違うだろw
>>719で結果が変わるのは参照型への代入を使った例外的な場合のみ
それ以外の一般的な式においては、(Haskellと同様に)意味は変わらない(>>731を参照)
Haskellで意味が変わらないのは、参照型が存在しないので入れ替えようがないから
その代わりに(MLにはない)doという「関数以外」のモノが存在する
そして、do記法の中で式を入れ替えれば(MLと同様に)意味が変わる
結局、ここまでの手続き的か否かという議論の中で、正格評価/非正格評価の違いは無関係
あえて関連性を言えば、
非正格評価であるHaskellでは参照透明性がくずれるref型を導入「できない」から、
do記法という「関数以外」の異物を導入した
という点かな
0750デフォルトの名無しさん
2012/01/28(土) 11:17:05.06Haskellの do が「ただの構文糖」にすぎない、というのなら、
MLの ref も「ただのデータ型」にすぎない、としないと>>746は矛盾を抱えるよね？
0751デフォルトの名無しさん
2012/01/28(土) 11:17:13.34let x = ref 0
let f () = x := !x + 1; !x
let a = f () in
let b = f () in
a - b
へー、これで a - b が決定されるのは正格評価と関係ないんだ
あとdoは構文糖だっていってんだろ
表記が違えば関数じゃなくなるのかよ
0752デフォルトの名無しさん
2012/01/28(土) 11:24:53.46関係ないよ。
0753デフォルトの名無しさん
2012/01/28(土) 11:26:05.08机にかじりついて勉強ばかりしている頭でっかちよりも、
時には裏でこっそり「不純な」xx交遊するほうが、生きていて楽しいよねw
私は純粋で品行方正ですなんて、どこかの政治家みたいでかえってうさん臭い
0754デフォルトの名無しさん
2012/01/28(土) 11:29:42.76>>=は二項演算子だから、bind という関数に置き換えて書くと
bind x (lambda a -> bind y (lambda b -> return a + b))
0755デフォルトの名無しさん
2012/01/28(土) 11:30:59.08bind って関数の定義を教えてほしいんですけど・・・
0756デフォルトの名無しさん
2012/01/28(土) 11:32:57.98じゃあこれは？
let a = f () in
let b = f () in
print_int b;
print_int a;
a - b
0757デフォルトの名無しさん
2012/01/28(土) 11:35:10.25bind :: [a] -> (a -> [b]) -> [b]
0758デフォルトの名無しさん
2012/01/28(土) 11:35:42.61>>=は二項演算子だから、bind という関数に置き換えて書くと
bind x (lambda a -> bind y (lambda b -> return a + b))
0759デフォルトの名無しさん
2012/01/28(土) 11:36:19.750760749
2012/01/28(土) 11:36:37.96>へー、これで a - b が決定されるのは正格評価と関係ないんだ
うん、関係ないよ
関係するのはref(参照型)の使用
繰り返しになるけど、refを使わなければ意味はHaskellと同じ(>>731を参照)
あとrefは「ただデータ型」だっていってんだろw
0761デフォルトの名無しさん
2012/01/28(土) 11:38:48.75関係ないよ
正格と非正格で評価順序が違うから、
副作用のある式を評価すれば当然結果は変わるけど、
正格でも非正格でもそれぞれの評価戦略に従って a - b の値は一意に決定されるよ。
0762デフォルトの名無しさん
2012/01/28(土) 11:40:45.020763デフォルトの名無しさん
2012/01/28(土) 11:43:14.27だからrefを使っててもa - bが定まるのは正格評価だからだろ
a = f () と b = f () のどっちを先に評価するかで結果変わるんだから
もし print_int で出力する時点で評価する遅延評価なら
結果が変わっちゃうだろ
0764デフォルトの名無しさん
2012/01/28(土) 11:44:53.23＞a = f () と b = f () のどっちを先に評価するか
それはマイナスという二項演算子の定義の問題
正格評価と全然関係ない
0765デフォルトの名無しさん
2012/01/28(土) 11:48:55.030766デフォルトの名無しさん
2012/01/28(土) 11:51:23.77[a] ってのは何？
0767デフォルトの名無しさん
2012/01/28(土) 11:52:28.110768デフォルトの名無しさん
2012/01/28(土) 11:54:57.030769デフォルトの名無しさん
2012/01/28(土) 11:55:26.270770デフォルトの名無しさん
2012/01/28(土) 11:58:20.28[]はリストじゃない？
一般的には (>>=) :: m a -> (a -> m b) -> m b じゃないの？
Haskell知らんけど（定義はwebからコピった）
OCamlなら
(>>=) : 'a t -> ('a -> 'a t) -> 'a t
return : 'a -> 'a t
0771749
2012/01/28(土) 12:05:23.04だからrefを使わなければ、正格評価でも非正格評価でも結果は同じ(>>731を参照)
そしてrefが使えば結果は変わるけど、そもそもrefの存在が許されるのは正格評価だけで、
非正格評価では(参照透明性が崩れる)refの存在は許されない
もしも非正格評価でrefが使えてかつ結果が同じであれば、
その理由が正格/非正格の違いであると考察する事は正しいと思う
しかし、残念ながら非正格評価ではrefが使えないから、比較そのものが成立しない
従って、両者の差異を決定付ける要因とは、refを使う/使わないという違いであると結論付けられる
ハァ、疲れたョ
ここまで書けば納得してもらえるかな？
0772デフォルトの名無しさん
2012/01/28(土) 12:43:21.61let f () = lazy (x := !x + 1; !x)
let (!$) x = Lazy.force x
let a = f () in
let b = f () in
print_int (!$ b);
print_int (!$ a);
(!$ a) - (!$ b)
lazyで遅延評価するとref型を使ってもletの順番には異存しないよ
0773デフォルトの名無しさん
2012/01/28(土) 13:25:02.71非正格評価のメリットって無限リストを扱えることだけじゃん。
それだけのために失っているものが大きすぎじゃね？
0774デフォルトの名無しさん
2012/01/28(土) 17:34:04.060775デフォルトの名無しさん
2012/01/28(土) 20:16:56.19いや、判ろうとしないだけだ
なんつって
なんつって
orz
0776デフォルトの名無しさん
2012/01/28(土) 20:26:38.85汎用のリスト型(aとかbとかのちゃんとした名前は代数型とか何とか言ってた気がする)
リストの中身はどんな型でもおk(ただし、中身各要素の型は同じ型で統一しないとダメ)
c++のテンプレートとか、c#,javaのジェネリックみたいなもん
0777aaa ◆sVVR0Q7eM2
2012/01/31(火) 11:47:27.110778デフォルトの名無しさん
2012/02/01(水) 09:43:15.150779デフォルトの名無しさん
2012/02/01(水) 14:21:12.28var という暗黙の型を持つことができます。
暗黙的に型指定されたローカル変数は、型を宣言した場合と同様に厳密に型指定されますが、コンパイラが型を決定します。 次に示す 2 つの i の宣言は、機能的に同じです。
とのことことだが関数の人これどう思う？
static関数でvar でやってけば関数っぽくなるのでは？
0780デフォルトの名無しさん
2012/02/01(水) 14:24:51.69F# はそういった実装になってる。
0781デフォルトの名無しさん
2012/02/08(水) 08:54:16.980782デフォルトの名無しさん
2012/02/11(土) 08:33:29.59タプルとリストで実現できるって、どっかで見かけた。
([3 2 1],[4 5 6])
ポインタを動かす→([4 3 2 1],[5 6]) ([2 1],[3 4 5 6])
方法を取るってことだた。
0783デフォルトの名無しさん
2012/02/11(土) 09:23:30.700784デフォルトの名無しさん
2012/02/11(土) 18:51:21.540785デフォルトの名無しさん
2012/02/12(日) 10:29:33.18int my_strlen(char str[])
{
int i = 0;
for( i = 0; str[i] != '\0'; i++ )
;
return i;
}
Haskellのlength関数の初心者にも分かり易い実装
my_length [] = 0
my_length (x:xs) = 1 + my_length xs
とか見てて思うのは、何というか、実用的とかは知らんけど、（広い意味での）アルゴリズムを学ぶのにＨａｓｋｅｌｌは向いてると思う
ＨａｓｋｅｌｌのコードとＣのコードが同じアルゴリズムで動いてることに気づけば、他の言語でも同じアルゴリズムが使える事が期待できると思う
ところで、CやHaskellみたいに組み込み関数を自分で実装してみようと言う試みが、rubyやpythonではあまり見られないんだが・・・
難しいんだろうか・・・
0786デフォルトの名無しさん
2012/02/12(日) 11:40:42.62まずは自分がアルゴリズムの勉強を勉強してみるべきだと思うがｗ
0787デフォルトの名無しさん
2012/02/12(日) 11:43:53.06ほう、では、アルゴリズムとして違う点を述べよ
スタック消費するとか、そう言う点はアルゴリズムとは無関係だぞ
0788デフォルトの名無しさん
2012/02/12(日) 11:59:06.72これ本質的には一緒だよね。
あと、ループで書くか再帰で書くかの違いで、言語は関係ない。
Haskell以外はどちらでも書ける。
ただ、初心者には、ループで教えるほうがいいよ。
再帰は、末尾再帰最適化されてない言語だとスタック溢れさせてしまって、
余計なところで躓くよ。
0789デフォルトの名無しさん
2012/02/12(日) 12:06:32.35>再帰は、末尾再帰最適化されてない言語だとスタック溢れさせてしまって、
まあそのとおりなんだけど、その理屈だとCはアルゴリズムを学ぶのに適してない言語という事になってしまうな。
0790デフォルトの名無しさん
2012/02/12(日) 12:24:51.220791デフォルトの名無しさん
2012/02/12(日) 12:29:59.85Ｃでなら、ループで教えると言うことと、アルゴリズム教えるのにＣは向いてないと言うこととは無関係ですが・・・
0792デフォルトの名無しさん
2012/02/12(日) 12:31:44.960793デフォルトの名無しさん
2012/02/12(日) 12:34:57.680794デフォルトの名無しさん
2012/02/12(日) 12:37:08.720795デフォルトの名無しさん
2012/02/12(日) 12:42:39.39my_sum n = f n 0
where
f 0 m = m
f n m = f (n-1) (m+1)
main = putStrLn $ show $ my_sum 1000000
Haskellは遅延評価だから末尾再帰で書くだけじゃ不十分なことがある
そういうことも含めて初心者に教えるのは難しいだろう
0796デフォルトの名無しさん
2012/02/12(日) 12:47:36.21と言うか、初心者がそんなでかい数字使うかいな
個人的にはＨａｓｋｅｌｌでアルゴリズムを学んで、Ｃなり普通の言語でそれを活用する。という形を期待してる
そのアルゴリズムがどういう動きをしてるのか？が見えやすいのはＨａｓｋｅｌｌだが、実用には、やはり他の言語が向いてる
0797デフォルトの名無しさん
2012/02/12(日) 13:00:18.66これ特に問題なさそうなのになんで落ちるんだろう？
0798デフォルトの名無しさん
2012/02/12(日) 13:10:20.90fが第二引数に関して正格であることをGHCが見抜けないから。
-Oを付ければ落ちない。
0799デフォルトの名無しさん
2012/02/12(日) 13:16:11.60考えなきゃいけないことが一つ増える
逆に実用レベルなら>>795みたいなのに対処する方法はいくらでもあるし、
プログラマにもそれができることが求められる
0800デフォルトの名無しさん
2012/02/12(日) 14:39:19.48C版は連続メモリ領域の中で、数え上げによるトラバースをして、特定要素として記述された末尾記号を探索している。
Haskell版は代数データ型が提供する木構造の中で、パターンマッチングによるトラバースをして、代数データ型で定義された末尾記号を探索している。
全然違うｗ
0801デフォルトの名無しさん
2012/02/12(日) 15:01:01.20むしろそっちが驚きだわ
0802デフォルトの名無しさん
2012/02/12(日) 16:27:51.86CのクイックソートとHaskellのクイックソートも全然違うアルゴリズムってか
使ってるデータ構造が違うだけで、アルゴリズムは同じだろ
0803デフォルトの名無しさん
2012/02/12(日) 17:24:34.76>>785は初心者向けのアルゴリズム基礎だから、そこはポイントじゃない。
0804デフォルトの名無しさん
2012/02/12(日) 17:37:16.230805デフォルトの名無しさん
2012/02/12(日) 18:30:54.18ランダムアクセス可能な領域を使うのと、単方向リンクによる木構造を使うのと、
同じアルゴリズムとか言い出すのか？
アルゴリズムの基礎からやり直したら？
0806デフォルトの名無しさん
2012/02/12(日) 19:26:23.56日本語の基礎からやり直したら？
0807デフォルトの名無しさん
2012/02/12(日) 19:30:09.57単にカタログ化するための名称で「同一アルゴリズム（ｷﾘｯ」ですかｗｗｗ
0808デフォルトの名無しさん
2012/02/12(日) 19:34:18.96おまえそれ自己矛盾してるよｗ
0809デフォルトの名無しさん
2012/02/12(日) 19:41:29.13アルゴリズム（クイックソート）と、データ構造（配列・リスト）を一緒くたにするな
0810デフォルトの名無しさん
2012/02/12(日) 19:57:11.88おばか？
0811デフォルトの名無しさん
2012/02/12(日) 20:03:51.29それデータ構造の話で、アルゴリズムの話じゃ無いじゃん。
あほか。
0812デフォルトの名無しさん
2012/02/12(日) 20:05:04.80適切なアルゴリズムに適切なデータ構造を選択するのは確かに重要で、リストはHaskellに限らず、配列を使ってクイックソート書くよりも短いコードになるが、配列を使ったクイックソートよりも遅くなる
だから、アルゴリズムとデータ構造を一緒くたにするなと言ってる
0813デフォルトの名無しさん
2012/02/12(日) 21:22:45.910814デフォルトの名無しさん
2012/02/12(日) 21:38:11.930815デフォルトの名無しさん
2012/02/13(月) 02:51:32.45パスカル
名前もそっくりだしな。
0816デフォルトの名無しさん
2012/02/13(月) 06:14:23.48えっと、あんた、メモリモデルって聞いたことある？
アルゴリズムの本なら大抵は説明しているはずだが…
0817デフォルトの名無しさん
2012/02/13(月) 06:15:36.43メモリモデルが異なる言語間で同じアルゴリズムとか、あんた高卒？
0818デフォルトの名無しさん
2012/02/13(月) 12:21:15.07みたいなコメントばかり繰り返してるな。隔離スレらしいといえばそれまでだがな。
0819デフォルトの名無しさん
2012/02/13(月) 16:47:17.36そうかい
メモリモデルとやらは知らんが、日経ソフトウェアやら、関数型言語の本には同じクイックソートとしてCやJavaと関数型言語のコードが平然と比較されてるぞ？
クレームよろしく
0820デフォルトの名無しさん
2012/02/13(月) 17:56:31.120821デフォルトの名無しさん
2012/02/13(月) 20:39:45.19馬鹿を認めるから、メモリモデルっての説明してくれ
単なる感だけど、アルゴリズムの性能比較の用語か何か？
それともアルゴリズムの厳密な定義として>>805みたいなのが決まってるの？
アルゴリズムって、配列使うとか、リスト使うとかに依存しない、もっと抽象的なものだと思ってたんだが
0822デフォルトの名無しさん
2012/02/13(月) 20:53:08.92アルゴリズムを記述する仮想機械のモデル。
ランダムアクセス可能であることが前提ならば、
そのメモリモデルはランダムアクセスモデルと呼ばれ、
仮想機械はランダムアクセスマシンと呼ばれる。
一方、磁気テープやストリームデータのように
逐次的にしか読み書きできないものもある。
それらはランダムアクセスモデルとは区別される。
で、Cの配列はどっちで、Haskellのリストはどちらか
理解できるよな？
0823デフォルトの名無しさん
2012/02/13(月) 21:05:28.43こいつホンマもんのあほや。
初心者が混乱するからやめろ。
0824デフォルトの名無しさん
2012/02/13(月) 23:42:40.09きーつけや〜
0825デフォルトの名無しさん
2012/02/14(火) 04:55:01.03Cのコードを走らせたらどうなるのっと
0826デフォルトの名無しさん
2012/02/14(火) 05:01:31.470827デフォルトの名無しさん
2012/02/14(火) 08:30:33.33わかりました〜。きーつけます〜。
0828デフォルトの名無しさん
2012/02/14(火) 10:36:12.80うーん。。。
データ構造によって実現方法が変わるって言う、当たり前のこと言われてるだけの様な。。。
人間が書類の並び替えにクイックソート使った場合はどっちのモデル？
ランダムアクセス出来るから、Cと同じ？
分割/結合が容易だから、haskellと同じ？
rubyの配列は動的に要素数を変えられるから、ランダムアクセスしながら、haskellっぽく書けるけど、Cと同じモデルなの？
0829デフォルトの名無しさん
2012/02/15(水) 02:34:54.000830デフォルトの名無しさん
2012/02/19(日) 13:25:02.530831デフォルトの名無しさん
2012/02/22(水) 00:59:05.70reverce [] = []
reverce (x:xs) = reverce xs ++ [x]
rubyとかpythonとかだと、reverce関数はどう書くの？
この辺、命令型言語と宣言型言語の違いが出てきそうな気がする
0832デフォルトの名無しさん
2012/02/22(水) 01:24:57.59return [] if lst == [] else reverse(lst[1:]) + [lst[0]]
def reverse(lst)
lst == [] ? [] : reverse(lst[1..-1]) + [lst[0]]
end
パターンマッチング以外は見ための違いはほとんどないね
0833デフォルトの名無しさん
2012/02/22(水) 02:19:38.65832とどっちが効率的かはわからないが。
def rev(l,a=[])
l.inject([]){|a,i|[i]+a}
end
p rev([3,4,5,1,2])
0834デフォルトの名無しさん
2012/02/22(水) 04:30:10.39def rev(l):
return [l[i] for i in reversed(xrange(len(l)))]
reversedが反則だというのなら、
def rev(l):
return [l[i] for i in xrange(len(l)-1,-1,-1)]
でも同じ。ちょっと見た目が不精ったいだけ。
0835デフォルトの名無しさん
2012/02/22(水) 04:46:09.63(比較的)新しい言語だから、単純なreverse関数くらいだと、
手続き型言語(命令型計算モデル)と関数型言語(作用型計算モデル)との違い
は出てこない
同じお題で、FortranやPascalで書けば、違いが分かるのかもしれない
0836デフォルトの名無しさん
2012/02/22(水) 06:17:59.95お言葉ですが、
70年代後半に設計されたSmalltalk-80ですら
>>834のような定義が可能ですが何か？
0837デフォルトの名無しさん
2012/02/22(水) 06:43:25.66まず、オリジナルのSmalltalk-72は関数型言語である
LOGOをヒントに生まれたと伝えられてる
その後、(Smalltalk-76を経て)当時のXROX PARCで広く使われていた
Lispの影響を受け、より洗練された構文のSmalltalk-80が誕生した
だから、Smalltalk-80が関数型作法で書けるのは、ごく当たり前の話
さらに、関数型言語のルーツであるLISPそのものは60年代に誕生している
これはFORTRANやCOBOLの誕生時期とほぼ同じ
つまり、関数型言語そのものは古い技術である、と言える
0838デフォルトの名無しさん
2012/02/22(水) 08:48:18.66関数型言語使いなら普通にfoldlを使おうぜ
reverse = foldl (\xs x -> x:xs) []
0839デフォルトの名無しさん
2012/02/22(水) 12:18:21.92なお、有名なシステムブラウザ画面に代表されるSmalltalk-80のIDE(統合開発環境)であるが、これは
これまたPARCで広く使われたMesaと呼ばれる手続き型言語で書かれたシステムの影響を受けている
また、Smalltalk-80と同時期に誕生したInterlisp-Dにも同様なIDEの研究成果が反映された
結果として、80年代前半のPARC内には、Mesa/Interlisp/Smalltalkという
三つの(パラダイムの異なる)プログラミング言語コミュニティが存在することになった
（他にはCの祖先にあたるBCPLもファームウェア記述用に使われていた）
当然の事として、PARCでは次世代のプログラミング言語について熱い議論が交わされた
そして、最終的に主力言語として決定したのが(Mesaをベースとした)手続き型言語Cedarになる
つまり、80年代前半時点のXEROX PARCで選ばれたのは、
(このスレ的には残念な事であるが、関数型言語ではなく)手続き型言語ということになる
(....などと、無理矢理スレタイに戻してみた)
0840デフォルトの名無しさん
2012/02/22(水) 13:07:10.67今ならSmalltakの統合開発環境で、関数型言語に触れてみるのもいいかもしれない。
ttp://www.pharo-project.org/home
0841デフォルトの名無しさん
2012/02/22(水) 13:57:39.65へ？状態の塊とも言えるLOGOをヒントに関数型言語設計したってこと？
Smalltalk-72にはしっかり「代入」がある上に、
クロージャにいたってはSmalltalk-80ですらナンチャッテ実装だった。
というわけでSmalltalkを関数型言語の傍流であるかのように言うことは
関数型厨の我田引水と言うほかない。
0842デフォルトの名無しさん
2012/02/22(水) 13:59:09.36> (このスレ的には残念な事であるが、関数型言語ではなく)手続き型言語ということになる
おいおい、スレタイ読めよ。残念どころか、非常に歓迎すべきことだろｗ
0843デフォルトの名無しさん
2012/02/22(水) 14:33:26.28代数を基礎とする関数型とは相容れない気がするな
0844デフォルトの名無しさん
2012/02/22(水) 14:45:10.19>へ？状態の塊とも言えるLOGOをヒントに関数型言語設計したってこと？
ん？何か(>>841を)読み違えているよ
まず、LOGOはタートルグラフィック機能ばかり注目されるけど、立派な関数型言語だよ
LISPのcar/cdr/consに相当するリスト処理もプリミティブとして言語仕様に定義されている
実際、LOGOが国内で注目された80年代当時、「LOGOによる記号処理」とか
「LISPとLOGOによるAIプログラミング」のような題名の本が出版されている
そして、(初期の)SmalltalkはLOGOの影響を受けている
まあ、LOGOが関数型言語であると聞いて驚く人が普通だから、>>841の疑問もしかたがないね
もしもこれがご不満なら、Wikipedia(日本語版および英語版)の訂正もヨロシク
>Smalltalk-72にはしっかり「代入」がある上に、
Smalltalk-80にもしっかり「破壊的」代入があるし、もちろんLOGOやLISPにもあるけど何か？
それとも>>841は「破壊的代入のあるLISPは関数型言語ではない！」と主張する
純粋関数型原理主義者、通称「ハスケラ症」の患者さんなのかな？(>>15)
>というわけでSmalltalkを関数型言語の傍流であるかのように言うことは
誰もSmalltalkが関数型言語であるとは言っていないと思うけどなあ....オブジェクト指向言語だろ？
ただし、SmalltalkがLISPやLOGOといった関数型言語から影響を受けたのは事実だし、
実際に、条件分岐が式であり、しかもブロック式(という「ナンチャッテ」クロージャ)があるから、
手続き型言語では素直に書けない関数型プログラミングのコードがSmalltalkでは書ける、というだけ
0846デフォルトの名無しさん
2012/02/22(水) 15:34:52.19副作用がないとまともなプログラムは書けなかったから
関数型言語も副作用を許していたわけで
(Common)LISPやMLみたいな言語は今となっては中途半端で
純粋関数型のHaskellが最強言語
みたいなラディカルな姿勢を皮肉っていたのがこのスレの上の方の流れだった
0847デフォルトの名無しさん
2012/02/22(水) 15:53:58.56LOGOがLISPの影響を受けたのはその通りだが、それをもって関数型言語というのはあまりにも乱暴だな。
LOGOが受けたLISPの影響は主にその動的環境であって、関数型パラダイムではないだろう。
そもそもプログラム実行でのデータ処理の基盤が関数適用か代入かという区分を考えれば
LISPのsetやsetqはあくまで環境設定にすぎずプログラムの実行は関数適用にあることは明らか。
その点でタートルの状態変化をプログラム実行の基盤に置いているLOGOは全く別物だ。
Wikipediaを聖典のように持ち出すのであれば、LOGOが手続き型言語の例として挙げられている点をどう説明する？
0848デフォルトの名無しさん
2012/02/22(水) 16:34:59.71要するに、純粋関数型原理主義者なのね....orz
>LOGOが受けたLISPの影響は主にその動的環境であって、関数型パラダイムではないだろう。
だから、動的な対話型プログラミング環境もLISPの影響だろうと思うけど、>>844で書いたように、
LOGOには、古いLISPの仕様に相当する関数型言語としての要素が備わっている
>その点でタートルの状態変化をプログラム実行の基盤に置いているLOGOは全く別物だ。
だから、LOGOの開発目的が教育用途であり、その応用であるタートルグラフィックが主体であると
考えてしまうのは、一般人であればしかたないと思うけど、グラフィックはI/O機能の一つでしかない
計算モデルという視点で見れば、LOGOは関数型言語なんだけどね
>>847の考え方は、「木を見て森を見ず」そのものだよ
>Wikipediaを聖典のように持ち出すのであれば、
Wikipediaは聖典じゃないよ....当然だろ？
特に日本語版はソースも無しにいきなり著者の主観で始まる記事があるから、驚く事もある
でも、英語版はとりあえず全世界の人々に認められている事、さらに該当記事の冒頭では、
" It was originally conceived and written as a functional programming language,[1]" と
ソース付きで明記されている
これらから、LOGOが関数型言語の一つであると見なすのは、妥当な判断じゃないかと思うけどな
なお、冒頭の後半にはタートルグラフィックについて、こんな一文もある(ただし、こちらはソース無し)
"Today it is remembered mainly for its turtle graphics,"
>LOGOが手続き型言語の例として挙げられている点をどう説明する？
まずは、その例についてソースをキボン
0849848
2012/02/22(水) 16:44:56.13X: だから、LOGOの開発目的が教育用途であり、その応用であるタートルグラフィックが主体であると
考えてしまうのは、一般人であればしかたないと思うけど、
O: だから、LOGOの開発目的が教育用途であるのは事実であり、その応用であるタートルグラフィックが
LOGOの主体であると考えてしまうのは、一般人であればしかたないと思うけど、
0850デフォルトの名無しさん
2012/02/22(水) 17:11:19.480851デフォルトの名無しさん
2012/02/22(水) 17:18:08.65LOGOが関数型言語であるというソースについて、
>>847から異論があったので、別のソースを見つけてきた
・Computer Science Logo Style Volume 1: Symbolic Computing
Brian Harvey, University of California, Berkeley, MIT Press
http://www.cs.berkeley.edu/~bh/v1-toc2.html
この本の序文(Preface)にある章 "Why Logo?" から引用する
・ It is a dialect of Lisp, the language used in the most advanced
research projects in computer science, and especially in artificial intelligence.
・For example, APL is based on the idea of matrix manipulation;
Prolog is based on predicate calculus, a form of mathematical logic.
Logo, like Lisp, is based on the idea of composition of functions.
・A big change since 1984 is that Logo is no longer the only member of
the Lisp family available for home computers.
Another dialect, Scheme, has become popular in education.
この本には高階関数の例としてmapの実装コードも紹介されている
この本でもまだ異論はあるかな？ >>847
もし英語が苦手なら、上の英文を翻訳してもいいよ
では、引き続き「LOGOが手続き型言語の例として挙げられている」ソースの提示をヨロシク
0852デフォルトの名無しさん
2012/02/22(水) 17:19:22.21関数型言語は純粋でなければならないなんて思っちゃいないけど、
自分の基準では、関数型言語は関数適用を情報処理の主要な機構とした言語。
その点においてLISPも関数型言語。
LOGOにおいて関数適用は補助的な機構であり、主要機構は代入。
その点においてLOGOは関数型言語ではない。
LISPを関数型言語として認める人を純粋関数型原理主義と呼ぶのであれば、
それまでの話だけど。
0853デフォルトの名無しさん
2012/02/22(水) 17:25:04.06X: LOGOが関数型言語であるというソースについて、
>>847から異論があったので、別のソースを見つけてきた
X: LOGOが関数型言語であるというWikipedia上のソースについて、
>>847からWikipediaの信頼性に異論があったので、別のソースを見つけてきた
0854デフォルトの名無しさん
2012/02/22(水) 17:35:48.43> では、引き続き「LOGOが手続き型言語の例として挙げられている」ソースの提示をヨロシク
http://encyclopedia2.thefreedictionary.com/procedural+language
あたりは如何？
An example (non-imperative) procedural language is LOGO, which specifies sequences of steps to perform...
と記述してありますが。
0855836
2012/02/22(水) 17:41:24.68>>835への指摘としては「新しい」という部分だからLOGOがLISPからインスパイアされていても
実はどうでもいいことではある。
しかし、LOGOはfunctional programmingというのはどうかと思うね。
starlogoを見てもfunctionalとは到底思えない。
せいぜい、originally designed upon a functional programming environment程度じゃなかろうか。
0856デフォルトの名無しさん
2012/02/22(水) 18:07:55.64>>851に加えて、他のソースも見つかった
・Wat is LOGO? - LOGO FOUNDATION
http://el.media.mit.edu/logo-foundation/logo/index.html
該当部分を引用する
The Logo Programming Language, a dialect of Lisp, was designed as a tool for learning.
まあ、他のソースといっても>>851はMIT Pressで、上のサイトはMITそのものだけどね
でも、とりあえず天下に知られた MIT がソースだから、聖典の代用品くらいにはなるかな？w
0857デフォルトの名無しさん
2012/02/22(水) 18:20:03.08まず、>>847がWikipediaの信憑性について異議を申し立てているのだから、
>>854のTHE FREE DICTIONARYの記事も、同じ理由で>>847は認めてくれないだろうね
さらに、その記事にはソースすら示されていないから、信憑性はWikipedia未満になる
しかも、同サイトのLogoに関する記事には、どこにもprocedural languageと書かれていない
http://encyclopedia2.thefreedictionary.com/LOGO
一貫性に欠けたソースである、とも言える
0858デフォルトの名無しさん
2012/02/22(水) 18:35:48.34教育を目的とした言語であるLOGOが関数型プログラミングのスタイルで
実際にプログラミング教育に使われた例があるとしたら興味深いよね
他の言語や数学の知識のない小学生とかがすんなり関数型を受け入れられるのだろうか？
0859デフォルトの名無しさん
2012/02/22(水) 18:41:52.53知り合いにも10人ぐらい実体験者がいるが、あまり肯定的な話ではなかった。
0860デフォルトの名無しさん
2012/02/22(水) 18:47:50.30つまり、
1. LISPは関数型言語である
2. LOGOはLISPの１つの方言である。
3. したがって、LOGOは関数型言語である。
と言いたいのか。
その論だと、
1. Smalltalkは動的プログラミング環境である。
2. GNU SmalltalkはSmalltalkの１つの方言である。
3. したがって、GNU Smalltalkは動的プログラミング環境である。
という主張も正しいことになるが、それでいいのかい？
0861デフォルトの名無しさん
2012/02/22(水) 18:47:56.20>LOGOにおいて関数適用は補助的な機構であり、主要機構は代入。
>その点においてLOGOは関数型言語ではない。
えーと、その為にわざわざ>>851というソースを提示したのだけど、読んだの？
読んだ上で「LOGOにおいて関数適用は補助的な機構であり、主要機構は代入」なの？
それとも、英語が読めない人？あるいは、自分が認めたくない事実には必死で目をつぶる人なの？
よく分からんなあ......
繰り返すけど、LOGOのタートルグラフィックはI/O機能の一部でしかなく、
言語の本質である計算モデルは関数適用であり、代入は構文糖にすぎない
>>851の章 "Why Logo?"から、Schemeとの差異に関する記述を引用する
The main difference between Scheme and Logo is that Scheme is more consistent
in its use of functional programming style. For example, in Scheme, every procedure is
what Logo calls an operation--a procedure that returns a computed value for
use by some other procedure. Instead of writing a program as a sequence of instructions,
as in Logo, the Scheme programmer writes a single expression whose complexity takes
the form of composition of functions.
The Scheme approach is definitely more powerful and cleaner for writing advanced projects.
Its cost is that the Scheme learner must come to terms from the beginning with
the difficult idea of function as object. Logo is more of a compromise with the traditional,
sequential programming style. That traditional style is limiting, in the end,
but people seem to find it more natural at first. My guess is that ultimately,
Logo programmers who maintain their interest in computing will want to learn Scheme,
but that there's still a place for Logo as a more informal starting point.
あと、>>854は別人さんだと思うので、
「LOGOが手続き型言語の例として挙げられている」ソースの提示も忘れずに、ヨロシク
0862デフォルトの名無しさん
2012/02/22(水) 19:05:45.79>1. Smalltalkは動的プログラミング環境である。
>2. GNU SmalltalkはSmalltalkの１つの方言である。
>3. したがって、GNU Smalltalkは動的プログラミング環境である。
この三段論法は、論理的に成立しないよ
命題1.は環境に関する事実だけど、命題2.は言語に関する事実
これらの型が一致していないから、単純に推論3.は誤り
詭弁を操ろうとするなら、もう少し論理学について勉強しておくれ
こちらが楽しめないからw
0863デフォルトの名無しさん
2012/02/22(水) 19:17:40.22あなたの主張は、Smalltalk-80で関数型的な表現が可能なのは、
Smalltalk-72の時点でLISP発LOGO経由で
LISPの関数プログラミングのエッセンスが導入されていたからだと。
しかし、私の理解が正しければ、Smalltalk-72のmapはcollect:ではなく
do:相当なわけで、確かにLISPのmapからの派生には違いないと思うが
関数プログラミング的なmapではなく、手続き的(doneで終わるところが
特に)なmapだと思うのだが、どうよ？
具体的には、>>834的なコードを
Smalltalk-72のmapでどう実装するか、
その実装は関数プログラミング的か、
ということだが。
0864デフォルトの名無しさん
2012/02/22(水) 19:25:01.82LISPやSmalltalkの議論に「型が一致していない」というのは冗談としても、
Smalltalkの歴史うんぬんを言う割に、言語としてのSmalltalkと環境としての
Smalltalkをバラバラにするのかい？
自分としては一貫してLISPもLOGOもSmalltalkも言語であり環境でもある
ものとして記述してきたつもりだが。だからLISPとLOGOの関係を動的環境
を軸に書いたのだが。
歴史を振り返るのは結構なことだが、ある言語が新しい言語を派生する時には
必ず新しい言語には元の言語では適応できなかったニッチを獲得していること
を忘れないほうがいいんじゃないのかい？
0865デフォルトの名無しさん
2012/02/22(水) 19:27:00.47> あと、>>854は別人さんだと思うので、
同一人物じゃ何か問題でも？
0866デフォルトの名無しさん
2012/02/22(水) 19:31:00.40Smalltalk-80のcollect:とpythonのリスト内包表現はそれぞれ別々の型だろうに。
ということは、>>862が正しいのなら>>837こそ詭弁なんじゃね？
0867デフォルトの名無しさん
2012/02/22(水) 19:36:16.13http://toro.2ch.net/test/read.cgi/tech/1251530895/
0868デフォルトの名無しさん
2012/02/22(水) 21:41:35.11>あなたの主張は、Smalltalk-80で関数型的な表現が可能なのは、
>Smalltalk-72の時点でLISP発LOGO経由で
>LISPの関数プログラミングのエッセンスが導入されていたからだと。
その「LISPの関数プログラミングのエッセンス」とは何か？だけど、
まずSmalltalk-72のmapは単純にコレクション系オブジェクトの各要素へ
メッセージを送信するだけで、(doneは無関係だから)関数的だと思う
逆に、手続き的な構文要素は(doneで終わる)repeatだと思うけど、
これも(関数的なmapの)構文糖であると見なすことも可能ではないかと思う
>具体的には、>>834的なコードをSmalltalk-72のmapでどう実装するか、....
そのとおりだね
自分が(>>837で)「Smalltalkなら関数的作法で書ける」と言ったのだから、
(たとえそれがSmalltalk-72であっても)コードはこちらから示す必要があるだろね
そのコードは、もう少し待って欲しい(Smalltalk-80ならすぐに書けるんだけど....)
あと、Smalltalk-72の実行環境は手元に無いから、おそらく動くであろうと考える
コードしか示せないことを、あらかじめ承知してもらいたい
0869デフォルトの名無しさん
2012/02/22(水) 22:01:18.43全然話の流れと関係ないが、Pythonならこれで良いかと
reverse = lambda x: x[::-1]
0870デフォルトの名無しさん
2012/02/22(水) 22:02:43.93ここでの議論は、ある言語(またはそのプログラミング作法)が
関数型か否か(あるいは関数的か否か)という判定であり、
その判定と環境の有無は無関係だろ
もちろん言語誕生の歴史も判定とは無関係
で、そちらが無理矢理に環境や歴史を絡めたいと考えるのは自由だけど、
絡めるなら絡めるで、論理的に成立する主張をしてくれ、って話だよ
0871デフォルトの名無しさん
2012/02/22(水) 22:12:11.79同一人物であるなら、それで無問題だよ
口調が>>847と>>864とではまるで違うし、本人であるとも書いていないので、別人だと思っただけ
自分が他人のソースに文句をつける時には、自分もそれに反しないソースを用意しておくし、
それが常識だと思っていたけど、>>847はそうじゃなくて、
単に理屈で反論できないからイチャモンを付けたかっただけだったのね、というどーでもいい話
0872デフォルトの名無しさん
2012/02/22(水) 22:16:39.81えーと、>>862の一致しない型というのはプログラミング言語のデータ型のことではなく、
数学の集合のことなんだけど.....
話にならないので、論理に加えて集合も勉強しなおしてから出直してくれ、たのむ
0874デフォルトの名無しさん
2012/02/23(木) 00:52:26.77型理論系の知識ってあった方が良いですか？
0875デフォルトの名無しさん
2012/02/23(木) 02:57:47.80母校の工業高校ではＣとＢａｓｉｃでプログラミング教えてるっぽいんだが、
Haskellみたいな言語で大まかな処理の流れを説明してからＣで作らせた方が挫折者が減るんじゃないか？とか考えてて、
有効そうだったら、母校に提案してみようと思うんだが、どうだろう？
上のreverceの例だと、Ｃで書くならこんな感じのコードになると思うんだが
#define SWAP_CHAR( x, y ) {char c; c = x; x = y; y = c;}
void reverse(char t[])
{
int i,j;
for(i = 0, j = strlen(t)-1; i < j; i++, j--)
SWAP_CHAR(t[i], t[j]);
}
Haskellだと同じアルゴリズムで書くなら、こんな感じのコード
reverce [] = []
reverce (x:xs) = [last xs] ++ reverce (init xs) ++ [x]
Haskell（と言うか、リストと再帰の組み合わせ）だと、リストに対して、線対称の位置にある値を交換して、真ん中まで来たら終了。と言うのが明確に分かるし、
これをヒントにＣでreverce書けなかった子にも、書けるようになるんじゃなかろうか
0876デフォルトの名無しさん
2012/02/23(木) 07:19:30.10(1)要素数が奇数だったら落ちる
(2)毎回lastとinitするのがクソ遅い
(3)Cと比べてHaskellは破壊的代入を使ってない
そして一番大事な点は、プログラミング出来ない子にとっては
再帰は難しいってことを忘れてる
0877デフォルトの名無しさん
2012/02/23(木) 08:54:17.63手続き型のスタイルで書いてもアロケーションを気にしないでいい言語なら楽だろ
function reverse( xs )
{
var ret = new Array;
for( i in xs )ret[xs.length-i-1] = xs[i];
return ret;
}
0878デフォルトの名無しさん
2012/02/23(木) 10:16:12.44寝ぼけてましたね。。。
奇数については
reverce [x] = x
を2行目に追加すれば良いとして、リストで配列向きのアルゴリズム使えば遅いのはしょうがないです
Cのコードで再帰使ってないとおり、どう言う動きのコードを書けば良いかのヒントになりさえすれば良いと考えています
再帰が難しい。。。ですか
確かに、x = x + 1を理解出来ない子も居ますしね。。。
階乗を例にして何とか理解して貰えたら。。。
0879デフォルトの名無しさん
2012/02/23(木) 10:18:15.97x reverce [x] = x
o reverce [x] = [x]
0880デフォルトの名無しさん
2012/02/23(木) 10:24:59.95>再帰が難しい。。。ですか
>確かに、x = x + 1を理解出来ない子も居ますしね。。。
x = x + 1 は再帰じゃないよんw
なんとなく、このままいくと>>878の母校で
「【アンチ】関数型言語は使えない【玩具】」な高校生が
大量生産されそうなオカン
0881デフォルトの名無しさん
2012/02/23(木) 10:55:02.79Haskellで x = x + 1 を書いて困惑するわけですね
0882デフォルトの名無しさん
2012/02/23(木) 11:25:57.72関数型かどうかは関係ないよね。というわけで、そこだけ C++ の string 使って書いちゃえ！
（>>877 とほぼ同じになるはず）
0883デフォルトの名無しさん
2012/02/23(木) 11:34:54.51小学生でも、普段の生活の中で帰納・演繹→再帰を理解するくらいの基礎経験はあるから、これは教える側の問題。
0884デフォルトの名無しさん
2012/02/23(木) 12:01:21.20同感だなあ
再帰なら入れ子になったデータ構造がタマネギの皮を剥くように展開されている様子を
絵やアニメで表現すれば、子供達でも理解しれくれると思う
たとえば手続き型言語ならフローチャートやPADのような図表現があるように、
関数型言語ならヘンダーソン図などがあるのに使わないんだよね
0885デフォルトの名無しさん
2012/02/23(木) 12:11:39.56いえ。。。
それはBasicの授業での話で。。。
そう言う子がいる以上は、再帰が分からない子も居るだろうな、と
0886デフォルトの名無しさん
2012/02/23(木) 12:16:58.16Wikipediaを持ち出した主張への反論の中で
別のフリーの百科事典の記述を提示することが
矛盾だと思うような感性w
LISP言語とLISP環境は型エラーだけど
LISPのmapとst72のmapは型エラーにならないとか、
型付き集合論ならZF系を修論で扱ったが
さすがにこんなトンチンカンな公理系は知らんわw
0887デフォルトの名無しさん
2012/02/23(木) 12:50:32.70親個体のごく一部が大きく育って子になり、またそれを繰り返す...
すれ違いスマン。
0888デフォルトの名無しさん
2012/02/23(木) 23:31:33.51Haskell版2行目は、
reverce (x:xs) = reverce (xs) ++ [x]
ではあるまいか。それはどうでもよくて、C版が配列(非再帰的構造)に対し、
Haskellがリスト(再帰構造)と、データ構造が異なるなるのが問題。
概念→実装詳細と授業展開するなら、C版もリストにすべし。
0889デフォルトの名無しさん
2012/02/24(金) 00:13:01.97ヘンダーソン図ってなんぞ？
0890デフォルトの名無しさん
2012/02/24(金) 02:11:54.03reverce (x:xs) = reverce (xs) ++ [x]
は「線対称の位置にある値を交換して、真ん中まで来たら終了」
じゃない
0891デフォルトの名無しさん
2012/02/24(金) 07:49:52.64データ構造の違いは百も承知です
アルゴリズムと言うほど大層で無い手順でも躓く子が居て、そう言う子には、変に図で説明するより、再帰的な表現の方がわかり易いのでは無いか？と思ったのがきっかけで、処理効率とかデータ構造の違いを無視して、アルゴリズムだけを抽出して説明したいのです
そこで、アルゴリズムの可視化にhaskellが使えるのでは無いだろうか？と言うのが、私の考えです
0892デフォルトの名無しさん
2012/02/24(金) 08:22:39.48ここの書き込みを見るに、わかりやすい説明ができそうな気がしない
0893デフォルトの名無しさん
2012/02/24(金) 12:56:36.08まあ、口下手は否定しません
ただのOBですし、教材作る時間も限られるので、haskellの様なアルゴリズムの可視化に向いてる言語を利用しようと言う魂胆です
有効そうなら、実際に使ってみようかと考えてる訳です
0894デフォルトの名無しさん
2012/02/24(金) 19:53:22.600895デフォルトの名無しさん
2012/02/24(金) 20:02:57.01自分の場合は
関数型言語がえらい流行ったのって
もう5年以上前になるんじゃないかな…
C++でOS自作したとかいう目の下の黒いプチ有名人が
（OS自作ブームは10年前か？）
紫色の勉強する過程をｂLogにうｐしてたの覚えてるわ
Google社のエンジニアリング部門のインフラ言語に
使われてるらしいとか、なんかで読んだことあるけど
それ以外で何が開発されたとか
寡聞にして一切聞いたこと無い
まだ学習すんの流行ってんの？
0896デフォルトの名無しさん
2012/02/24(金) 21:02:46.80型推論付きの関数型言語くらいしか選択肢が無い
0897デフォルトの名無しさん
2012/02/24(金) 21:09:35.16OCaml系でType Classが入れば個人的にはかなり満足
0898デフォルトの名無しさん
2012/02/24(金) 21:26:33.590899デフォルトの名無しさん
2012/02/24(金) 21:47:49.83IOモナドとかを使わずにプログラミングするスタイルが というべきかな？
このスレの上の方でも出てるけど
グラフ操作とか双方向リストとかシンプルで効率の良い実装の困難なものが結構ある
割り切ってIO使いまくったコードを書くのもそれはそれでありかなと今思った
0900デフォルトの名無しさん
2012/02/24(金) 22:12:54.46STなんてそのための存在だし
0901デフォルトの名無しさん
2012/02/24(金) 23:53:13.300902デフォルトの名無しさん
2012/02/25(土) 01:19:42.90IORefは使ったことあるが、STはない。
0903デフォルトの名無しさん
2012/02/25(土) 01:20:51.250904デフォルトの名無しさん
2012/02/25(土) 01:28:40.83関数型言語って流行ものだったのか!?
Perlのように使えて、記述がわかりやすく対話的環境があるものが欲しかった
のだが、SML/NJが実によくできていたので、これを使うことにした。
それこそ、最初は電卓のかわりとして。
0905デフォルトの名無しさん
2012/02/25(土) 01:42:56.22大手のHPじゃソースコードの解析に使ったなんて使用例をみたな。
それでなくとも、今後にゃ統計処理やテキストマイニングが重要になるから、
パーサー書いたり、統計処理での数値計算、並列処理なんかの用途が考えられるし、
そこら辺の動的言語よか、ずっと実用的なんじゃないかなと思っているけど。
0906デフォルトの名無しさん
2012/02/25(土) 01:54:07.67これはRがかなり成功してますね。他にも、処理系はあるのでしょうか。
0907デフォルトの名無しさん
2012/02/25(土) 02:10:44.89理由は詳細なコメントを書かない人が多い。
Cなどのコーディングを読む力が強すぎると単なる記号の並びの
本人以外が読み取るのが難しいものを作ってしまう。忘れやすい人には
不向きだ。記憶力が無いと馬鹿にする人も多いが規模が大きくなれば
暗記できる量など誰でも限界はある。
アセンブラが難解だといっている人は、逆アセンブルソースを見て
理解できないという話かと思う。
分かりやすく設計し設計書を残しコーディングすれば問題はない。
0908デフォルトの名無しさん
2012/02/25(土) 03:32:18.37つまるところ
スレ住人には使えない
って意味でよろしいか？
0909デフォルトの名無しさん
2012/02/25(土) 04:58:10.730910デフォルトの名無しさん
2012/02/25(土) 07:29:09.41処理系ということならS S-PLUS
あとはStata、SAS、
SPSSとそのオープンな実装PSPP
0911868
2012/02/25(土) 09:29:33.41お待たせ、Smalltalk-72によるreverseの実装コードです（アク禁により、カキコ代行を依頼）
to reverse vec
((vec length) = 0 =>
(^ vector 0)
^ (reverse vec[2 to (vec length)]) + vec[1 to 1])
・全体としてSmalltalk-72の構文は、(その後継のSmalltalk-80よりも)LOGOとの類似性が強い
・2行目行末の '=>' および3,4行目行頭の '^' は、それぞれ条件分岐とリターンの意味
本物のAltoマシン上では、特殊キーで入力するアイコン風の特殊記号で表示される
・標準のvectorクラスを使い、Ruby(>>832下段)を参考にして実装している
LISP/LOGOのリストに対応する構文は、Smalltalk-72では定義されておらず、vectorを使う
ただし、ドット項に対応するlinkクラスがあり、car/cdr/cons相当のリスト処理も記述できる
0912デフォルトの名無しさん
2012/02/25(土) 10:41:34.61primes = f [2..]
where
f (p:xs) = p : [x | x <- f xs, x `mod` p /= 0]
ps = takeWhile (< 100) primes
ポイントは素数生成アルゴリズムとループ終了条件が分離出来ているところ
コードの独立性と再利用性が高まるからね
0913デフォルトの名無しさん
2012/02/25(土) 12:29:13.14細かなところを直したり、（シミュレーターに無かったので）ベクターに + を定義したりしましたが
動作の確認できました。
http://squab.no-ip.com/collab/uploads/61/st72reverse.png
参考
http://languagegame.org:8888/propella/74
0914デフォルトの名無しさん
2012/02/25(土) 13:29:24.81Python
from itertools import count, takewhile
def primes():
def f(p, xs): return p, (x for x in xs if x % p)
xs = count(2)
while True:
p, xs = f(xs.next(), xs)
yield p
ps = takewhile(lambda x: x < 100, primes())
0915デフォルトの名無しさん
2012/02/25(土) 15:01:59.23関数型言語LOGOの影響を受け
関数的作法で書けるSmalltalkなら余裕ですよ？
たぶん
0916デフォルトの名無しさん
2012/02/25(土) 15:30:35.33理解するのに30分かかった。pure functionalはむつかしいのう。
>>914
pythonって遅延評価もっているの?
>>915
Smalltalkは知らないが、これをやるには遅延評価がいる。処理系に組み込み
の遅延評価がなくても、チャンクを書けばできなくはないが、それだったら
命令的に書いたほうがわかりやすい。
0917デフォルトの名無しさん
2012/02/25(土) 15:39:26.960918デフォルトの名無しさん
2012/02/25(土) 16:16:22.99b
0919デフォルトの名無しさん
2012/02/25(土) 16:19:22.12datatype 'a lazylist = NULPO | CONS of 'a * (unit -> 'a lazylist)
fun tabulate (f: int -> 'a): 'a lazylist = let
fun tabulate' (i:int): 'a lazylist =
CONS (f i, fn () => tabulate' (i + 1))
in
tabulate' 0
end
fun takeWhile (xs: 'a lazylist, cond: 'a -> bool) =
case xs
of NULPO => nil
| CONS (x, f) =>
if cond x
then x :: takeWhile (f(), cond)
else nil
fun filter (cond: 'a -> bool) (xs: 'a lazylist): 'a lazylist =
case xs
of NULPO => NULPO
| CONS (x, f) =>
if cond x
then CONS (x, fn () => filter cond (f()))
else f()
0920デフォルトの名無しさん
2012/02/25(土) 16:19:57.14fun f (CONS (p,xs)) = CONS (p, fn () => filter (fn x => x mod p <> 0) (f (xs()) ))
in
f (tabulate(fn i => i + 2))
end
0921デフォルトの名無しさん
2012/02/25(土) 16:27:40.07ありがとう。
こういうページがあって、なんとなく挙動が想像できるようにはなったが、
まだはっきりしないので、落ち着いて考えてみます。
http://jutememo.blogspot.com/2008/07/python-1.html
0922デフォルトの名無しさん
2012/02/25(土) 16:46:58.03| primes |
primes := Generator on: [:g |
| f xs |
f := [:gen |
| p |
p := gen next.
Generator on: [:h |
[ | next |
((next := gen next) isDivisibleBy: p) ifFalse: [h yield: next].
] repeat]].
xs := Generator on: [:h | 2 to: Float infinity do: [:n | h yield: n]].
[g yield: xs peek. xs := f value: xs] repeat].
(1 to: 1000) collect: [:each | primes next]
0923デフォルトの名無しさん
2012/02/25(土) 16:57:35.04fun filter (cond: 'a -> bool) (xs: 'a lazylist): 'a lazylist =
case xs
of NULPO => NULPO
| CONS (x, f) =>
if cond x
then CONS (x, fn () => filter cond (f()))
else filter cond (f())
0924デフォルトの名無しさん
2012/02/25(土) 17:03:38.72xs.next() を next(xs) に書き換える必要があるね
0925デフォルトの名無しさん
2012/02/25(土) 17:04:46.580926デフォルトの名無しさん
2012/02/25(土) 17:11:39.250927デフォルトの名無しさん
2012/02/25(土) 17:22:07.50いや>>912でしょ
0928デフォルトの名無しさん
2012/02/25(土) 17:36:44.87ジェネレーター使って素数生成と終了条件を分離するだけならこれで十分かとも。
| primeGen |
primeGen := Generator on: [:g |
| primes |
primes := OrderedCollection new.
g yield: (primes add: 2).
2 to: Float infinity do: [:n |
(primes noneSatisfy: [:prime | n isDivisibleBy: prime])
ifTrue: [g yield: (primes add: n)]]].
(1 to: 1000) collect: [:each | primeGen next]
0929デフォルトの名無しさん
2012/02/25(土) 17:51:06.22Smalltalk知らないんだけど、その方法って
ps = takeWhile (< 1100) $ dropWhile (< 1000) primes
のように 1000 <= p < 1100 の範囲の素数が欲しいときに
メモリが無駄にならない？
0930デフォルトの名無しさん
2012/02/25(土) 17:55:32.21そうなのか
上がってたからスレ読んでみたけど>>912が何か分からない俺には早すぎますた
0931デフォルトの名無しさん
2012/02/25(土) 18:42:56.40その方法とはどちらでしょう？ primeGen の実装？ それとも最後の素数の集め方のほう？
前者は算出済み素数を保持するくらいしかメモリは使っていないので、
遅延評価やましてジェネレーターを量産する方法よりは消費は少ないような気がします。
後者は書き方次第ですね。集めてから捨てるとかだと無駄ですが、
欲しい区間だけ集めるようにすれば無駄な領域確保は必要ないと思うので。
0932デフォルトの名無しさん
2012/02/25(土) 19:12:30.66primes = 素数列
2から始まる数列を素数で割って、残った数列の先頭にある数もまた素数であるという、アリストテレスの櫛（くし）（又は篩（ふるい））というアルゴリズムを書いたもの
素数列 数列
(今は空） 2,3,4,5,6,7,8,9,10...
2で割る
素数列 数列
2 3,5,7,9...
3で割る
素数列 数列
2,3 5,7,...
0933デフォルトの名無しさん
2012/02/25(土) 19:59:47.11気分を害したならすまない
Smalltalkは知らないので訊いてみただけなんだ
メモリを無駄に使わないなら良いね
で、Haskellのコードを試しに動かしてみた
Smalltalkも試してみたいけど手元に環境が無い
http://ideone.com/FT59T ; (p < 100)
http://ideone.com/J7juX ; (1000 <= p < 1100)
http://ideone.com/AArag ; (10000 <= p < 10100)
0934デフォルトの名無しさん
2012/02/25(土) 20:23:41.25http://ideone.com/LaVqv ; (p < 100)
http://ideone.com/QdE6o ; (1000 <= p < 1100)
http://ideone.com/o2Pd4 ; (10000 <= p < 10100 : デフォルトのスタックサイズじゃ落ちたのでスタックサイズを弄った)
ていうかPython速いな
0935デフォルトの名無しさん
2012/02/25(土) 21:24:09.66| primeGen p time0 result |
primeGen := Generator on: [:g |
| primes |
primes := OrderedCollection new.
g yield: (primes add: 2).
2 to: Float infinity do: [:n |
(primes noneSatisfy: [:prime | n isDivisibleBy: prime])
ifTrue: [g yield: (primes add: n)]]].
#(0 100 1000 1100 10000 10100) pairsCollect: [:min :max |
gcStats := SmalltalkImage current getVMParameters.
time0 := Time millisecondClockValue.
result := OrderedCollection new.
[ ((p := primeGen next) between: min and: max) ifTrue: [result add: p].
p < max
] whileTrue.
SmalltalkImage current getVMParameters keysAndValuesDo: [:idx :gcVal |
gcVal ifNotNil: [gcStats at: idx put: (gcVal - (gcStats at: idx))]].
time := Time millisecondClockValue - time0.
SmalltalkImage current garbageCollect.
{min->max. time "ms". gcStats second "bytes" . result asArray}
]
"Squeak4.2-ja (CogVM), 1.8 GHz Core i7 =>
{ {0->100 . 0 . 23692 . #(2 3 5 7 11 13 17 19 23 29 31 37 41 43 47 53 59 61 67 71 73 79 83 89 97)} .
{1000->1100 . 1 . 199580 . #(1009 1013 1019 1021 1031 1033 1039 1049 1051 1061 1063 1069 1087 1091 1093 1097)} .
{10000->10100 . 35 . 1667972 . #(10007 10009 10037 10039 10061 10067 10069 10079 10091 10093 10099)}} "
0936デフォルトの名無しさん
2012/02/25(土) 21:33:30.54破壊的な代入が普通には出来ないから、良くも悪くも頭の体操になるな
update 0 a (_:xs) = a:xs
update n a (x:xs) = x:update (n - 1) a xs
swap n m xs = update m (xs!!n) (update n (xs!!m) xs)
こんなブログもあって、swap一つでも楽しめる
Haskell でリストの要素を swap する 9 つの方法
http://jutememo.blogspot.com/2011/04/haskell-swap-9.html
0937デフォルトの名無しさん
2012/02/26(日) 01:28:07.66が読み易いと本当に思ってるの？
0938デフォルトの名無しさん
2012/02/26(日) 02:07:54.530939デフォルトの名無しさん
2012/02/26(日) 02:52:44.82http://www.okinawa-awamori.or.jp/product.php?id=160
0940デフォルトの名無しさん
2012/02/26(日) 03:09:09.860941デフォルトの名無しさん
2012/02/26(日) 03:14:34.70むしろアリストテレスの櫛を>>912以上に分かりやすく書いてるコードを見たいもんだ
0942デフォルトの名無しさん
2012/02/26(日) 03:35:14.260943デフォルトの名無しさん
2012/02/26(日) 06:02:54.98終了判定の分離をあきらめてよければ、より手続き的に書けるだろう。
fun primes' upto = let
fun test p xs = List.all (fn x => p mod x <> 0) xs
fun loop p xs =
if p < upto
then loop (p + 1) (if test p xs then p :: xs else xs)
else xs
in
loop 2 nil
end
ところで、エラトステネスではなかったか。
0944デフォルトの名無しさん
2012/02/26(日) 07:56:28.81何か勘違いしているようだけど、関数型スタイルは>>912(Haskell)と>>920,943(SML)だけで、
>>914(Python)や>>922,928(Smalltalk)は手続き型スタイルだよ
関数型スタイルというのは(副作用を伴わない)宣言的な記述が特徴
でも、>>914(Python)はwhile文という手続き型の反復構文が使われているし、
>>922,928(Smalltalk)では変数primesへの破壊的代入が使われているから、宣言的とは言えない
どちらもジェネレータ(イテレータ)と呼ばれる手続き型コード化技法の応用になる(>>917)
仮に、処理効率を考慮してライブラリ(Pythonのitertoolsモジュール、SmalltalkのGeneratorクラス)の中で
手続き型コードの利用を選ぶことを認めるとしても、ユーザコード内では宣言的に書けるべき
結論としては、「リスト反転(>>831)」というお題では分からなかった手続き型と関数型の違いが、
この「エラトステネスの篩(>>912)」というお題で(少しだけ)見えてきた、と言えるのかもしれない
0945デフォルトの名無しさん
2012/02/26(日) 07:56:46.33私には
http://nojiriko.asia/prolog/t266.html
こういうJAVAっぽいコードの方がわかりやすいけど。
0946デフォルトの名無しさん
2012/02/26(日) 07:57:43.43primes = sieve [2..]
sieve (p:xs) = p : sieve [x | x <- xs, x `mod` p /= 0]
ちょっとした違いだけど分かりやすさも性能も桁違い
0947デフォルトの名無しさん
2012/02/26(日) 08:06:28.85Haskellで終了条件を分離せず、ST使って手続き的に書くと
読み難くなるかわりに>>912(>>933)と比べるとずっと速くなる
http://ideone.com/JkfhA
0948デフォルトの名無しさん
2012/02/26(日) 08:11:05.650949デフォルトの名無しさん
2012/02/26(日) 10:18:56.00ttp://www.cs.hmc.edu/~oneill/papers/Sieve-JFP.pdf
ttp://d.hatena.ne.jp/camlspotter/20100128/1264678903
0950デフォルトの名無しさん
2012/02/26(日) 10:32:57.520951デフォルトの名無しさん
2012/02/26(日) 11:29:08.460952デフォルトの名無しさん
2012/02/26(日) 12:33:05.01quick sort もシンプルだけど全然クイックじゃないし。
おまけにモナド使って手続き的に書いたほうが速いとかないわ。
0953デフォルトの名無しさん
2012/02/26(日) 13:23:02.95Haskellに限らず、再帰で書けばそんなもん
同じ程度の読みやすいコードなら、コンパイルすればpython/rubyより速いっぽいんだが、私はpythonもrubyも使ったことが無い・・・
0954デフォルトの名無しさん
2012/02/26(日) 13:32:19.19＞Haskellに限らず、再帰で書けばそんなもん
ですよね。それがスレタイの本質では？
0956デフォルトの名無しさん
2012/02/26(日) 13:42:10.76それがスレタイの本質では？
0957デフォルトの名無しさん
2012/02/26(日) 13:44:44.59破壊的代入を使わなければループを書けないから
必然的に再帰で書くしかないだろ
0959デフォルトの名無しさん
2012/02/26(日) 13:55:44.53スレタイで言うところの実用を考えると、悩むべき所はもっと他にあるぜ。
0960デフォルトの名無しさん
2012/02/26(日) 14:04:45.620961デフォルトの名無しさん
2012/02/26(日) 14:07:28.47能力があるプログラマが十分な時間かけてチューニングして書くんだったら
アセンブリで書いたほうがずっと速くなるってのｗ
0963デフォルトの名無しさん
2012/02/26(日) 15:07:00.04配列にインデックスアクセスして書き換えるというのは
再帰の引数にインデックスを渡すわけで
実質的に手続き型と言えよう
関数型言語を使うときに必要に応じて手続き型で書くのは普通のことだよ
0965デフォルトの名無しさん
2012/02/26(日) 15:14:04.72今は垣根なんてなく両方のいいとこを取り入れて書くのが普通。
0966デフォルトの名無しさん
2012/02/26(日) 15:21:23.18関数型言語の特徴と言えば特徴かね
0967デフォルトの名無しさん
2012/02/26(日) 16:21:45.97でもリスト上のmapなんかは正格評価で速くするの面倒くさいじゃん
正格評価だとスタックオーバーフローを認めるか
末尾再帰で書いて最後にreverseするか
変換のコスト払って破壊的操作できるデータ構造（配列など）に変換して
計算するしかないんじゃないの？
0968デフォルトの名無しさん
2012/02/26(日) 17:28:39.60(Haskell版は普通のリスト向けのアルゴリズムと、配列向けのＣと同じアルゴリズム（をリストに対して適用したVer)の２つ作ってみた）
意外なことに、Haskellのreverse２つに速度の差は出なかった
むしろ、メモリ使用量でCのアルゴリズム版の方が省メモリだった
配列（又はリスト）の要素数が6500なのは、このサイトでは要素数7000を超えるとCのコードでランタイムエラー起こすから
（PC上のコマンドラインでは10000でも余裕で動いてるし、Haskellも10000までならかろうじて我慢できる速さ@Core i5 mem:2GB環境）
ぶっちゃけ、Haskellはコード量と速度のバランスは悪いかなとは思うんだが、python/ruby分からんので、そっちの方は誰か頼む
Cのreverse
http://ideone.com/ylwPb
Haskellのreverse（よく見るコード版）
http://ideone.com/BkMS5
Haskellのreverse（Ｃのアルゴリズムをリストに使った版）
http://ideone.com/9fGR3
0969デフォルトの名無しさん
2012/02/26(日) 17:38:09.63比較のやりかたがわけわからん
・HaskellでO(n)のreverseが簡単に書けるのに、よく見るコードと称してなぜO(n^2)のを使うのか
・「配列向けのCと同じアルゴリズム」を使っておきながらなぜHaskellの配列を使わないのか
0970デフォルトの名無しさん
2012/02/26(日) 17:42:15.16Haskellも勉強中なんでね
よければ、Haskellの改良版も頼む
一応、基準としては読みやすさと速さのバランス・・・かな
あいまいでスマン
0971デフォルトの名無しさん
2012/02/26(日) 17:49:50.76http://ideone.com/U7EIu
0972デフォルトの名無しさん
2012/02/26(日) 17:51:21.29reverse のような基本関数を自作する時点で読みやすさは最悪だ。
C はその時点で、他の言語と比較不可能な高い高い壁がある
0973デフォルトの名無しさん
2012/02/26(日) 19:22:38.04計測したら>>971と同じか速い（てか、Ｃの素直なコードよりわずかに速い）
reverse = foldl (\ x xs -> xs:x) []
http://ideone.com/8hIIw
畳み込み系は足し算とか掛け算以外はイメージつかみにくいので、動作を追ってみた
foldl _ v [] = v
foldl f v (x:xs) = foldl f (f v x) xs
reverse [1,2,3,4,5]
= foldl (\x xs -> xs:x) ((\x xs -> xs:x) [] 1) [2,3,4,5]
= foldl (\x xs -> xs:x) ((\x xs -> xs:x) (1:[]) 2) [3,4,5]
= foldl (\x xs -> xs:x) ((\x xs -> xs:x) (2:(1:[])) 3) [4,5]
= foldl (\x xs -> xs:x) ((\x xs -> xs:x) (3:(2:(1:[]))) 4) [5]
= foldl (\x xs -> xs:x) ((\x xs -> xs:x) (4:(3:(2:(1:[])))) 5) []
= v = ((\x xs -> xs:x) (4:(3:(2:(1:[])))) 5) -- foldl _ v []より
= (5:(4:(3:(2:(1:[])))))
= [5,4,3,2,1]
うーん・・・動作確認した後だと
reverse = foldl (\x ys -> ys:x) []って書いたほうがしっくりくる・・・
0974デフォルトの名無しさん
2012/02/26(日) 21:37:18.02C : http://ideone.com/KZvjU
Haskell : http://ideone.com/BSxi8
0975デフォルトの名無しさん
2012/02/26(日) 21:45:57.32コスパ（コード量/実行速度)なら、今のところHaskellだな・・・
他の言語の方が全体ではコスパ良い言語ありそうだが
0976デフォルトの名無しさん
2012/02/26(日) 22:07:13.45「開発時間」／実行速度
で測るべきではないかと。
コード量で物事を測るのは、行数を金に換算できる時だけでいい。
0977デフォルトの名無しさん
2012/02/27(月) 08:16:55.40Python速www
Haskell遅www
http://ideone.com/ouGzb
0978デフォルトの名無しさん
2012/02/27(月) 08:23:36.42まぁ順序は変わらんと思うが
0979デフォルトの名無しさん
2012/02/27(月) 10:19:36.43>>973のhaskellの方が速いじゃ無いか
0980デフォルトの名無しさん
2012/02/27(月) 11:14:14.37良く見ろ
扱ってるリストのサイズが違う
0981デフォルトの名無しさん
2012/02/28(火) 14:40:28.19皆さんがっかりですか？
0982デフォルトの名無しさん
2012/02/28(火) 15:16:14.21http://ideone.com/YwgVh
0983デフォルトの名無しさん
2012/02/28(火) 15:59:39.544MBの4byte単位のreverseにそんなかかるわけない
素直なコードでも今時のCPUだったら数百usオーダのはず
0984デフォルトの名無しさん
2012/02/28(火) 17:16:55.890985デフォルトの名無しさん
2012/02/28(火) 17:59:53.19python詳しくないんだけど、
reverse(list(range(1,1000001)))[0]
ここって、1から1000001までのリストを反転して、先頭の要素を表示してるのでは？
結果が
1000000
ってのは、間違った結果じゃない？
0986デフォルトの名無しさん
2012/02/28(火) 18:03:24.03>>> range(1,10)
[1, 2, 3, 4, 5, 6, 7, 8, 9]
0987デフォルトの名無しさん
2012/02/28(火) 19:04:02.21なるほど
でも、なんで+1の数字を指定するの？
何か、紛らわしい
0988デフォルトの名無しさん
2012/02/28(火) 19:29:32.25Java
http://java.sun.com/javase/ja/6/docs/ja/api/java/lang/String.html#substring(int, int)
>パラメータ:
>beginIndex - 開始インデックス (この値を含む)
>endIndex - 終了インデックス (この値を含まない)
http://java.sun.com/j2se/1.5.0/ja/docs/ja/api/java/util/SortedMap.html#subMap(K, K)
>このソートマップの fromKey (含む) 〜 toKey (含まない) の
>キー範囲を持つ部分のビューを返します
C++標準ライブラリ
http://www5c.biglobe.ne.jp/~ecb/cpp/07_08.html
>iterator end() 末尾を表わすイタレーターを返します
>末尾とは最後の要素の次を表わします
割と一般的
0989デフォルトの名無しさん
2012/02/28(火) 19:38:21.710990デフォルトの名無しさん
2012/02/28(火) 19:40:47.64別に、破壊的にreverse出来ないのに良く頑張ってるな・・・程度
http://ideone.com/KGg1L
この程度なら、変数に実行前の結果を入れておけば済む話だけど、元々、関数型言語は参照透明性が保たれれば、マルチスレッド化しやすいってので注目された訳だし
推測するに、pythonのリストは双方向リストで、reverseはポインタを付け替えるだけで実現してると予想
0991デフォルトの名無しさん
2012/02/28(火) 19:42:12.90理由は色々ありそうだけど、例えば2つの並んだ範囲を書く
(0 <= x <= 99) (100 <= x <= 199)
整数なら良いけど連続値なら(0 <= x <= 99.999...)となってしまう
だから範囲は (0 <= x < 100) (100 <= x < 200) という「以上〜未満」で書いた方が安心確実だよね！
とかそんな感じじゃね
0992デフォルトの名無しさん
2012/02/28(火) 19:49:00.83参照透明性とは違うけど
>>974のCや>>982のJavaも元配列を変更しないよう(非破壊的)に書かれてるけどな
0993デフォルトの名無しさん
2012/02/28(火) 19:50:11.02残念ながら、>>977は元のリストには何の副作用もない。
Pythonインタプリタが非破壊的にリバースしている。
0994デフォルトの名無しさん
2012/02/28(火) 20:09:42.95それを言うなら、Haskellだって、[1..10]ってしても、その後ろに空リストが並んでるわけで・・・
javaと言うか、C系列でも、配列の宣言はint a[10]で、indexはa[0]からa[9]の十個じゃない？
Haskellも[1..10]ってしても、index(!!)は[1..10]!!0から、[1..10]!!9までの10個だよ
要素数が10個なのに、11って宣言するのはやっぱり変な気がするなぁ・・・
（まあ、他言語のルールをとやかく言ってもしょうがないんだけど）
0995974
2012/02/28(火) 20:37:56.79当然リストよりも速い
・STで非破壊的にreverse
http://ideone.com/YaOZi
・IOで破壊的にreverse
http://ideone.com/WRQwd
0996デフォルトの名無しさん
2012/02/28(火) 20:38:48.57>>977のPythonコード
def reverse(x): return x[::-1]
が速いのは、スライスと呼ばれる配列構成子を利用しているから
つまり、x[::-1] が「配列 x の末尾要素から逆順に列挙して得た配列を返す」という意味だから
Cで書くと、以下のようになる
void reverse(int *src, int *dst, int size) { int i; for (i = 0; i < size; i++) dst[(size - 1) - i] = src[i] }
スライス機能はCで実装されているから、Haskellより速いのは、当たり前と言えば当たり前の結果
ただし、RubyでもArrayクラスにreverseメソッドが定義されているから、
たった x.reverse だけでHaskellよりも高速(かつ非破壊的)に実行できるけど、
それをRuby信者が>>977,981のように「自慢げに語る」ことは見たことも聞いたことも無いなwww
0997デフォルトの名無しさん
2012/02/28(火) 20:40:11.15>>977のPythonコード
def reverse(x): return x[::-1]
が速いのは、スライスと呼ばれる配列構成子を利用しているから
つまり、x[::-1] が「配列 x の末尾要素から逆順に列挙して得た配列を返す」という意味だから
Cで書くと、以下のようになる
void reverse(int *src, int *dst, int size) { int i; for (i = 0; i < size; i++) dst[(size - 1) - i] = src[i] }
スライス機能はCで実装されているから、Haskellより速いのは、当たり前と言えば当たり前の結果
ただし、RubyでもArrayクラスにreverseメソッドが定義されているから、
たった x.reverse だけでHaskellよりも高速(かつ非破壊的)に実行できるけど、
それをRuby信者が>>977,981のように「自慢げに語る」ことは見たことも聞いたことも無いなwww
0998デフォルトの名無しさん
2012/02/28(火) 20:44:41.80Pythonのrangeや>>988はindex、配列の宣言はsize
indexとsizeを混同してはいけない
begin <= 有効index < begin + size (= end)
>int a[10]で、indexはa[0]からa[9]の
普通にfor文書いたら(0<=i<10)になるだろ？
for(int i=0; i<10; i++){...}
0999デフォルトの名無しさん
2012/02/28(火) 20:46:42.91http://toro.2ch.net/test/read.cgi/tech/1330429547/
需要が無ければ落ちるだろうから建てた
1000デフォルトの名無しさん
2012/02/28(火) 21:04:55.071001１００１
Over 1000Threadもう書けないので、新しいスレッドを立ててくださいです。。。
レス数が1000を超えています。これ以上書き込みはできません。