LLにおける関数型プログラミング

**デフォルトの名無しさん** · 2012/08/16(木) 22:17:50.32

339 返信：153[sage] 投稿日：2012/08/16(木) 22:16:29.83
>>314
>関数型言語でなければならないという観点は間違ってる気がする

ああ、これについては同感だね
現状のどの関数型言語も文字列、パターン、ハッシュの操作に難があるから、
現行LLであるPerl/Python/Rubyを置き換えるには無理があると思う

ただし、関数型言語にも良い特性がある訳で、実際に(LLを含む)多くの言語に影響を与えている
だから自分は「LLにおける関数型プログラミング」に注目している

**デフォルトの名無しさん** · 2012/08/16(木) 22:20:44.31

そうか

うゆ · 2012/08/16(木) 22:24:22.07

rubyが最強っていってんじゃん

**デフォルトの名無しさん** · 2012/08/16(木) 22:29:24.64

いい加減関数型とかうるさい

**デフォルトの名無しさん** · 2012/08/16(木) 22:42:07.04

>>1
> 現状のどの関数型言語も文字列、パターン、ハッシュの操作に難があるから、

その難というのを、もっと明確に言ってほしい。

たとえば、＊＊というプログラムをする上で必要な
文字列に関する＄＄という操作が、
どの関数型言語でもできない、あるいはやりにくい。

など

パターンとハッシュに関しても同様に。

**デフォルトの名無しさん** · 2012/08/16(木) 22:46:25.19

【関連サイト: Python編】

・関数型プログラミング HOWTO ― Python 2.7ja1 documentation
　http://www.python.jp/doc/nightly/howto/functional.html

・魅力的なPython: Pythonでの関数プログラミング: 第1回 - IBM dw
　http://www.ibm.com/developerworks/jp/linux/library/l-prog/

・Pythonの技法：関数型言語スタイル「関数の部分適用」 - ZDNet Japan
　http://builder.japan.zdnet.com/script/20364411/

・Pythonの"関数型"の機能の起源 - The History of Python.jp
　http://python-history-jp.blogspot.jp/2009/05/python.html

**デフォルトの名無しさん** · 2012/08/16(木) 22:54:29.59

カリー化なんかもRubyで簡単にできる時代

def add(a, b)
　return a + b
end

def curry(f, a)
　return lambda { |b| method(f).call(a, b) }
end

add1 = curry(:add, 1)
p add1.call(2)

Rubyは関数オブジェクトを扱えるので、
置き換えるも何も、既にRubyは関数型言語
当然純粋関数型言語ではないし、関数型言語らしく書かない事もできるけど、
関数型言語としての特性を備えている事に変わりはない

そもそもどの言語でも最近関数オブジェクトの取り入れが盛んで、
関数型言語かどうかという分類が既に成り立たなくなってる
C++11ですらカリー化できる時代、
可能なのはせいぜい純粋関数型言語か否かという区別程度だな
http://ideone.com/H82Pn

uy · 2012/08/16(木) 22:57:19.48

同意ですよ

**デフォルトの名無しさん** · 2012/08/16(木) 23:08:53.70

>>7
それのどこがカリー化だアホめ

**デフォルトの名無しさん** · 2012/08/16(木) 23:09:47.31

関数名がカリーだろよく見ろ

**デフォルトの名無しさん** · 2012/08/16(木) 23:10:41.08

以降おいしいカレーとチャーハンの作り方のスレ

**デフォルトの名無しさん** · 2012/08/16(木) 23:13:14.87

間を取ってドライカレーで

**デフォルトの名無しさん** · 2012/08/16(木) 23:13:58.81

>>7
それはカリー化ではなく、部分適用です。

uy · 2012/08/16(木) 23:18:13.64

http://www.ruby-doc.org/core-1.9.3/Proc.html#method-i-curry

はいはいわろ

**デフォルトの名無しさん** · 2012/08/16(木) 23:31:18.63

例えば f (a, b, c) という3引数の関数に対して、これをカリー化した関数というのは、
y (b, c) という2引数の関数を戻り値として返す1引数の関数 g (a) のことだ。

関数 f から関数 g を作ることをカリー化という。

では >>7 の中でカリー化された関数とはどれか、明確に示してみよ。

