カリー化談義 - あどけない話
最近、スタートHaskellで「カリー化された関数のメリットは何か？」という質問が出た。そのすぐ後に、kmizuさんがカリー化の誤用に対して警鐘を鳴らしてしていた。僕からするとkmizuさんの「カリー化の定義」も誤用に思えたので、調べるとともに考えたことのまとめ。 いろんな定義 「カリー化する」という用語は、すくなくとも以下の3つの意味で使われているようだ。 部分適用という意味 これは明らかに間違い 「複数の引数を取る関数」を「一引数を取る関数のチェインに直す」こと これはkmizuさんの定義。世間でもよく使われる。 「構造体を一つ取る関数」を「構造体のメンバーを複数の引数にばらし、一引数を取る関数のチェインに直す」こと これは僕の定義。というか、Haskellコミュニティの定義。 「部分適用」の意味で使うのは明らかに間違いのなで排除。定義2と3について議論する。あとで、部分適用とは何かに
カリー化関数 (curried function) について - (new Hatena).blog()
SML という言語のテキストを読んでいて、これまで自分がカリー化という言葉をよく理解せずに使っていたことに気付きました。 どうやら部分適用の概念と混同していたようです。 一般に、ML や Haskell のような関数型言語においては、カリー化とは n 要素タプルを取る関数 fun f (x,y) = z を、n 引数関数 fun curried_f x y = z に変形することと同義らしいです。(n > 1, z は適当な式とします) ML 等では n 引数を取る関数 fun f x1 x2 ... xn = z (* 1 *) は、実体としては次のように1引数関数が n 個連なったものとして定義されています。 val f = fn x1 => fn x2 => ... fn xn => z (* 2 *) (1 と 2 は同値であり、1 は 2 の構文糖衣に過ぎません) f は、最初の
ML っぽいカリー化関数を定義するマクロ - (new Hatena).blog()
ML とか Haskell のコードを読む時に私がどうしても憧れてしまうのが、自動的にカリー化定義される関数です。 Scheme にもカリー化関数を定義する構文自体は存在します (処理系にもよるでしょうが)。 例えば、このようなラムダ式のネストで定義された関数を (define add3 (lambda (a) (lambda (b) (lambda (c) (+ a b c)))))次のようなスタイルで短く書くことができるんです: (define (((add3 a) b) c) (+ a b c))でも全然自動的ではないですし、必ず定義した通りに適用しなければいけません: (((add3 1) 2) 3)2番目と3番目の引数を同時に与える、とかは出来ないわけです。 そこでちょっと知恵をひねりまして、case-lambda を使って、あらゆる関数適用のパターンに応じたラムダ式をあらかじめ
Schemeでカリー化
Haskellの有名な特徴として、関数が勝手にカリー化されるという点があります。 要するにHaskellの関数は常に部分適用可能になっていて、f foo bar bazという関数適用は(((f foo) bar) baz)と解釈されています。これは非常に強力な機能で、汎用的な関数を目的に合わせて簡単に特殊化することができます。 Schemeやその他のLispでは、引数は必ず同時に与えないといけないので、カリー化したものを作ろうとするとクロージャを使って(define f (lambda (x) (lambda (y) (lambda (z) ...))))とでもしなければなりません。しかも呼び出すときには(((f foo) bar) baz)と、1つずつ順番に適用する必要があります。 私が欲しいのは、"（Haskellが透過的にやっているように）与えられた引数を先頭から順に束縛し、足りない
カリーをもっと -- ラムダで考えるカリー化 - 檜山正幸のキマイラ飼育記 (はてなBlog)
「もっとかしこいカリー化」で紹介した、nanto_viさん、kilreyさん、KENZさんのコードはいずれも、ラムダ式によるカリー化の表現と正しく対応しています。最初からラムダ計算で考えればよかった。「なんでそんなことに気が付かないんだ？」と言われそうですが、それはですね； 僕みたいに後知恵で理屈をこねるヘタレと、直観で判断しても正しい結果を得るエキスパートの違いですがね。テキスト処理の方法を思いついたら、そのまま無反省にやってしまったよ、僕は。＜＜実は脊髄野郎だろ で、以下、後知恵でヘタレ理屈こねます、コネコネェ。 内容： JavaScriptからfunctional風疑似言語へ 多変数関数のラムダ計算： 構文の定義 あらためてカリー化の定義 ラムダ計算規則と計算例 curry関数がカリー化になっていること 補足または蛇足 自分的には、式のモーフィングがニャンカ面白い。 ●JavaScr
はてなグループの終了日を2020年1月31日(金)に決定しました - はてなの告知
はてなグループの終了日を2020年1月31日(金)に決定しました 以下のエントリの通り、今年末を目処にはてなグループを終了予定である旨をお知らせしておりました。 2019年末を目処に、はてなグループの提供を終了する予定です - はてなグループ日記 このたび、正式に終了日を決定いたしましたので、以下の通りご確認ください。 終了日: 2020年1月31日(金) エクスポート希望申請期限:2020年1月31日(金) 終了日以降は、はてなグループの閲覧および投稿は行えません。日記のエクスポートが必要な方は以下の記事にしたがって手続きをしてください。 はてなグループに投稿された日記データのエクスポートについて - はてなグループ日記 ご利用のみなさまにはご迷惑をおかけいたしますが、どうぞよろしくお願いいたします。 2020-06-25 追記 はてなグループ日記のエクスポートデータは2020年2月28
JavaScript でカリー化、再び: Days on the Moon
以前、「JavaScript で引数束縛」において関数のカリー化を試みました。しかし、そこでカリー化された関数は、そのままでは一度しか部分適用ができず、また、最初の関数呼び出しは必ず部分適用として扱われていました。 function mean3(a, b, c) { return (a + b + c) / 3; } // 「JavaScript で引数束縛」における curry 関数。 var curriedMean3 = curry(mean3); curriedMean3(1)(2, 3); // => 2 curriedMean3(1)(2)(3); // => TypeError: curriedMean3(1)(2) is not a function // そのままでは部分適用を 2 回以上行えない。 // curry(curriedMean3(1))(2)(3) なら大丈夫
JavaScriptでカリー化 - 檜山正幸のキマイラ飼育記 (はてなBlog)
JavaScriptでカリー化。ありがち、つうか実際にあるでしょうね。小ネタと思ってやりはじめたら、意外と混乱した。一種のメタプログラミングのはずだが、実際にはテキスト加工処理。 内容： カリー化ってなに？ カリー化を行う関数を作る：準備 カリー化を行う関数を作る：テキストのパッチワーク カリー化を行う関数を作る：組み立て ●カリー化ってなに？ 2引数の関数f(x, y)に対して、「gがfのカリー化」だとは、f(x, y) = g(x)(y) が常に成立すること -- ゴチャゴチャ説明するより実例実例： functio sum(x, y) { return x + y; } このsumのカリー化の例： function curried_sum(x) { return function (y) {return sum(x, y);} } curreid_sum関数は1引数で、戻り値として関数
JavaScript で引数束縛: Days on the Moon
引数束縛 (カリー化) の話。まずは「JavaScriptでカリー化」(檜山正幸のキマイラ飼育記)。タイトルを見てどこかで聞いたような話だなと思ったら「関数の変形」(Effecttive JavaScript - Dynamic Scripting) だった。だが、前者は文字列に戻してから評価というのが力技っぽくて個人的に好きでないし、後者は汎用的過ぎていささかわかりにくい。そこで今回は先頭の引数から束縛していくというのに的を絞ってみたいと思う。 まず第 1 引数のみを束縛する場合。Function#apply を使えば引数を配列として渡せるので、束縛された値と後から渡された引数とを連結してやればいいのではないか。 function curry(func) { return function (first) { return function () { var args = Array.p
Currying != Generalized Partial Application?! | Lambda the Ultimate
I had mistakenly learned that curry was a form of generalized partial application from the paper : Function Currying in Scheme by Jeffrey A. Meunier and the Wikipedia entry (I should have known better), however I was mildly reprimanded for making this novice mistake in a recent paper submission to ICFP. There was a short post to the Scheme mailing list some time back summing up the problem. In my
はてなグループの終了日を2020年1月31日(金)に決定しました - はてなの告知
はてなグループの終了日を2020年1月31日(金)に決定しました 以下のエントリの通り、今年末を目処にはてなグループを終了予定である旨をお知らせしておりました。 2019年末を目処に、はてなグループの提供を終了する予定です - はてなグループ日記 このたび、正式に終了日を決定いたしましたので、以下の通りご確認ください。 終了日: 2020年1月31日(金) エクスポート希望申請期限:2020年1月31日(金) 終了日以降は、はてなグループの閲覧および投稿は行えません。日記のエクスポートが必要な方は以下の記事にしたがって手続きをしてください。 はてなグループに投稿された日記データのエクスポートについて - はてなグループ日記 ご利用のみなさまにはご迷惑をおかけいたしますが、どうぞよろしくお願いいたします。 2020-06-25 追記 はてなグループ日記のエクスポートデータは2020年2月28
Curry Forward
If you are not automatically redirected use this link to the current home page of Curry.
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
http://nicosia.is.s.u-tokyo.ac.jp/pub/essay/hagiya/h/curry