07/04/09 21:34:02
無意味
575:デフォルトの名無しさん
07/04/09 21:57:29
>>573
コンビネータは、ぶっちゃけ 「自由変数のない関数」 で合ってるよ。
んで、プログラム言語のあらゆる関数がそうだと思うのなら、別にそれでも良いよ。間違ってはいないさ。
576:デフォルトの名無しさん
07/04/09 22:04:09
なんという結論
さすがFランク
577:デフォルトの名無しさん
07/04/09 22:18:37
自分の認識だと、引き数に関数のみ取り、
引き数で受け取った関数を何らかの形で組み合わせたものを返す以外のことをしない関数、
みためでいえば、
中身には引き数以外の名前が現れない関数、って理解だけど、あってる？
578:デフォルトの名無しさん
07/04/09 22:44:20
コンビネータ
「コンビネーター計算は、λ計算と同等のことを変数やλ抽象を持たず、
ただ適用だけをもつシステムで実現しようとしたものであって、λ計算とは別物」というのは同意。
ただ、(コンビネータ計算ではなく)ラムダ計算の文脈では、単に「自由変数を含まないλ式」
という意味で結構広く使われているように思いますし、私もそのように理解してました。
本来は誤用だったのかも知れませんが、すっかり定着してしまっているように思います。
調べてみると、Simon Peyton Jones の
The Implementation of Functional Programming Languages の p.224 には
「A combinator is a lambda expression which contains no occurences of a free variable [Barendregt, 1984]」
と書いてあります。ちょっと探した限りではバーレンドレヒト以前でこの意味で使っているのは見当たらなかったので、
この用法はやっぱりバーレンドレヒトが起源なのかも。それはそれでちょっと面白いなぁ。
579:デフォルトの名無しさん
07/04/09 22:51:46
またjargon fileの解釈論争みたいな塩梅だなあ
580:flatline ◆r6EONKKhcc
07/04/10 02:04:09
>>554
こんなのもありますよ
URLﾘﾝｸ(citeseer.csail.mit.edu)
Y in Practical Programs
581:デフォルトの名無しさん
07/04/10 02:12:26
おお、これは！
でも、PSもPDFもみんな見れない…。
右上のView or download:から本文を見るんだよね？
582:デフォルトの名無しさん
07/04/10 03:17:32
（さっきコテハンを使ってしまったのは失敗だった）
最近CiteSeerのミラーがどこもまともに機能してないなぁ...
こちらで っ[ URLﾘﾝｸ(citeseer.ist.psu.edu) ]
主張を要約すると「再帰関数を（わざわざ）Yコンビネータを使って定義するようにすると
- メモ化したくなった
- エラーの際にデフォルト値を返したくなった
- call treeを調べたくなった
等を含む色々な場合に拡張がすんなり行きますよ」というものです
まぁ読んだからって人生変わるほどのすごい論文ではないですが，小ネタとして
583:デフォルトの名無しさん
07/04/10 07:33:46
コンビネータ論理チュートリアル URLﾘﾝｸ(e.tir.jp)
584:デフォルトの名無しさん
07/04/10 07:50:12
>>580氏が別の分野でもλ関連やってる事を今朝初めて知ったｗ
585:デフォルトの名無しさん
07/04/10 22:08:02
やっぱ、頭の悪い人間が関数型言語とかに手を出しちゃいけないんだなぁってのが
この流れでよくわかった。
いちばんタチが悪いのは、単に無能なんじゃなくて「自分はわかっている」という
壮絶な勘違いにすぐ走ることだね。
586:デフォルトの名無しさん
07/04/10 22:18:42
で？
587:デフォルトの名無しさん
07/04/10 22:22:36
いちいち反応すんなよw
588:デフォルトの名無しさん
07/04/10 22:26:59
Barendregtが自由変数無しλ式指して
「あぁ～コンビネータの話？」って俺様定義するのと、
ヘタレがミニ言語作るだけの行為を指して
「俺、コンビネータ作っちゃおうかなぁ～」と意味不明発言するのでは
雲泥の差がある、ような気がしないでもない。
589:デフォルトの名無しさん
07/04/10 23:16:07
たぶんどっちもjargonだ
大して違わねぇよ
というような気がする
590:デフォルトの名無しさん
07/04/11 21:19:09
>>570
そっちじゃなくて、XMLを操作する手続きというかフィルタを合成していく方。
591:デフォルトの名無しさん
07/04/11 21:26:30
高階関数を使って再帰下降型パーサを構成する
といった類の話ですね。
592:デフォルトの名無しさん
07/04/11 21:28:56
いや慎重に言い直しておこう。
最近あぶない人が出没しているようだから。
高階関数を使って構文解析木を処理していく
といった類の処理なんじゃないですか？
593:デフォルトの名無しさん
07/04/21 12:18:15
ストリングリダクションについて調べたいんだけど取っ掛かりになりそうな本ってないだろうか。
スレ違いっぽくて悪いんだが他に訊けそうなスレがないんで頼む。
594:デフォルトの名無しさん
07/04/21 12:20:23
まだ項書換系とか学部レベルの勉強してるのか。
595:デフォルトの名無しさん
07/04/21 12:37:48
コンパイラ・スレの話題だな
596:デフォルトの名無しさん
07/04/28 23:49:44
関数型言語の性質をC++やその他の言語に実装する場合って
みんなどんな書籍参考にしてるのですか？
597:デフォルトの名無しさん
07/04/28 23:59:59
シュプリンガーの関数型言語作成本とか
598:デフォルトの名無しさん
07/04/29 00:04:29
>>597
なんて名前本ですか？
599:デフォルトの名無しさん
07/04/29 00:08:09
自分で探せ
あと、お前の実力では今読んでも力にならないと思う。
600:597
07/04/29 00:11:45
シュプリンガーじゃなくてプレンティスホールだったｗ
601:デフォルトの名無しさん
07/04/29 00:17:22
>>600
お前さん書籍の名前知らないんじゃねーのw？
プレンティスホールなんてもうねーだろw
602:デフォルトの名無しさん
07/04/29 00:19:56
>>600
プレンティスホールということは
The implementation of functional programming languages, Simon Peyton Jones, Prentice Hall 1987
でっか？
603:デフォルトの名無しさん
07/04/29 00:22:47
>>601-602
もともと一冊程度しかねぇんだから
いちいち煽んなよクズ
604:デフォルトの名無しさん
07/04/29 00:25:41
>>601
６００ではないが(この板はIDが出ないんだなorz)、たしかにピアソンになってるけど
プレンティス・ホールの名前も残ってるぽいし、過去の出版物だとその当時の名前で
引用するので、あながち>>600がまちがってるわけでもない。・・・と思う。
参考：
Pearson Education
URLﾘﾝｸ(www.pearsoned.com)
Pearson Prentice Hall
URLﾘﾝｸ(phcatalog.pearson.com)
605:デフォルトの名無しさん
07/04/29 00:27:37
>>596
URLﾘﾝｸ(citeseer.ist.psu.edu)
みたいな論文とかじゃね？
606:デフォルトの名無しさん
07/04/29 00:30:55
>>597
URLﾘﾝｸ(www.etl.luc.edu)
607:デフォルトの名無しさん
07/04/29 00:40:47
>>604
いちいちもったいぶった物言いして他人に不快感を撒き散らすなよクズ
608:デフォルトの名無しさん
07/04/29 00:49:52
>>596
シュプリンガーのLNCSにありそうな希ガスが見ちゃいねえ。すまん。
609:デフォルトの名無しさん
07/04/29 00:52:11
表紙が紅白の本だったっけ
610:デフォルトの名無しさん
07/04/29 00:58:52
>>609
SPJ本は、そう。
International Series in Computer Science(pub:PH)に共通の装丁があの紅白だと思う。
611:デフォルトの名無しさん
07/04/29 01:03:39
えーと結局どの本なのかいまだに見付けられないヘタレなのですが
612:デフォルトの名無しさん
07/04/29 01:12:28
つかSPJ本の古い方って、PSファイルで公開されてなかったっけ？
613:デフォルトの名無しさん
07/04/29 01:15:17
>>612
うーんと、
URLﾘﾝｸ(research.microsoft.com)
のことでしょうか？
614:デフォルトの名無しさん
07/04/29 01:18:57
>>607
604ではないが、どの辺が「もったいぶってる」のかも、何を不快に思うのかもまったくわからん。
メンタルクリニックでも行ったほうがいいんじゃないか？
615:デフォルトの名無しさん
07/04/29 01:21:23
>>614
604ですけど俺は無視したですよ。
あの手のは反応を楽しむから、放っておいたほうがいいと思うので。
スレ趣旨と関係ないから消えますね。
616:デフォルトの名無しさん
07/04/29 01:21:29
>>613
ですね。
617:デフォルトの名無しさん
07/04/29 01:23:03
そもそも回答に対して煽り口調で詰め寄る人間が居るから
荒れるのだと思う。
丁寧に質問し、煽らない。これが重要。
618:デフォルトの名無しさん
07/04/29 01:23:37
>>616
さんくすこ。
この本は関数型言語の実装や動作の理解にはいいけど
もともとの質問(>>596さん)ような目的にはどうなんだろ。
619:デフォルトの名無しさん
07/04/29 01:24:13
語尾にwを付ける人間の発言はスルーすべき。
620:デフォルトの名無しさん
07/04/29 01:26:48
>>618
どうでしょうね。
最近それっぽい人間がboostの使い方やら
ドラゴンブックの読み方を質問しまくってる状況だから
目的に向いてるか向いてないか、当人も判断できないんじゃないかと
思っていますが。
621:デフォルトの名無しさん
07/04/29 01:32:24
>>608
表紙が銀色とかのレクチャーノートシリーズね。・・・つかあの中から何を探せと言うんだ
622:デフォルトの名無しさん
07/04/29 10:21:04
あれは元々心当たりやポインタのないような人間が探すものなのか……?
623:デフォルトの名無しさん
07/04/29 23:03:44
F# ってまだ生きてるの？
624:デフォルトの名無しさん
07/05/01 00:27:37
仮想化とは対象物を不完全ながらもその性質や姿を模倣し現出させることだ。
対して抽象化は、対象物のある特徴的な側面を抽出し概念化することだ。
仮想化で抽象化の技術が使われることはあるだろうが、その逆は考え難い。
コンピュータを使い、扇風機やコタツを抽象化することはできても、仮想化する
ことはできないのだ。少なくとも今の技術では無理だ。コンピュータがその姿形
を変えることはできないのだから。コンピュータが仮想化できるものは、コンピュー
タそのものが直接扱うものだけだ。例えば、仮想メモリ、仮想ネットワーク、仮想
マシン、仮想キーボードといったものだ。
抽象化した結果表現されるものは、設計者が想定した概念やイメージだ。しかし、
実在するものそのものではなく、人が考えたものであるために、このイメージは
非常に脆く、不安定だ。外部からの影響をもろに受け、形を変え易い。個々人が
持つイメージの些細な相違から認識のずれが生じ易い。扇風機の使い方は人に
よって異なることはないが、人がイメージしたものは、その生成から、破棄に至る
まで、非常に不安定な状態になり易い。それを防ぐには、イメージそのものをなる
べく強固なものにし、インターフェースに一貫性と整合性をもたせ、外因による影響
を受けに難くく、壊れ難くするための技術を見につけ、理解を深めておくしかない。
625:デフォルトの名無しさん
07/05/01 21:13:14
URLﾘﾝｸ(www.cbook24.com)
既出?
626:デフォルトの名無しさん
07/05/01 23:16:09
今日M$の人にF#はどうしたのか2時間ぐらいしつこく聞いたら
話してくれなくなった...酷いよ
627:デフォルトの名無しさん
07/05/01 23:45:48
F#最近新バージョン出たばかりじゃないか。どこを見てるんだ
628:デフォルトの名無しさん
07/05/02 00:15:13
>>626
あれ？今日なんかイベントあったっけ？
それとも仕事で趣味の話？
629:デフォルトの名無しさん
07/05/02 03:55:15
>>626
F# 1.9が出て、Active Patterns(ﾊﾞﾅｰﾅ構文)とか面白いものが出てきてるぞ。
少しは本家サイト見てみれ。
630:デフォルトの名無しさん
07/05/06 11:48:08
おい！気づいたんだが、Excelって関数型言語じゃね？
631:デフォルトの名無しさん
07/05/06 14:21:34
>>630
"Spredsheet functional programming" の話？
ずいぶん前にも似たような話があった気がするけど
632:デフォルトの名無しさん
07/06/07 20:16:24
Comegaが自然消滅したのを見ればF#が公式にVS一門に加わるまでは手なんか出せるはずが無い
633:デフォルトの名無しさん
07/06/07 20:30:08
>>630
あれは関数型言語ではなく、エンドユーザコンピューティングだ。
634:デフォルトの名無しさん
07/06/07 20:35:07
関数性とエンドユーザ性は直交しないの？
635:デフォルトの名無しさん
07/06/07 20:55:07
関数の無い言語って見たことないんだが
636:デフォルトの名無しさん
07/06/07 21:13:40
機械語やBrainfuckやPrologには関数がないんじゃない？
637:デフォルトの名無しさん
07/06/07 22:05:40
結構いっぱいあるよ
638:デフォルトの名無しさん
07/06/07 22:09:43
N88-BASIC とか
639:デフォルトの名無しさん
07/06/08 01:18:34
Fortressって関数型言語？
640:デフォルトの名無しさん
07/06/08 01:51:20
Prolog には関数あるよ。組み込みだけど。
641:デフォルトの名無しさん
07/06/28 06:49:48
まだあったのかこのスレ
642:デフォルトの名無しさん
07/07/01 15:20:52
関数型言語、あまりに動きがないな。
新しいことやってくれよ。
643:デフォルトの名無しさん
07/07/05 06:00:25
広まる前に枯れたから難しいな
644:デフォルトの名無しさん
07/08/29 18:43:31
私は普段 Python を使っています。
関数型プログラミングにおける reduce が分かりません。
"広い意味において"どのように理解しておけばよいのでしょうか？
説明のためにちょっと定義:
A(f,[0,1,2,3,4]) => f(0,f(1,f(2,f(3,4))))
B(f,[0,1,2,3,4]) => f(4,f(3,f(2,f(1,0))))
C(f,[0,1,2,3,4]) => f(f(f(f(0,1),2),3),4)
D(f,[0,1,2,3,4]) => f(f(f(f(4,3),2),1),0)
(1). 正直 reduce だけではどれなのか分からない。（また fold も曖昧である）。
(2). fold は reduce と同義。
(3). 普通は (reduce_r == fold_r == A) , (reduce_l == fold_l == C) で通じている。
(4). f(x,y)==f'(y,x) なら A(f)==D(f') になるので、結局のところ A,D を区別しない。（同様にB,Cも区別しない）。
(5). A,D と B,C は実装の問題だと考えている。
645:デフォルトの名無しさん
07/10/03 23:13:32
foldとreduceは違うんじゃないの？
fold:リスト要素の型との戻り値の型はちがっても良い
reduce:同じ
じゃない？
646:デフォルトの名無しさん
07/10/05 08:47:15
俺もほぼ同義でいいと思うが、あえて分ければそうかもしれんね。
別の表現をすれば、最初の項を別途与える=fold、リストからとる=reduce ?
647:デフォルトの名無しさん
07/10/09 16:20:56
どうもありがとうございます。
ニュアンスに微妙な違いがあるんですね。
648:デフォルトの名無しさん
07/10/09 23:01:13
>>642
あたらしいことｗｗｗ
URLﾘﾝｸ(www.blue.sky.or.jp)
649:デフォルトの名無しさん
07/10/10 00:01:42
スゲエ、笑けるw
650:デフォルトの名無しさん
07/10/10 02:07:38
>>648
なんぞこれｗｗｗｗｗ
651:デフォルトの名無しさん
07/10/10 14:19:10
ドキュメントが英語なのが最大の笑い所な気がするｗ
652:デフォルトの名無しさん
07/10/10 15:48:39
>>648
これはワラタ。
けど、手で書きにくすぎる上に機械生成が簡単過ぎるので、
変態言語としては微妙な気がする。
あと、公式の「はいはいわろすわろす」を逆アセしてみたら、
サイズを節約するためのトリックが使ってあって面白かった。
URLﾘﾝｸ(up.uppple.com)
653:デフォルトの名無しさん
07/11/01 01:50:17
scalaってどうよ？
654:デフォルトの名無しさん
07/11/05 19:12:40
Genericsの互換性がないのが痛すぎる＞Scala
F#のほうがよさげ。
655:デフォルトの名無しさん
07/11/14 14:31:47
JavaのGenericsと互換性がないってこと？
それはちょっとキツいかも。
思えば generic な HashMap も java.util のそれではなく scala.collection.mutable.HashMap だったり…
しかし今Scala触ってて Option型と for記法に感動したんだが。
val o2 = new HashMap[int,int]();
o2(1) = 2
for(i<-o2.get(1)) {println(i)}
for(j<-o2.get(2)) {println(j)}
まんまMaybeモナドやん！ Scala最強
656:デフォルトの名無しさん
07/11/14 14:35:25
書き忘れた。 Scala かじらないと何のことかわからんな。
o2(1) = 2
for(i<-o2.get(1)) {println(i)} // 2が出力される
for(j<-o2.get(2)) {println(j)} // 何も出力されない (エラーにならない)
for(i<-o2.get(1); j<-o2.get(2)) {...} // j の束縛に失敗するので何も出力されない (エラーにならない)
まじで Scala の範囲内なら NullPointerException 撲滅できそう。
既存のコード書き直すと Option型だらけになる場合もありそうだけど。
それだけに、 asInstanceOf の戻り型をなぜ Option 型にしなかったのか理解に苦しむ…
657:デフォルトの名無しさん
07/11/15 23:11:06
Scala わかんないけど、それ単に key = 2 のリストを返してるだけちゃうん？
658:デフォルトの名無しさん
07/11/19 21:16:55
ハッシュの戻り値が Option に包まれているのが良いんです。
Javaだと null かもしれない Integer 型を扱う必要があるけど、
Scala なら Option[int] みたいな感じで、 無効な値を含む場合を陽に切り分けることができるっす。
これだけだと、無効な値を含むかどうかをチェックしなきゃだめでめんどくさいんですが、
Haskell でいう Maybe モナドみたいな書き方がサポートされているので、if文が必要なくなり楽ができます。
しかも JVMで動く型付きの関数型言語。ちょっと良さげだと思うです。
>>654 みたいな欠点はあるけど。
659:デフォルトの名無しさん
07/11/20 13:06:09
そのうちoption型は、どの言語も持つようになって、
それ前提にライブラリ構成されるようになるかもね。
C++もboost::optionってのがある。
660:デフォルトの名無しさん
07/12/06 07:18:16
つまりfailure-oblivious computingってやつ？
661:デフォルトの名無しさん
08/03/16 17:25:51
組み込み用にクロス開発できる関数型言語処理系ってありますか？
具体的に言うと、ARMやMIPS-RのGCCでスタティックリンクできるものがあれば
紹介して頂けないでしょうか。
662:デフォルトの名無しさん
08/03/16 20:58:12
optionalって.NETでいうとNullableみたいなもの？
663:デフォルトの名無しさん
08/03/17 03:39:13
nullでもnilでもなく、Noneですがそうです。
関数型言語的に言うと、domianがliftingされてるわけです。
664:デフォルトの名無しさん
08/03/17 10:54:19
どみあん
665:デフォルトの名無しさん
08/04/01 12:25:53
何度も出た話題かもで恐縮だけど、関数型言語の位置付けってこれからどうなっていくの？
手続き型より巨大になっていくか、融合していくか、今のままなのか。
666:デフォルトの名無しさん
08/04/01 13:37:07
未来のことなんてわかんねーｙｐ
667:デフォルトの名無しさん
08/04/02 01:18:44
関数型言語が本流になることはないでしょうが、
プログラムに参照の透明性があるのは手続き型言語でも好ましいことなので、
関数型言語で産み出された種々の機構が
手続き型言語に結び付けられるのではないでしょうか。
668:デフォルトの名無しさん
08/04/02 04:15:20
50年間そうだったのだからそうだろう。
669:デフォルトの名無しさん
08/04/02 07:26:36
実際そんな感じだよな。
670:デフォルトの名無しさん
08/04/02 10:39:27
手続き型言語では簡単にできることが、
純粋関数型言語では困難なことがある。
その困難に立ち向かって獲得した手法は、
他の言語でも極めて有益なことがある。
不自由さの中で獲得した手法がきわめて豊穣である、
これは数学基礎論で起っていることと同じである。
671:デフォルトの名無しさん
08/04/02 10:51:01
関数型言語はきっと本流になるよ
主流の言語は確実にこっちに向かってる
少なくとも、そう信じないとやってられない
672:デフォルトの名無しさん
08/04/02 10:52:43
関数型言語は前と同じところに立っているのにな。
673:デフォルトの名無しさん
08/04/06 10:16:39
関数型って逐次処理は一切ないの?
それとも数学的に(ラムダ計算で?)合成可能な関数オブジェクトを持った
普通のプログラミング言語になるの?(つまりc#とか既に近い所にあるのか)
674:デフォルトの名無しさん
08/04/06 10:29:14
言語に逐次処理が組み込まれているかどうかは別として、
逐次処理が「表現できない」言語は実用にならないから、
普通の関数型言語はどれも逐次処理を表現できるようになってる
どうやって表現するかは言語ごとに違って、組み込みで持ってるの(Scheme,ML)とか、
データに関数を適用して、その結果に関数を適用して…という構造で逐次処理を表すの(Clean)とか、
処理自体を第一級のデータとして扱うの(Haskell)とか
675:デフォルトの名無しさん
08/04/06 10:34:35
関数型でも、Lispとかで逐次処理をだらだら書いてるソースを見かけると、
手続き型とあんま変わんなくね？と思うことがある。
一方で、非関数型でも、定義を並べる感じできれいに書かれてるものもある。
言語も重要だが、書き手の心構えのほうが影響でかい気がする。
676:デフォルトの名無しさん
08/04/06 10:41:26
レスどうも。ポインタありがとう。
やっぱ書き方というか設計によるところもあるんですね。
677:デフォルトの名無しさん
08/04/06 10:42:02
関数型言語はあくまで関数プログラミングを支援する言語だからな
Haskellで命令的に書くことも不可能じゃない
678:デフォルトの名無しさん
08/04/06 11:42:58
>>674
基本的には関数の評価が強制されることを利用して順序をつけるので同じじゃないかな
679:デフォルトの名無しさん
08/04/06 12:02:37
>>678
例えばSchemeの((lambda () a b c))でa b cが順に評価されるのを
「関数の評価が強制されることを利用」と表現するのは無理がないか？
Haskellの動作に至っては関数と全く(特定の処理系の内部実装の話を別にすれば)関係ない
680:デフォルトの名無しさん
08/04/07 01:32:03
論理型言語の現状はどうなってるの？