**デフォルトの名無しさん** · 2012/08/16(木) 23:34:41.03

んじゃこれで
1.9では>>14なんてのもあるみたいだが

def add(a, b)
　return a + b
end

def curry(f)
　return lambda { |a| lambda { |b| method(f).call(a, b) } }
end

add1 = curry(:add).call(1)
p add1.call(10)

**デフォルトの名無しさん** · 2012/08/16(木) 23:34:48.19

f :: (a, b, c) -> d から
g :: a -> (b -> (c -> d)) を作るのがカリー化

**デフォルトの名無しさん** · 2012/08/16(木) 23:40:44.49

>>16
２引数の場合しか動かんようなクソコードなら貼らなくて良いよ

**デフォルトの名無しさん** · 2012/08/16(木) 23:49:07.32

ソースコードに全角スペース入れる奴なんなの？

**デフォルトの名無しさん** · 2012/08/16(木) 23:53:57.05

お前は黙ってろ

**デフォルトの名無しさん** · 2012/08/17(金) 00:02:31.38

>>17
違う

f :: (a, b, c) -> d から
g :: a -> ((b, c) -> d) を作るのがカリー化だ。

-- Wikipedia : カリー化（http://ja.wikipedia.org/wiki/%E3%82%AB%E3%83%AA%E3%83%BC%E5%8C%96）
> 複数の引数をとる関数を、引数が「もとの関数の最初の引数」で戻り値が「もとの関数の残りの引数を取り結果を返す関数」であるような関数にすること。

カリー化された関数の戻り値は「もとの関数の残りの引数を取り結果を返す関数」だ。

(b, c) を勝手に b -> c -> と形を変えることまではカリー化には含まれない。

**デフォルトの名無しさん** · 2012/08/17(金) 00:08:24.78

>>21
ごめんねーwikipediaは英語見てたわーww

http://en.wikipedia.org/wiki/Currying

> In mathematics and computer science, currying is the technique of transforming a function
> that takes multiple arguments (or an n-tuple of arguments) in such a way that
> it can be called as a chain of functions each with a single argument (partial application).

**デフォルトの名無しさん** · 2012/08/17(金) 00:12:29.05

>>14がそれを満たしてんじゃないの？

**デフォルトの名無しさん** · 2012/08/17(金) 00:24:16.48

>>14 のレスはあぼーんされて見えないから無視する。

Ruby でカリー化が本当にできるのかどうかは知らない。
少なくとも、確実に >>7 はカリー化ではないと指摘しているだけだ。

>>16 もなんか怪しい気がする。
カリー化された関数とはどれのことか？

**デフォルトの名無しさん** · 2012/08/17(金) 00:29:51.41

>>16はcurry(:add)でカリー化はできてる
ただ、２引数にしか使えない

1.9ではまんまcurryメソッドが用意されてるので変な事する必要ない
http://www.ruby-doc.org/core-1.9.3/Proc.html#method-i-curry

**デフォルトの名無しさん** · 2012/08/17(金) 00:47:30.59

Pythonのfunctionalモジュールにcurryがあるけど
自前で定義するとこんな感じか

def curry(f):
    n = f.__code__.co_argcount
    def _(args=[]):
        return f(*args) if n == len(args) else lambda x: _(args + [x])
    return f if n == 0 else _()

@curry
def foo(a,b,c):
    return a + b + c

print(foo(1)(2)(3))

**デフォルトの名無しさん** · 2012/08/17(金) 09:01:48.91

そもそもrubyはHLですしおすし

**デフォルトの名無しさん** · 2012/08/17(金) 13:16:16.85

>>5
>その難というのを、もっと明確に言ってほしい。

現行のLLにはこれらデータを「簡潔に表現」できる専用の記法/構文がある
以下はRubyの例(これらはPerl(awk?)から影響を受けた(=パクッた)と思われる)

【文字列】　　文字列リテラルには「式展開」や「ヒアドキュメント」がある
　　　　　　たとえば "my name is #{$ruby}" は、format "my name is %s", $ruby よりも
　　　　　　簡潔に書ける
【パターン】　「正規表現リテラル」がある。たとえば /^Ruby is OOPL/ は、
　　　　　　Regexp.new "^Ruby is OOPL" よりも簡潔だ
【ハッシュ】　「ハッシュ式」とハッシュ操作のための構文がある
　　　　　　たとえば {a: 1, b: 2} は Hash.new [:a, 1, :b, 2] よりも簡潔だし、
　　　　　　obj[:a] は obj.fetch :a よりも簡潔に書ける

これらの記法/構文はRuby全体からすればほんの一部であり、
LLの主用途(主戦場)である日常的なテキスト処理に特化した様々な工夫が施されている
これらの多くは関数型言語ではライブラリ関数として提供され、
同等な処理は書けてもLLの専用記法/構文と比較すれば冗長である(=めんどくさい)と考える

**デフォルトの名無しさん** · 2012/08/17(金) 13:34:56.55

> {a: 1, b: 2}

この暗号みたいなの何？

**デフォルトの名無しさん** · 2012/08/17(金) 13:45:54.65

>>28
× 現行のLL
○ Ruby

**デフォルトの名無しさん** · 2012/08/17(金) 13:47:00.73

RubyってPerlが糞だと言われたことと同じ轍を踏んでるよな

**デフォルトの名無しさん** · 2012/08/17(金) 14:20:06.15

>>29
Ruby 1.9で導入された新しいハッシュ式の記法
以前の記法 {:a => 1, :b => 2} と同じ

**デフォルトの名無しさん** · 2012/08/17(金) 14:24:36.76

糞分かりにくいな

28 · 2012/08/17(金) 14:33:34.42

>>31
UNIXプログラミング環境に住み慣れた人なら、
sh や awk でなじみがあるから好意的に受け止める人は多いのではないかと思う
少なくともWeb開発の世界では、Perlの記法を引き継いだPHP(と一部でRoR)が主流だし...

まあWindowsプログラマからすれば、これらの記法に違和感があるというのは認めるw

**デフォルトの名無しさん** · 2012/08/17(金) 14:43:29.41

PHPが主流なのはCの記法に似てるからだろｗ　何言ってんだコイツは…

**デフォルトの名無しさん** · 2012/08/17(金) 14:52:20.75

Rubyの関数型プログラミングスレで良かったんじゃねぇ～？
元のLL云々ってRuby＆関数型マニアのコイツがLLスレで暴れたいだけの口実だったんだしぃ～
なんかLLの話するのかと思って釣られてくる被害者が出そうだわぁ～
まーた関数型言語用のお題ってのを早速コテみたいなのをつけ出したコイツが出してくるんだろぉ～
都合の良いルールで縛ってさぁ～、結論ありきの議論は面白いですかぁ～

28 · 2012/08/17(金) 15:25:41.58

>>36
>Rubyの関数型プログラミングスレで良かったんじゃねぇ～？

んー自分はそれでも良かったけど、せっかく>>1がスレを立ててくれたんだから、
Rubyに限定せず、あらゆるLLで関数型プログラミングを語る場になれば....と思う
特に(>>6にあるように)Pythonは関数型プログラミングに関する情報が豊富みたいだから、
Python&関数型マニアの参加は大いに歓迎したいな

**デフォルトの名無しさん** · 2012/08/17(金) 15:33:53.84

でも実践的な話は一切出来ないみたいだから隔離して良かった

**デフォルトの名無しさん** · 2012/08/17(金) 15:43:48.64

>>28
camlp4使って構文拡張すれば足りるな

uY ◆gXFLM6waxs · 2012/08/17(金) 17:43:13.21

＞Perlの記法を引き継いだPHP
＞Perlの記法を引き継いだPHP
＞Perlの記法を引き継いだPHP

それ変数につく$だけだろｗｗｗｗｗｗｗ

Perlの汚い部分を引き継いだのがPHP

綺麗な部分だけ選んで引き継いだのがRuby

Rubyでは$変数をあまり使わない
perと同じように $_ 使える部分もあるんだけど、基本的には使えない場所のが多い　使えてもいい気がするんだけどな

**デフォルトの名無しさん** · 2012/08/17(金) 18:41:20.65

>>33
実際にはActiveRecord/Rails系列の「キーワード風」メソッド引数の mes(sym1: val1, sym2: val2) のときに*しか*使用されない
これ以外の場面で使うのはなにもわかってないただのバカで早晩自爆するので放置でOK

uY ◆gXFLM6waxs · 2012/08/17(金) 19:08:08.44

なんていうか
シンボルが
:symbol

こうだから
xx: 4

だといったん、タイプがとまるんだよね

かといって
:xx => 4
だとタイプ数があるし

2.0に期待するしかない

**デフォルトの名無しさん** · 2012/08/17(金) 19:29:55.50

>>28
では、逆に関数型言語にはあって、Ruby などの LL には無い機能や仕組みで、
是非 LL にも取り入れてほしいと思ってるものは何？

こちらも詳細にお願いします。

**デフォルトの名無しさん** · 2012/08/17(金) 19:40:22.07

Rubyは同じことをやるのに手段を大量に提供するコンセプトなのかもしれないけど
それって人のコード読むときに苦労するよな。そういう用途は対象外なのかもしれないが。

uY ◆gXFLM6waxs · 2012/08/17(金) 21:02:31.33

>>44
大量の手段あるけど
それはC++みたいにソース見ただけじゃ何やってるかわからない構文は無いんだよ
手段とはいっても
オブジェクト.メソッド　で呼び出す形だから
メソッドの動作さえ覚えれば良いだけ

こういうところの考えからPythonとかのリスト内包表記は入れないんだと思う

**デフォルトの名無しさん** · 2012/08/17(金) 21:17:26.95

>>44
DSＬに関しては「読みにくくて書きづらくて覚えにくい」で意見の一致をみている
一時期ライブラリがなんでもかんでもDSLっぽい記述になったりもしたが、これからはそんなことは無いだろう

**デフォルトの名無しさん** · 2012/08/17(金) 22:11:38.46

殆どはリテラルの表記の問題ということだな

uY ◆gXFLM6waxs · 2012/08/17(金) 22:42:52.85

バカには無理

28 · 2012/08/18(土) 00:04:09.84

>>43
まず各LLにおける関数型プログラミングの適性度には大きな差異があること、
およびLLプログラミングではRubyしか深い経験/知識が(自分には)無いという理由から、
以降で述べる要望は「Rubyだけを対象」にしていることを断っておきます

最初の要望は、理想論であるけど「型推論を前提とした静的型付け」です
LLの主用途は(>>28で述べたように)日常的なテキスト処理であるけれど、
RailsやmRubyなどの登場によって「Rubyで製品を開発する」ケースが増えつつあります
この場合、生産性(効率的な開発)も大切ですが、長期間に渡って運用/開発が継続するという
性格から、品質(バグ発生率や保守性)が最も重要であると考えます
この高品質コード設計においては、生産性(簡潔さ)と高品質(安全性)を兼ね備えた
「型推論を前提とした静的型付け」がRubyに求められることになるでしょう

ただし、サブセットのRuby言語仕様であれば型推論の実験的実装について
いくつかの報告が存在しますが、完全なRuby言語仕様についてはかなり遠い目標でしょう
そこで、これに代わる現実論(=妥協案)として「省略可能な動的型検査構文」を要望したい
これは単純に def hoge(num : Integer, str : String) : MyClass といった構文でもいいし、
typexpr Integer * String -> MyClass のような明示的型式宣言でもいいし、
あるいはPythonのデコレータ記法を応用した型検査手法をパクってもいいと思います
なお、当たり前ですがこの要望は組み込み/標準添付ライブラリに関しても適用されるべきです

この要望は、ドキュメンテーションの改善にも役立てることができます
現在のRubyコミュニティでは、コメントとして記述された型情報を含む解説を抽出するという
JavaDocスタイルの文書化が主流です(たとえば「引数 num は整数、str は文字列 ......」)
ここで、もしも動的型検査構文が導入され、かつ型情報を外部へ出力できるようになれば、
そこからメソッドの型に関する解説を文書の一部として自動生成できるようになるはずです
また「コードとコメントの乖離」というJavaDocスタイル固有の問題(の一部)も解消されます

(続きは、また明日)

**デフォルトの名無しさん** · 2012/08/18(土) 01:36:00.45

なんで日本はRubyオタクばっかなの？

uY · 2012/08/18(土) 02:49:47.77

Ruby会議とかいう謎の宗教活動が頻繁に行われてるからだよ

**デフォルトの名無しさん** · 2012/08/18(土) 08:09:05.11

Rubyにこだわらず、Haxeでもやればいいのに。

**デフォルトの名無しさん** · 2012/08/18(土) 11:30:54.68

RubyはHL

28 · 2012/08/18(土) 13:54:42.00

(>>49の続き)

二番目の要望は、「可変(mutable)な操作と不変(immutable)な操作の明確化」です
具体的には、Rubyにはオブジェクトの状態を破壊的に更新するメソッドであれば、
そのメソッド名の末尾に !(感嘆符) を付けようという弱いルールが昔から存在していました
(この末尾感嘆符ルールは、Lisp文化に由来すると思われます)
けれどもこのルールは一般にはほとんど普及していませんし、
残念なことに組み込みクラスですらルールが守られていないケースがあります
たとえば、Hashクラスには二つのハッシュを(破壊的に)結合する可変操作merge!と
破壊せずに結合するmergeがある一方で、merge!と同じ可変操作updateが存在します
これはRuby 1.8 -> 1.9 の時点でupdateを廃止するか、あるいはdeprecate(非推奨)を
判断して、リファレンスへ反映させるべきでした
組み込み/標準のクラスですら平気で逸脱しているのだから、ユーザが遵守する訳がありません

関数型プログラミング作法の基本は
「(破壊的代入を含む)副作用を避けた参照透明性のあるプログラミング」
であり、Rubyにおいては
「副作用を極力避けたり、参照透明性のある部分とない部分を意識的に使い分ける、
　あるいは副作用のあるコードを隠蔽する」
ことが、高品質コード設計技法では重要になります -- (LLバトルスレ25のレス#255も参照)

一般に普及している手続き型プログラミングでは破壊的操作が基本ですから、
「可変な操作と不変な操作の明確化」への関心はさほど強くなかったことが
現状の背景にあると思いますが、関数型プログラミングによる高品質コード設計では
こんな些細なこだわりも大切になるでしょう

(終わり)

**デフォルトの名無しさん** · 2012/08/18(土) 14:14:33.06

【関連サイト: Ruby編】

・Functional programming with Ruby
　http://www.slideshare.net/tokland/functional-programming-with-ruby-9975242
　http://code.google.com/p/tokland/wiki/RubyFunctionalProgramming

・Thinking Functionally In Ruby – A Great Presentation by Tom Stuart
　http://www.rubyinside.com/functional-programming-in-ruby-2713.html

・Functional Programming Techniques With Ruby: Part I & Part II
　http://rubysource.com/tag/functional-programming/

・Adventures in Functional Programming With Ruby
　http://www.naildrivin5.com/blog/2012/07/17/adventures-in-functional-programming-with-ruby.html

**デフォルトの名無しさん** · 2012/08/18(土) 14:22:49.28

Both support some functional programming constructs,
but Ruby is arguably better suited to a functional programming style.

Lambdas in Python are generally very short, because lambdas in Python are
restricted to expressions and cannot contain statements.
Ruby's lambda support is far more flexible,
allowing for lambda expressions of arbitrary length.

In a similar vein, Python 2.x's closure support is
more limited than Ruby's thanks to its limited support for lexical scope.
Python 3 introduces the nonlocal keyword which addresses this limitation
by allowing assignment to variables in outer non-global scopes.

On the other hand, as of version 1.8, which is still used widely,
Ruby does not support tail-call optimization for recursive functions,
whereas Python uses a decorator to implement tail-call optimization.
Ruby 1.9 ― the current stable release ― can currently be compiled to
support tail-call optimization.

　"Functional Programming - Python vs Ruby"
　http://www.wikivs.com/wiki/Python_vs_Ruby#Functional_Programming

**デフォルトの名無しさん** · 2012/08/18(土) 14:57:41.48

>>54
> 可変(mutable)な操作と不変(immutable)な操作の明確化

破壊的な操作を内部に一カ所でも含む関数は破壊的になるから、
まともに明確化して分けようとすると、結局 Haskell の IO モナドみたいになりそう。