2ちゃんねる★スマホ版★■掲示板に戻る■全部1-最新50

クロージャって何がいいの? [転載禁止]©2ch.net

1 :
デフォルトの名無しさん
2014/11/08(土) 13:11:47.84 ID:6V2MLUHb
関数型言語に必ずくっついてるこれ
いらんでしょ?匿名クラスで充分でしょ
2 :
2014/11/08(土) 13:17:58.06 ID:rszc5DFq
マジレスすると、クロージャーよりも
関数内関数の方がいい。

クロージャーは変数スコープが不必要に広い。

多くの場合、クロージャーの外は見える必要がない。
逆に見えてしまうと不用意に変数を書き換えてしまう。

関数内関数がない言語が多いから
仕方なくクロージャーを使うしかないが、
Java8のラムダの方がまだ安全なコードを書くことが出来る。
(ラムダも外のスコープが参照できる場合があるので完璧ではない)

つまり俺がいいたいのは、クロージャーを使うと苦労するのジャー。
3 :
2014/11/08(土) 13:42:47.14 ID:alIlcZLx
ディスクロージャ
4 :
2014/11/08(土) 14:33:50.79 ID:Wb7Sa5AG
>>1
関数型言語の操作的意味論において、クロージャとは:
  「ラムダ式と局所環境とを組合せた概念」
を指す
このクロージャを具象構文で表したものが一般的な「ラムダ式」であり、
クロージャを識別子に束縛したものが一般的な「関数宣言」である

Standard ML という関数型言語だと、
たとえばラムダ式は fn x => x + 1 であり、関数宣言は val succ = fn x => x + 1 である
ここで、関数宣言には fun succ x = x + 1 と簡潔に書ける構文糖を用いるのが一般的
だから、あらゆる関数型言語ないし関数型プログラミングが可能なあらゆる言語であれば、
クロージャ(という概念)は必要不可欠に存在である、と言える

また Java の「匿名クラス」もクロージャ(という概念)を応用した具象構文の一種である
で、Java 8 で導入された「ラムダ式」もクロージャの具象構文だけど、
匿名クラスよりも簡潔に書ける利点があるから、多くのケースで広く利用されるようになるだろう
両者の間には、局所環境と組み合わせる対象が「匿名クラス」ではクラスという単位であるのに対して、
「ラムダ式」では式という(クラスよりも粒の小さな)単位であるという違いがある
目的に応じて適切に両者を使い分けることが望ましい
5 :
2014/11/08(土) 16:17:08.12 ID:gNjtEENQ
  / ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄\
∠                     ノ
 丶                      |
  ノ                        |
  |      / ̄ ̄ ̄ ̄\       |
  |     /            ヽ      |
  |     |             |     |
  |     |             |     |
  |     |             |     |
 /      |           |     /
 ヽ      \_/| |\_/    ヽヘ
  |         / \         /
   ̄ ̄ ̄ ̄ ̄ ̄     ̄ ̄ ̄ ̄ ̄ ̄
       パンとか止めるやつ
6 :
デフォルトの名無しさん
2014/11/08(土) 16:19:08.12 ID:gwropNof
>>5
それ、パンとか止めるやつだろ!
7 :
2014/11/08(土) 16:28:06.78 ID:Z0nNiFel
                / ̄ ̄\
               / _ノ  ヽ、_ \
             . | ( ●)(● ) |
         ,-,-,-,__ |  (__人__)  │rヽヽヽヽ__   「クイックロック バッグ クロージャー!!」
        r.l .' ' .'.r_l |   `⌒ ´   . | ´l   .|/
        .ヽ|   |   |           |  |   /_
      ._,,-ーヽ   /-‐ ヽ        /‐''",'  /.  `ヽ
     /   /`''‐-',.   ヽ      ./ rj,.-‐''´`l    ./
     \  |  二ヽ           ヽ三  |ー‐'´
       `''‐ヽ  ―`ヘ            j `―r'´
          `T ´   j.           ./   j
           ヽ   .ヽ、 ___  /   ,'
            |    ./(>)^ ヽ\   i
            |  ./  (_  (<) \ .i  
          / .! ./   /rェヾ__)⌒:::  ヾ.\
          /  ∧i.   `⌒´-'´  u;   ノ   ヽ
            |    .\ヽ 、  ,    /    |
         .ヽ    ',.  ー  一   ./     /
          ',   .',        ./   /
           .',   ',       /   /
           /ヽ、  \    /   /
           /  |   ヽ―‐/    ./ \
          ./   .l    丿  ゝ   (   ヽ
         /   /  /    \   ',    ',
         /   /-‐''´       `''‐|    ',
       ./   __|            . /     .',
       |    `ヽ、        ./ ̄     .|
       |      ヽ       /       /
       `"''-,,__ ,,,,丿       ゝ、__,,-''
8 :
デフォルトの名無しさん
2014/11/08(土) 18:29:54.75 ID:+pW0VlFs
>>1
匿名クラスは嫌。

まぁ俺の用途では関数内関数で十分なことが多い。
なのでけっこう>>2には同意。
9 :
2014/11/08(土) 18:31:45.04 ID:Z0nNiFel
>>8
最後の行に同意してくれてありがとう
10 :
2014/11/08(土) 21:41:30.87 ID:1bx+kI6Q
おもてたんとちゃうこのスレ
11 :
2014/11/08(土) 22:16:16.20 ID:BzSpEdoH
クロージャーってただのメソッド一つのクラスだろ
12 :
2014/11/09(日) 01:25:23.88 ID:5LKfT6rZ
まじすか
13 :
2014/11/09(日) 02:04:06.76 ID:8LiWtrih
という見方、扱い方もできるねって話だろ
14 :
2014/11/09(日) 05:57:17.96 ID:n2NDOrh4
ActionListenerなんて、実装当時にクロージャがあったら存在してたかどうか怪しいクラスだよね
15 :
デフォルトの名無しさん
2014/11/09(日) 07:54:16.27 ID:6VpE/OBT
lispの方言かとおもった
16 :
2014/11/09(日) 09:19:55.73 ID:nlmXbEn2
>>2
関数型言語では、基本的に変数を書き換えるのは例外的な操作だから
不用意に変数を書き換えることは殆ど無いし、
それなら環境が見えてる事のメリットの方が大きい
17 :
2014/11/09(日) 10:23:47.55 ID:gYZvrVR/
>>11
複数にできるよ
18 :
2014/11/09(日) 16:16:30.86 ID:K4BO8Ja1
関数内で関数が定義できる事とクロージャと何の関係があるんだ?
比較できるものじゃないでしょ
19 :
2014/11/09(日) 16:48:40.28 ID:EbU/SVlS
まあ、クロージャは関数内関数の用途をも内包することは多いんじゃね?
20 :
2014/11/09(日) 17:24:14.45 ID:xhtawW2X
>>16
それはあまり使われていない関数型言語限定の話ですね。
21 :
2014/11/09(日) 17:32:09.95 ID:PiaxZAwM
>>1は関数型言語の話をしてるんじゃないのか。

> 関数型言語に必ずくっついてるこれ
22 :
2014/11/09(日) 17:38:41.70 ID:50xVLBic
オレオレ言語仕様を考えてるんだけどさ今どの言語を見てもlambdaだらけじゃない
RAII出来る言語だとクロージャに環境掴まれるだけでリソースリークしそうなわけよ
ならイランでしょ?というわけでたてた
23 :
2014/11/09(日) 18:18:41.40 ID:K4BO8Ja1
クロージャだからって外の環境全部掴む必要無いんじゃね
クロージャが使用してない変数については各スコープのタイミングで解放すれば十分じゃないの
24 :
2014/11/09(日) 18:20:47.86 ID:xhtawW2X
evalが使える言語では、使用していないかどうか
実行するまでわからないのでそれは無理。
25 :
2014/11/09(日) 18:24:28.78 ID:KOr7L+hP
>>20,21
関数型言語ではなく関数型プログラミングの話だと考えれば、
すでに多くの言語でクロージャという概念は幅広く普及していると言えるのではないかと
たとえば C#、Java8、C++11、JavaScript、Ruby 等々

もちろん Python のように、クロージャが存在しない手続き型言語も広く使われているけどね
また、C++ や Java でも古い規格だとクロージャは存在していなかった
26 :
2014/11/09(日) 18:40:07.36 ID:lx9et4kr
Pythonの関数は外の環境掴んでるからクロージャ
嘘は良くない
27 :
2014/11/09(日) 18:40:57.06 ID:nlmXbEn2
>>24
クロージャじゃなくてevalを禁止すれば良いんじゃね?
28 :
2014/11/09(日) 18:55:58.44 ID:KOr7L+hP
>>26
>>25 で挙げたクロージャを備えた言語は、どれも外の環境を掴んで
ローカル変数に代入できる(=局所環境内の識別子に束縛できる)

それに対して,Python のラムダ式では外の環境を掴めないからクロージャではない
つまり Python は、クロージャを持たない手続き型言語

(ラムダ式ではなく)関数で外の環境を掴めるのは当たり前の話であり、嘘は良くない
29 :
2014/11/09(日) 18:59:22.34 ID:KOr7L+hP
>>28 を訂正、ラムダ式(匿名関数)の話であるのを書き忘れていた

X:>25 で挙げたクロージャを備えた言語は、どれも外の環境を掴んで
O:>25 で挙げたクロージャを備えた言語は、どれもラムダ式の中で外の環境を掴んで
30 :
2014/11/09(日) 19:03:23.62 ID:lx9et4kr
>>28
ラムダ式では代入は出来ないけど外の環境は掴んでるからクロージャ
嘘は良くない
31 :
2014/11/09(日) 19:08:15.30 ID:nlmXbEn2
不毛だからケンカする前に用語を定義しろよ
オレオレ定義じゃないんだったら引用も必要

http://ja.wikipedia.org/wiki/%E3%82%AF%E3%83%AD%E3%83%BC%E3%82%B8%E3%83%A3

> クロージャ(クロージャー、英: closure)、関数閉包はプログラミング言語における関数オブジェクトの一種。
> いくつかの言語ではラムダ式や無名関数で実現している。引数以外の変数を実行時の環境ではなく、
> 自身が定義された環境(静的スコープ)において解決することを特徴とする。
32 :
2014/11/09(日) 19:13:25.68 ID:nlmXbEn2
> (ラムダ式ではなく)関数で外の環境を掴めるのは当たり前の話であり、嘘は良くない

とりあえずelispにケンカ売ってるのだけは分かった
33 :
2014/11/09(日) 19:19:20.49 ID:5LKfT6rZ
pythonのlambdaって外の環境見えないの?
34 :
2014/11/09(日) 19:22:02.17 ID:lx9et4kr
見えるよ
35 :
2014/11/09(日) 19:25:16.21 ID:5LKfT6rZ
そうだよね...
36 :
2014/11/09(日) 19:39:55.45 ID:KOr7L+hP
>>30
C#、Java8、C++11、JavaScript、Ruby 等々の関数型プログラミングが可能な言語では、
どれも「ラムダ式の中であっても外の環境を参照し、それを局所環境に保存」できる

それに対して、Python だと「ラムダ式の中では外の環境を参照する」ことしかできない
つまり、手続き型言語の Python は関数型プログラミングには不向きである、と言える


>>31
>> 引数以外の変数を実行時の環境ではなく、
>> 自身が定義された環境(静的スコープ)において解決することを特徴とする。

クロージャを備えた言語ではクロージャ自身が局所環境を持つということだね(>>4 も参照)
だから、関数内でもラムダ式内であっても局所環境で変数を解決できる

それに対して(クロージャを備えず、代わりに)関数という実行環境しか持たない Python では、
関数内では変数を解決できてもラムダ式内で変数を解決できない
つまり、Python はクロージャを持たない手続き型言語
37 :
2014/11/09(日) 19:44:13.19 ID:5LKfT6rZ
pythonのlambdaって単に単純な関数定義のシンタックスシュガーなんじゃないの?
lambdaなんて名前が付いてるからアレだけど。
38 :
2014/11/09(日) 19:44:17.88 ID:KOr7L+hP
>>33
もちろん見えるよ

ただしクロージャが無いから、その(ラムダ式の中から)見えた値を局所環境に保存できない
関数の中ならば(関数が持つ)局所環境に保存できるんだけどね....
39 :
2014/11/09(日) 19:47:57.23 ID:nlmXbEn2
>>36
・「変数を解決する」という用語が未定義
・「ラムダ式のみクロージャと認める」というのは>>31とは異なる定義だが、そのような定義をしている文献が引用されてない

やり直し
40 :
2014/11/09(日) 19:48:24.99 ID:5LKfT6rZ
>>38
ラムダ式を評価した結果も関数定義を評価した結果も同じfunctionだよ。
41 :
2014/11/09(日) 20:00:59.51 ID:lx9et4kr
>>40 たしかに

import inspect

def func(x):
return lambda n: x * n

func(5)(4) #=> 20 (Clojure)
inspect.isfunction(func) #=> True
inspect.isfunction(func(1)) #=> True
42 :
2014/11/09(日) 20:10:51.52 ID:KOr7L+hP
>>39
>・「変数を解決する」という用語が未定義

失礼、言語処理系や言語意味論を知らない人には難しい表現だった

「変数を解決する」とは、変数に束縛された値を求めることを意味する
単純な実装では、変数と値の対(ペア)の集合である環境から、変数をキーに値を探索することで実現できる

>・「ラムダ式のみクロージャと認める」というのは>>31とは異なる定義だが、そのような定義をしている文献が引用されてない

「ラムダ式のみクロージャと認める」とは言っていないよ
C#、Java8、C++11、JavaScript、Ruby 等々の一般的な言語では関数でもラムダ式でも局所環境を持てる
これは「クロージャ自身が局所環境を持つ(>>4)」というクロージャ定義からすれば、自然な結果である
それに対して、ラムダ式では局所環境を持てない Python にはクロージャの概念が欠落しているんじゃないのか?
と指摘しているだけ

あるいは処理系への実装を失敗した?、あるいは言語設計上の欠陥を見落とした?という指摘と言い換えてもいい
Python の言語設計者達はクロージャの概念を知っているつもりだったのかもしれないけどね......
43 :
2014/11/09(日) 20:14:38.63 ID:nlmXbEn2
>>42
お前こそ良く分かってなくて用語使ってるだろ
そういうのは変数の再束縛っていうんだよ
そんでお前は変数の再束縛と局所環境が持てない事を混同してる
44 :
2014/11/09(日) 20:19:48.73 ID:5LKfT6rZ
pythonでは関数=クロージャなんじゃないの?
ラムダ式は関数定義の略記方だよ。
45 :
2014/11/09(日) 20:27:21.21 ID:5LKfT6rZ
変数に束縛された値を求めることは評価するっていうんだと思う。
再束縛は別の値を束縛すること。
46 :
2014/11/09(日) 20:32:25.05 ID:lx9et4kr
Lispっぽくクロージャ書けるよ

f = (lambda x:
(lambda y=2*x:
(lambda z=x*y:
(lambda w: w * (y + z))))()())
g = f(2)
g(3) #=> 36
47 :
2014/11/09(日) 20:34:00.52 ID:KOr7L+hP
>>43
言葉を「変数の再束縛」へ言い換えただけでは、結論は同じだよ

C#、Java8、C++11、JavaScript、Ruby 等々の一般的な言語では関数やラムダ式はクロージャを元に
設計されているから、外の環境を参照した値を「局所変数に再束縛」できる
それが当たり前で、自然な関数型プログラミングができる

それに対して(クロージャを元にしていない)手続き型言語の Python では、
ラムダ式の中だと「局所変数に再束縛」できない
従って、手続き型言語の Python は関数型プログラミングには不向きである
48 :
2014/11/09(日) 20:34:54.87 ID:nlmXbEn2
>>45
評価はPythonのラムダの中でも出来るよな?
49 :
2014/11/09(日) 20:37:14.94 ID:nlmXbEn2
>>47
よし、あとはラムダの中で変数の再束縛ができないと
その言語にクロージャが無い事になるという文献を引っ張ってこい
50 :
2014/11/09(日) 20:40:33.21 ID:lx9et4kr
>>47
Pythonのラムダ式では局所変数に再束縛できない、は間違い(>>46)
嘘は良くない
51 :
2014/11/09(日) 20:49:43.56 ID:lx9et4kr
>>44
そうだよ
52 :
2014/11/09(日) 21:05:06.25 ID:KOr7L+hP
>>47
クロージャを備えた言語であれば、ラムダ式を入れ子にした複雑なコードを書かなくても、
単純明瞭で可読性の高いコードが書ける

f = function(x) {
  y = 2 * x;
  z = x * y;

  return function(w) { return w * (y + z) }
}
g = f(2);
print(g(3));


これがクロージャを備えた C#、Java8、C++11、JavaScript、Ruby 等々の普通の言語と
関数型プログラミングに不向きな手続き型言語 Python との違い
53 :
2014/11/09(日) 21:08:04.55 ID:lx9et4kr
ラムダ式の入れ子は分かりにくいから
関数型プログラミングに向いてない

関数型とは一体…
54 :
2014/11/09(日) 21:09:53.89 ID:5LKfT6rZ
そもそも関数型プログラミングって堂々と代入してるようじゃダメなのでは
55 :
2014/11/09(日) 21:12:20.49 ID:lx9et4kr
どれだけ間違いを指摘しても
Pythonにクロージャが無いって意見を上書きできない


これが参照透過性です
56 :
2014/11/09(日) 21:14:02.40 ID:KOr7L+hP
>>52 の続き)
もちろん関数型言語であれば、>>52 の JavaScript より更に簡潔になるのは当たり前の話
以下は Standard ML

val f = fn x => let
    val y = 2 * x
    val z = x * y
  in
    fn w => w * (y + z)
  end
val g = f 2

g 3
57 :
2014/11/09(日) 21:18:46.76 ID:KOr7L+hP
>>53
>ラムダ式の入れ子は分かりにくいから
>関数型プログラミングに向いてない

添削しよう:

 ラムダ式の入れ子は分かりにくいから、
 ラムダ式の入れ子や関数内関数を多用しなければならない手続き型言語の Python は
 関数型プログラミングに向いてない

それに対して、クロージャを備えた C#、Java8、C++11、JavaScript、Ruby 等々の普通の言語では、
クロージャ自身が持つ局所環境内の変数に代入(=束縛)できるから、
関数型プログラミングに向いている
58 :
2014/11/09(日) 21:25:01.25 ID:KOr7L+hP
>>50
Python ができるのは、引数に再束縛することだけ
局所変数(>>52,56 の y と z)には代入できない

Python でも「ラムダ式では局所変数に再束縛できる」と主張したいのなら、
ラムダ式の入れ子や関数内関数を使わずに、可読性の悪い >>47 のコードを書き直しなさい
もし Python に真のクロージャが存在するのなら、簡単な仕事のはずだ

できるよね? できないのなら、嘘つきは君のほうだよ
59 :
2014/11/09(日) 21:31:21.14 ID:lx9et4kr
変数に再束縛できないから、変数に代入できないに意見が変わったね
やっと>>30に追いついたね
60 :
2014/11/09(日) 21:36:16.07 ID:lx9et4kr
>>46の変数は外から見えないという意味で
紛れもなく局所変数
61 :
2014/11/09(日) 21:41:46.54 ID:LUEi6lWE
Java 8にクロージャなんかあったっけ?
ただのラムダだったような
62 :
2014/11/09(日) 21:44:14.34 ID:KOr7L+hP
>>59,60
ぐだぐだ屁理屈を言うより、さっさと >>47 のコードを書き直した方がいいんじゃね?

それとも Python コミュニティでは >>47 みたいな
  ラムダ式を入れ子にしたカッコだらけ
のコードが可読性のある美しいコードなのかなあ
自分には、>>52,56 のほうが可読性の高いコードだと思うけどね
63 :
2014/11/09(日) 21:45:18.38 ID:lx9et4kr
普通は関数定義するよ
当たり前じゃん
64 :
2014/11/09(日) 21:49:19.33 ID:lx9et4kr
ところで関数はクロージャじゃないって
どこの文化なの?
聞いたことない
65 :
2014/11/09(日) 21:50:58.85 ID:KOr7L+hP
>>61
>>4 で書いたように、クロージャは抽象的な概念だよ
言語の意味論を定義したり言語処理系を設計する時に用いられる抽象構文で現れる
この抽象構文上のクロージャは、具象構文では一般にラムダ式とか無名関数(匿名関数)と呼ばれる

たとえば Java 8 のラムダ式がそうだし、JavaScript の具象構文では function() { .... } と書き、
Standard ML では fn <id> => <expr> という具象構文で表現される
66 :
2014/11/09(日) 21:55:24.38 ID:lx9et4kr
言語的にはJavaのラムダは
ただのメソッド一つのクラスだよ
67 :
2014/11/09(日) 21:58:19.30 ID:KOr7L+hP
>>64
自分も聞いたことないね
そんなこと言ってるお馬鹿さんはいるのかな?

まあ正確に言うと、クロージャを識別子に束縛したものが関数だから、
束縛されていない無名関数(=ラムダ式)と区別することが必要な文脈もあるけどね(>>4)
68 :
2014/11/09(日) 22:04:34.10 ID:lx9et4kr
>>67
じゃあPythonにクロージャはあるの?
Yes/Noで答えて
69 :
2014/11/09(日) 22:05:03.57 ID:TZMLlS/6
Java 8のクロージャは「effectively finalに限りキャプチャ可能」
というなんちゃってな局所環境だけどな
effectively finalの導入でかろうじて使い物になるかも知れないレベル
70 :
2014/11/09(日) 22:10:31.90 ID:KOr7L+hP
>>63
普通は局所変数に代入するだろ、>>52 みたいに
  y = 2 * x
  z = x * y

それとも、Python ではこんな単純な代入文も書かずに(書けずに?)、
わざわざ関数定義するのが当たり前なのかなあ?
71 :
2014/11/09(日) 22:13:13.99 ID:n2NDOrh4
>>38
…Haskellにはクロージャが無いと?
72 :
2014/11/09(日) 22:21:17.10 ID:KOr7L+hP
>>68
Yes/No であれば No だ

繰り返しになるけど、
真のクロージャを備えた C#、Java8、C++11、JavaScript、Ruby 等々におけるクロージャの定義と、
手続き型言語の Python におけるクロージャの定義は異なっている
Python では識別子に束縛したクロージャ、いわゆる関数しか存在できず、
局所環境を伴うラムダ式を表現できない

このため、>>47 のような
  ラムダ式が入れ子になったカッコだらけ
の汚いコードしか書けない
結果として、Python は関数型プログラミングには不向きである
73 :
2014/11/09(日) 22:21:52.15 ID:lx9et4kr
>>70
だから普通はこう書くよ
あれ?一番簡潔になった?


def f(x):
y = 2 * x
z = x * y
return lambda w: w * (y + z)
g = f(2)
g(3)
74 :
2014/11/09(日) 22:25:17.72 ID:lx9et4kr
>>67
そっちが言う馬鹿(>>72)がいたよ



まさかの同一ID⁉︎
75 :
2014/11/09(日) 22:28:55.78 ID:GwhuA7Og
>クロージャを識別子に束縛したものが関数だから

C#やECMAScriptの匿名関数は関数ではないと。
珍妙な新説ですなふむふむ
76 :
2014/11/09(日) 22:31:31.78 ID:KOr7L+hP
>>71
>>38における「値を局所環境に保存」とは、識別子と値の対(ペア)を局所環境に追加すること(>>42 も参照)

ここで、追加の時に既に同じ名前の識別子が存在していた場合、手続き型言語では値を破壊的に更新するけど、
関数型言語では新たに局所環境が生成される(=破壊的に更新しない)点が異なる
ただし、この追加時の振る舞いの差異は、クロージャが存在する/しないとは無関係、ごっちゃにするのは間違い
77 :
2014/11/09(日) 22:45:45.31 ID:KOr7L+hP
>>73
たとえば JavaScript なら、ラムダ式だけ(>>52)と関数定義との併用、
それらのどちらでも簡潔なコードが書けるよ

function f(x) {
  y = 2 * x
  z = x * y
  return function(w) { return w * (y + z) }
}
g = f(2)
g(3)


結局、Python では「ラムダ式を放棄して」関数定義しなければ簡潔なコードを書けない、
ということが実証されてしまったようだね

つまり、真のクロージャを備えた C#、Java8、C++11、JavaScript、Ruby 等々のふつうの言語では、
ラムダ式だけでも関数定義との併用でも、ケースバイケースで選択して簡潔で可読性のあるコードを「書ける」けど、
手続き型言語の Python だとラムダ式だけでは「入れ子になったカッコだらけ」の汚いコード(>>47)しか書けないから、
常に関数定義で「書かなければならない」という違いがある
78 :
2014/11/09(日) 22:46:49.16 ID:nlmXbEn2
>>76
お前のオレオレ定義なんて興味ねーんだよ
まずはその珍説が書いてある文献を引用しろ
79 :
2014/11/09(日) 22:49:23.73 ID:5LKfT6rZ
80 :
2014/11/09(日) 22:51:44.34 ID:lx9et4kr
>>77
関数定義で可読性も簡潔さも失わないから、関数で書ければ良いよ

で、なぜ関数定義でクロージャが作れる
Pythonにクロージャがない事になるの?
>>68にNoと答えて、>>64も否定したよね?
81 :
2014/11/09(日) 22:54:09.40 ID:nlmXbEn2
>>79
そいつ、関数を定義する特定のシンタックスシュガーに制限があることと
その言語自体が持つ機能との区別が付かない馬鹿だから
82 :
2014/11/09(日) 22:56:01.93 ID:5LKfT6rZ
でもまあ、pythonの文法が変態なのは間違いない。
83 :
2014/11/09(日) 22:56:21.23 ID:KOr7L+hP
>>73
ナゼ Python では、以下のような簡潔なコードが構文エラーになるんだろうね?

f = lambda x:
  y = 2 * x
  z = x * y
  return lambda w: w * (y + z)
g = f(2)
g(3)

これじゃあ「Python は関数型プログラミングに向かない」と評価されてもしかたないよね
だって、真のクロージャを備えた C#、Java8、C++11、JavaScript、Ruby 等々のふつうの言語では、
>>52 みたいなラムダ式だけを使ったコードが何の苦もなく自然に書けるんだから
84 :
2014/11/09(日) 22:59:47.88 ID:QKkGL4h0
83はキチガイなの?
>>73は明らかに実行時のy,zを取り込んだ関数オブジェクトを生成してるからクロージャだろ
defと書くかlambdaと書くか文法の些細な決まり事などどうでもいい
85 :
2014/11/09(日) 23:01:05.93 ID:lx9et4kr
>>83
同程度に簡潔に書けるなら、書き方は一つの方が良い
というのがPythonの理想だから
86 :
2014/11/09(日) 23:08:28.24 ID:KOr7L+hP
>>80
>で、なぜ関数定義でクロージャが作れる
>Pythonにクロージャがない事になるの?

>>72 で書いたように、真のクロージャを備えた C#、Java8、C++11、JavaScript、Ruby 等々の
ふつうの言語では(関数定義だけではなく)ラムダ式でもクロージャが作られるという違いがあるからだ
対して、Python のラムダ式ではクロージャが作られない(だから、局所変数へ値を代入できない)

もし「Pythonにクロージャがない」という主張が不適切であるのならば、
>>42 の最後で書いたように、
 「Python の言語設計者達は、処理系への実装を失敗した、あるいは言語設計上の欠陥を見落とした」
と言い換えてもいいよ

こんな使い物にならないラムダ式で満足しなければならないとは、最大の被害者は Python プログラマだよね
だって、他のふつうの言語であれば「ふつうに書ける」ことが、Python じゃ「書けない」のだから....(>>83)
87 :
2014/11/09(日) 23:13:26.40 ID:5LKfT6rZ
ラムダ式の構文が残念だと言いたいなら、最初からそう言えばいいじゃん。
88 :
2014/11/09(日) 23:16:00.89 ID:KOr7L+hP
>>84
ラムダ式が引数に値を束縛できるのは、関数型言語を知っていれば常識だよ
そんなことも知らないの?

で、引数以外の局所変数に値を束縛するには、純粋なラムダ式に加えてクロージャが必要になるって話だよ
89 :
2014/11/09(日) 23:18:21.66 ID:G8K4RNhm
>ラムダ式が引数に値を束縛できるのは

それ束縛じゃねーだろ
キミはアホなのか?
90 :
2014/11/09(日) 23:18:59.88 ID:nlmXbEn2
>>88
>>73のy, zのどこが引数なんだよ
既知外は黙ってろよ
91 :
2014/11/09(日) 23:23:03.86 ID:lx9et4kr
>>46の話ならデフォルト引数で値を入れてるから
普通に関数適用で引数に値を入れてるのとは厳密には違うよ?
どうでも良いけどね
92 :
2014/11/09(日) 23:26:01.65 ID:lx9et4kr
>>86
Pythonにクロージャが無いは嘘ってことね
嘘は良くない
93 :
2014/11/09(日) 23:27:54.79 ID:KOr7L+hP
>>90
>>88で書いたのは >>41 のラムダ式だけで書かれた Python コードだ
失礼した

>>73 は関数定義でクロージャが作られているね
ただし、Python だけがラムダ式ではクロージャが作られず、
Python におけるクロージャの定義が他の「普通の言語」と異なっている事実に変わりはない
94 :
2014/11/09(日) 23:30:45.91 ID:nlmXbEn2
>>93
お前は無名関数って何がいいの?スレを立てて、そこで思う存分Pythonのlambdaを罵倒するべき
クロージャ云々は言いたい事と噛み合ってない
95 :
2014/11/09(日) 23:33:02.09 ID:KOr7L+hP
>>92
Python には真のクロージャが存在しない、という指摘は事実だよ(嘘ではない)

もし「Python にも真のクロージャが存在する」と主張したいのなら、
>>83 のコードが構文エラーとならないように添削しなさい
もし「Python にも真のクロージャが存在する」のなら、たやすい作業のはずだ
真のクロージャを備えた普通の言語では、何の苦も無く >>52 みたいなコードが書けるんだからね

君が嘘つきでなければ、書けるはず
96 :
2014/11/09(日) 23:33:22.37 ID:5KptUVSU
使い勝手で一番使い物にならないのはJavaだろ?
void m() {
 int y = f();
 y = y + 1;
 new Thread(
  () -> {ここでyを使えないKUSO言語}
 );
}
97 :
2014/11/09(日) 23:33:25.09 ID:5LKfT6rZ
ID:KOr7L+hP が言ってるのは、

関数の引数にもう少し複雑な処理をインラインで書きたいのに、
defは値返さねえし、lambdaは1行しか書けねえし、
まったく融通がきかねえな!

みたいな字面上の不満であって、関数型プログラミングだのクロージャだの全然関係ない。
98 :
2014/11/09(日) 23:36:58.94 ID:lx9et4kr
>>95
関数は局所環境持ってても「真のクロージャ」じゃないってこと?
Yes/Noで答えて
99 :
2014/11/09(日) 23:39:26.26 ID:nlmXbEn2
真のクロージャとかいうオレオレ用語
もちろん引用もなければ定義もない
100 :
2014/11/09(日) 23:40:53.08 ID:KOr7L+hP
>>94
クロージャという概念を正しく理解していないと、
Python みたいなラムダ式に欠陥のある言語が設計されてしまうというお話だよ
言い換えると、クロージャという概念を用いると、
なぜ Python のラムダ式が欠陥品なのかを明解に説明できる

このクロージャの利点は、このスレの主旨からは逸脱していないと思うよ
101 :
2014/11/09(日) 23:42:02.22 ID:nlmXbEn2
>>100
お前がこのスレで一番クロージャを理解してない件
構文の字面しか見てないし
102 :
2014/11/09(日) 23:57:43.62 ID:KOr7L+hP
>>98
No だね

あえていえば「クロージャもどき」とか「なんちゃってクロージャ」だね
真のクロージャであれば無名関数でも間数定義でも作られ、
無名関数であってもクロージャを構成する局所環境を持つことができる
これが、 C#、Java8、C++11、JavaScript、Ruby 等々の
「ふつうの言語」における「ふつうのクロージャ」だ

おそらくクロージャを正しく理解していなかったんだろね、Python 言語設計者達は....
103 :
2014/11/09(日) 23:59:39.38 ID:yjLcynWs
話をまとめよう

世間一般のクロージャの要件:
 局所環境を持つ(変数を束縛できる)
 関数をインラインで書ける

キチガイのクロージャの要件:
 クソージャの中にクソージャが書ける
 若しくは
 言語設計上の欠陥を見落としたことを認める(>>86の発言)
 のいずれか
104 :
2014/11/10(月) 00:08:24.74 ID:LMH7nFF4
>>103
添削してあげよう


--
話をまとめよう

世間一般のクロージャの要件(C#、Java8、C++11、JavaScript、Ruby 等々):
 関数であっても無名関数であっても、局所環境を持つ(変数を束縛できる):>>52,56,77

Python に固有なクロージャの要件:
 関数だけが局所環境を持つ(変数を束縛できる):>>73
 無名関数では局所環境を持てない(変数を束縛できない):>>46,83
105 :
2014/11/10(月) 00:14:31.96 ID:cCGgoLPL
まあここはscheme最強っていう事にしておきますか。
106 :
2014/11/10(月) 00:28:52.73 ID:LMH7nFF4
>>101
> 構文の字面しか見てないし

だとすれば、Martin Fowler氏も「構文の字面しか見てない」ってもとになるんだろな

・Martin Fowler's Bliki in Japanese - クロージャ
 http://capsctrl.que.jp/kdmsnr/wiki/bliki/?Closure

Lsip/Smalltalk/Ruby/JavaScript といったプログラミング言語では、
クロージャやブロックを多用したスタイルが好まれる
だから、Python みたいな無名関数で局所環境を持てない言語で同じようにクロージャを
多用するスタイルを試みると、「ラムダ式が入れ子でカッコだらけ(>>46)」な汚いコードや、
いちいち「関数定義しなければならない(>>73)」ケースと頻繁に出会うから、ストレスが溜まる
まあ「Python は手続き型言語」だから仕方ないんだよと自分に言い聞かせて我慢してるけど、
プログラミング言語を自由に選べるなら、真っ先に Python は除外するね、自分なら

もし、これが「構文の字面しか見てない」と思えるのなら、それはそれでもいいんじゃないのかもね.....
107 :
2014/11/10(月) 00:37:52.21 ID:cCGgoLPL
Pythonはlambdaの不便さも含めて構文がアレなので大嫌いだけど、
ライブラリが色々そろってて便利だから結局よく使っているのであった。
108 :
2014/11/10(月) 00:42:53.31 ID:zIX5GD/A
pythonのlambdaってmapやfilterを追加したときに申し訳程度に付けたって感じ
109 :
2014/11/10(月) 02:52:22.03 ID:qQmxJFhq
>>106
その文章を書いた人の考えと、君の解釈には随分とズレがあるようだ
110 :
2014/11/10(月) 06:04:53.17 ID:i3Y7RgoA
馬鹿には無理
111 :
2014/11/10(月) 07:14:42.95 ID:0mRy26rG
Pythonの不自由さ(関数型のクロージャに近いの)はGuidoの方針じゃないの?
嫌なら、おとなしくジェネレータ使えばいいじゃん。
112 :
2014/11/10(月) 08:48:39.72 ID:PWSP4TjP
クロージャは何がいいんだよ!
https://i.imgur.com/fTQTEYN.gif
113 :
2014/11/10(月) 09:04:03.39 ID:HTkQymog
引数に別名付けたくなる程に中身が長いなら
関数にも名前付けろってのがGuidoの方針なんだろ
文法的に拡張可能なのに、あえてリジェクトしてるくらいだし
http://www.artima.com/weblogs/viewpost.jsp?thread=147358
114 :
2014/11/10(月) 10:20:30.55 ID:CeTPRNSr
>>106
Martin Fowlerは字面だけを見てないから、ちゃんとPythonにもクロージャがあると思ってるよ

お前が張ったリンク先の「他の言語」を見てみろ
115 :
2014/11/10(月) 11:39:28.98 ID:rdbd3Lyi
何がクロージャかよりどこが好きかでクロージャを語れよ!!(ドンッ
116 :
2014/11/10(月) 20:33:09.35 ID:AR7BQCkT
クロージャとメソッドで f[x] と f(x) を使い分けなきゃダメなRubyが
一番ウンコだと思う
117 :
2014/11/10(月) 20:39:42.07 ID:5eyjbk6/
>>116
それはクロージャとメソッドではなく、Procとメソッドだと思う
Rubyのクロージャはブロックのほうの機能と考えたほうが良いんじゃないかな
118 :
デフォルトの名無しさん
2014/11/10(月) 21:34:09.37 ID:Xzn5T3EF
>>115

俺の財宝か?欲しけりゃくれてやる。
探せ!この世の全てをそこに置いてきた。
119 :
2014/11/10(月) 22:47:25.14 ID:oQ75X8QG
文系出身プログラマ「クロージャ?なにそれ?服入れるとこ??」
ってやつに対してドヤ顔ができる
120 :
2014/11/11(火) 06:32:45.68 ID:G8l0apNf
クロー系の最強魔法です 消費MP60
121 :
2014/11/11(火) 21:00:28.44 ID:UknPa1bY
レスお願いします
122 :
2014/11/11(火) 22:06:02.40 ID:3gT2I0NB
若い時に買ってでもすることは?

苦労じゃ!くろうじゃ!クロージャ!
123 :
2014/11/12(水) 01:25:01.41 ID:G1/eYMX4
クロージャの良さを、クロージャを使うことで劇的に
簡潔になる例を使って説明してください
124 :
2014/11/12(水) 07:27:28.43 ID:ptlTHlgg
コールバック関数を別途書かなくて良くなります。
もしコールバック関数の為だけにインスタンス変数を定義していたなら、
それも必要が無くなります。

消費MP 5
125 :
2014/11/12(水) 08:10:30.04 ID:G1/eYMX4
コールバック関数地獄のJSのコードは
可読性が悪い上に簡潔でも無いので、失格です
126 :
2014/11/12(水) 08:13:15.39 ID:/hly7+iy
オールバックって額からハゲるだろ?
127 :
2014/11/12(水) 08:27:11.27 ID:cKuXIrT/
>>125
そんなあなたにClojureScript。
core.asyncのチャネルでスッキリしますよ(Go由来のようだけど)
128 :
2014/11/12(水) 20:27:05.24 ID:3VJGATlA
>>127
コールバック自体がダメなんだよ。
例えば、addEventLisnerの引数にコールバックを指定する。
これだけでも可読性悪いだろ。
129 :
2014/11/12(水) 20:37:53.49 ID:L8labB6g
見慣れてるかどうかだと思うけどな
130 :
2014/11/12(水) 20:38:24.71 ID:5GyhUZuz
>>128
代案も出さずに批判だけするなら、幼稚園児にだってできるよ
131 :
2014/11/12(水) 20:52:00.80 ID:UPi6O5bX
リスナーI/Fをインプリメントしたオブジェクト渡せばいいのでは
132 :
2014/11/12(水) 21:14:25.68 ID:ptlTHlgg
それではそのオブジェクトを定義しなくてはならなくなります。
クロージャはそのようなデリゲートオブジェクトやコールバックパターンからの解放なのです。

消費MP 12
133 :
2014/11/12(水) 21:16:45.87 ID:eep146vT
JavaScript(だけに限らないが)
クロージャーが見難いんじゃなくて
非同期の入れ子が見にくいんだろ。
で、それを解決するライブラリが存在する。

結局のところ、そのライブラリ
Promiseとかを使えば解決する問題。
134 :
2014/11/12(水) 21:23:36.45 ID:G1/eYMX4
結局のところ、コールバックはクロージャのメリットじゃないんですね?
もっと良い方法があるのですから
135 :
2014/11/12(水) 21:36:55.56 ID:ptlTHlgg
いや、クロージャ使ってそのスコープで解決しちゃえばコールバック関数要らないって話なんだが。
136 :
2014/11/12(水) 21:59:20.14 ID:G1/eYMX4
Haskellのdo記法みたいなのがあれば
クロージャをチェインしていっても読み難くならないという話ですか?
137 :
2014/11/12(水) 22:58:17.02 ID:L8labB6g
小規模なコールバックだったらインラインで書いた方が見通しが良いだろうし、
複雑なのだったら分けて書いた方が理解しやすいだろうし、
あれが最強他はゴミとか言ってるのが一番ダメなんじゃね?
138 :
2014/11/15(土) 12:17:49.98 ID:uUcubJGq
結局クロージャの利点てコールバックが楽にかけるってだけ?
ならクロージャや匿名オブジェクトじゃなくて匿名メソッドが書ければ充分だな
139 :
2014/11/15(土) 12:25:31.04 ID:u4ZMuG60
楽に書けるって事じゃなくて、そのスコープで完結できるって事じゃね?
140 :
2014/11/15(土) 12:56:58.32 ID:XlhMXrhL
とりあえずコードで語れば?
大規模開発でメリットが出てくるとかの話じゃないんだし
141 :
2014/11/15(土) 14:40:16.71 ID:EFct/v5k
見た目的にも変数の値の可視性的にもそこのスコープってとこが楽だよね
142 :
2014/11/15(土) 14:43:26.00 ID:XlhMXrhL
つまりインラインでクラス定義できるのでも良いわけだよね
143 :
2014/11/15(土) 15:14:55.72 ID:EFct/v5k
>>142
本来そうだけど 、
シンタックスはインラインだけど実際はただの内部クラスで、
生成時の環境を一切利用できない言語もあるから何とも言えない。

クロージャの代わりにクラスを用いると何となくそういう実装になる。
ローカル環境の代わりにインスタンス変数を用いる方向にいくから。


FILE *fp = fopen(..);
doHoge( ^(const char*msg){ fputs(msg,fp); });
fclose(fp);

みたいに簡便にクロージャ生成時の外部の変数(の値のコピー)を
保持し使用できるクロージャとは方向性が違う。

ローカルメソッドに至っては環境が一昨渡せない
シングルスレッド前提ならグローバル変数を使えばいいわけだけど
144 :
2014/11/15(土) 15:54:48.49 ID:uUcubJGq
(擬似言語)
fw = new FileWriter();
doHoge( fw.witer );
fw.close();
こんなのをワンラインで書ければ満足なんだろ?匿名メソッドで十分じゃない
145 :
2014/11/15(土) 15:58:46.71 ID:EFct/v5k
>>144
じゃ匿名メソッドで書いてごらんよ
146 :
2014/11/15(土) 23:46:47.75 ID:JsFAZjCZ
with (fw, new FileWriter()) {
doHoge(fw.witer);
}
こうやって書けるほうがいい
147 :
2014/11/16(日) 10:37:06.14 ID:ZMiOBdAw
じゃあこれは?

FILE *fp = fopen(..);
doHoge( ^(const char*msg){ fprintf(fp, "Hoge: %s\n", msg); });
fclose(fp);
148 :
2014/11/16(日) 11:54:54.13 ID:fx2XWh+X
>>146
もはや匿名メソッドすら要らない派が出てくるしww
149 :
2014/11/18(火) 16:33:41.48 ID:cuxiU0eb
Java8すら使わせてもらえない人が必死なスレにしか見えなくなってきた
150 :
2014/11/19(水) 22:27:12.37 ID:eeZRz+g3
>>144,147
それだと doHoge の実行中に例外が発生するとファイルがクローズされない

たとえばクロージャを多用する Ruby のような言語だと、以下のように書く
 File.open(..) do |file|
   doHoge do
     file.puts(msg)
   end
 end
Ruby ではクロージャをブロックと呼ぶけど、ブロック実行中に例外が発生しても
ファイルは確実にクローズされるし、ユーザ定義メソッドでも同様な振る舞いを実装できる


>>146
それに対して、クロージャを持たない手続き型言語の Pascal や Python といった言語では、
同じ事をするのに(>>146 のような) with 構文を使わなければ書けない
クロージャは一級市民だから引数で渡したり呼び出すことができるという自由があるけど、
with 構文はあくまで文(statement)だからクロージャと比較すれば表現力は制限される
いわばクロージャという概念を持たない言語の代用品が with 構文である

なおJavaScript はクロージャと with 構文のどちらも持っているけど、
書籍 "JavaScript: Good Parts" だとクロージャは Good Parts に
with 構文は Bad Parts に分類されている
151 :
2014/11/19(水) 23:00:05.80 ID:074lLX1H
クロージャばりばり使うlisp方言でもwith構文は使うよ
152 :
2014/11/19(水) 23:12:18.42 ID:3WdraWBV
クロージャとクリーンアップ処理とは別の話じゃないの?
153 :
2014/11/19(水) 23:33:41.68 ID:PA9iCB5s
Pythonが憎すぎて既知外になった人の相手をしちゃいけません
154 :
2014/11/19(水) 23:39:01.13 ID:QzanlTyB
>>150
> なおJavaScript はクロージャと with 構文のどちらも持っているけど、
> 書籍 "JavaScript: Good Parts" だとクロージャは Good Parts に
> with 構文は Bad Parts に分類されている

お前バカじゃね? 大馬鹿じゃね?

ここで言ってるwithは例外が起きた時にリソースを解放する機能を持ったもの。
JavaScriptのwithはそんな機能は持っておらず、

obj.foo() を
with(obj) {
  foo()
}
と書けるようにするためでしかなく、それによる問題(詳しくは調べて)があるから
Bad Partsになってるだけ。
PascalやPythonのwithがBad Partsになってるわけじゃない

お前、ほんと、馬鹿だよね?
155 :
2014/11/19(水) 23:57:41.67 ID:eeZRz+g3
クロージャと with 構文のどちらも持っている言語であれば、
ケースバイケースで可読性や好みで使い分ければいいのではないかと

問題はクロージャを持たない、あるいは
「世間一般のクロージャの要件(>>104)」を満たせない言語では、
with 構文という(クロージャと比べて)不自由な代用品を使わざるをえない
という話
156 :
2014/11/20(木) 00:02:30.91 ID:fhZ8V3Hu
>>150>>155
下の(a)と(b)が等価であるようなJSのwith構文と
リソース解放のwith構文の区別もつかないような馬鹿が
何書いても説得力無いよ


// (a)
with (obj) {
    a = b;
}

// (b)
if (obj.a === undefined) {
    a = obj.b === undefined ? b : obj.b;
} else {
    obj.a = obj.b === undefined ? b : obj.b;
}


withって字面だけ見て同じだと思っちゃったの?
そんなだから構文の字面しか見てない馬鹿って言われちゃうんだよ
157 :
2014/11/20(木) 00:19:03.39 ID:wJ3BgpRF
>>154
>ここで言ってるwithは例外が起きた時にリソースを解放する機能を持ったもの。

わざわざ with という構文を追加して言語の意味論を複雑にしなくても、
もし汎用的な概念であるクロージャがあれば、同じ事を実現できるってことだよ

もし Python にもクロージャがあるなら、他の言語達と同様に
with 構文を使わなくてもリソースの自動解放を簡潔に表現できるハズだけど、
手続き型言語の Python では無理だろうね

それとも、書けるかな?
158 :
2014/11/20(木) 00:20:15.54 ID:7GcQ+ika
pythonでも引数にクロージャ受け取ってwithの中でそれを実行する関数つくれば、rubyのそれと等価じゃね?
pythonはlambdaが制限きついから複雑な処理はインラインには書けないけど。
159 :
2014/11/20(木) 00:29:37.23 ID:wJ3BgpRF
>>158
>それを実行する関数つくれば、

もし Python が「世間一般のクロージャの要件(>>104)」を満たしていれば、
「関数をつくらなくても」クロージャだけで簡潔に書けるはず
つまり「関数をつくらなければ書けない」ということは、
Python が「世間一般のクロージャの要件」を満たしていないことを認めたってこと
160 :
2014/11/20(木) 00:36:40.77 ID:ri7Qzvfi
「世間一般のクロージャの要件」が
全然世間一般の定義じゃない件
161 :
2014/11/20(木) 00:37:00.07 ID:7GcQ+ika
>>159
def make_f(x):
 def f(y):
  return x * y
 return f

例えばこんなのがあったとして、このmake_f()が返すものは何?
162 :
2014/11/20(木) 00:42:39.12 ID:wJ3BgpRF
>>161
「クロージャみたいなモノ」もしくは「クロージャもどき」

def make_f(x):
 return lambda(y): x * y

が返すのも同じ
163 :
2014/11/20(木) 00:44:55.24 ID:7GcQ+ika
>>162
「クロージャみたいなモノ」もしくは「クロージャもどき」と、クロージャの違いは何?
164 :
2014/11/20(木) 00:45:40.70 ID:ri7Qzvfi
>>162
>>31の定義だと完璧にクロージャの条件を満たしてるけど?

君はどこのローカルルールの話をしてるの?
165 :
2014/11/20(木) 00:47:27.27 ID:wJ3BgpRF
166 :
2014/11/20(木) 00:52:13.60 ID:7GcQ+ika
>>165
>世間一般のクロージャの要件(C#、Java8、C++11、JavaScript、Ruby 等々):
>  関数であっても無名関数であっても、局所環境を持つ(変数を束縛できる):>>52,56,77

>>161のmake_f()が返すものは局所環境をもってるし名前も付いてないよ。
167 :
2014/11/20(木) 00:58:03.79 ID:wJ3BgpRF
>>164
いや、Python は関数を定義しなければ局所環境が作られないんだから、
>>31 の要件は満たしていないだろ
>>31 には「ラムダ式や無名関数で実現している」と書かれているんだけど、
日本語が不自由なんですか?

実際、もしも >>31 の定義を満たしているなら、
>>46 のゴチャゴチャしたコードは
(>>73 のようにわざわざ関数を定義しなくても)
>>83 のように「ラムダ式や無名関数で実現している」
簡潔なコードに書き直せるはずだ

さて、論よりコード、>>164 は書き直せるかな?
168 :
2014/11/20(木) 01:00:19.64 ID:fhZ8V3Hu
今の議論と全然関係ないんだけど、久しぶりにTIOBEを見たら
ちょっと前までPerl, Python, Ruby, PHPで順位を争ってたのに
いつの間にかRubyだけ人気無くなっててワロタw

http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html


だからRuby信者発狂しちゃったの?


1 C
2 Java
3 Objective-C
4 C++
5 C#
6 PHP
7 Python
8 JavaScript
9 Perl
10 Visual Basic .NET
11 Visual Basic
12 R
13 Transact-SQL
14 Ruby
15 Delphi/Object Pascal
16 F#
17 PL/SQL
18 Swift
19 Pascal
20 Dart
169 :
2014/11/20(木) 01:03:38.95 ID:ri7Qzvfi
>>167
>>31には「いくつかの言語では」と前置きされてるじゃん
つまりラムダ式や無名関数は必要条件ではない

そっちこそ日本語が不自由すぎるのでは?
170 :
2014/11/20(木) 01:04:53.19 ID:wJ3BgpRF
>>166
それは def f(x): で関数を定義しているから、当たり前の話

「世間一般のクロージャ」であれば、わざわざ関数を定義しなくても
ラムダ式や無名関数と呼ばれる構文でクロージャを作れるんだよ
>>31 をよく読み直そうね
171 :
2014/11/20(木) 01:06:05.89 ID:7GcQ+ika
>>170
じゃあさ、これが返すものは何?
(define (make_f x)
 (define (f y)
  (* x y))
  f)
172 :
2014/11/20(木) 01:07:50.18 ID:fhZ8V3Hu
>>170
> >>31 をよく読み直そうね

お前が100回読み直した方が良いぜw
173 :
2014/11/20(木) 01:10:58.55 ID:wJ3BgpRF
>>169
>>31 にある「いくつかの言語では」という前置きは、
後から出てくる Smalltalk や Ruby のブロック構文を指すと
考えるのが自然じゃないかな?

さすがに Wikipedia のページ著者が
「ラムダ式や無名関数」と「関数定義」との違いも
分からないほどのお馬鹿さんだとは思えないしね
174 :
2014/11/20(木) 01:11:10.32 ID:7GcQ+ika
>>171
ごめん。それで (make_f 10) とか実行した時に返ってくるもの、の間違い。
175 :
2014/11/20(木) 01:15:12.19 ID:wJ3BgpRF
>>171
クロージャだね

(define (make_f x)
 (lambda (x) (* x y))
)

が返すのもクロージャだね
176 :
2014/11/20(木) 01:18:52.68 ID:7GcQ+ika
>>175
>>161のpythonのコードと完全に同じなんだけどw
177 :
2014/11/20(木) 01:18:56.43 ID:fhZ8V3Hu
>>173
> さすがに Wikipedia のページ著者が

Wikipediaの編集者を持ち上げるのは良いけど、
お前の主張とは違う事が書いてあるぜ
読めるか?Pythonって書いてある

> クロージャを持つ言語に、C# 3.0、C++11、ECMAScript(JavaScriptを含む)、Groovy、Java 8(予定)、
> Perl、Python、Ruby、PHP(5.3以降)、Lua、Squirrelなどがある。
178 :
2014/11/20(木) 01:28:21.39 ID:wJ3BgpRF
>>177
Wikipedia の記事が常に 100% 正しいと思っているのかな?

記事の冒頭にある >>31 のクロージャという用語の定義とは
矛盾していると思うけどね
(自分のクロージャという用語の定義は >>4 で書いた)

もし矛盾していないと反論したいのなら、論よりコードだ
>>46 のゴチャゴチャしたコードは
(>>73 のようにわざわざ関数を定義しなくても)
>>83 のようにラムダ式や無名関数だけで書き直せるはず

さて、>>177 は書き直せるかな?
179 :
2014/11/20(木) 01:32:42.88 ID:fhZ8V3Hu
>>178
>>169が正解と考えれば全く矛盾してないので、お前が間違ってるんだよ
180 :
2014/11/20(木) 09:44:37.50 ID:BfhGUngW
with構文はスコープから抜ける時にclose的な関数を必ず呼び出してくれる保証があるけど、
Rubyのブロックにはそんな保証は無い
だからRubyではウッカリcloseを忘れても分かりにくい
そういうのは良くない
181 :
2014/11/20(木) 11:08:08.37 ID:nwROesTX
>>178
> Wikipedia の記事が常に 100% 正しいと思っているのかな?

思ってないけど、あんたが言っていることよりかは
正しいと思うね。

だって、あんたの言うことのほうが正しいなら
wikipediaを修正すればいいわけだから。
182 :
2014/11/20(木) 12:57:07.44 ID:5gFBGGbj
なんだ、この偏執狂たちの罵り合いはw

そんなことより、問題。
若い内に買ってでもしろ、と言われるものはなぁんだ?
183 :
2014/11/20(木) 15:15:51.24 ID:W3M4RtQD
ああ、let-inが無いからpythonのはクロージャじゃないって主張か。
斜め上だな。
184 :
2014/11/20(木) 16:40:50.21 ID:2szoNUEC
環境と変数を手軽に包めるのは有難いけどなあ
XMLベースのジョブ管理言語とか
ちょっとしたVM作るときに
継続の表現にクロージャなしだとだるいよ
さらに無名クラスも無い言語だと
本物のVM作らなきゃいけなくなる
185 :
2014/11/20(木) 20:12:20.93 ID:IqIimPum
186 :
2014/11/21(金) 13:07:27.23 ID:obtZMam2
>>182
セックス…かな
年とると立たなくなるから
187 :
2014/11/21(金) 13:13:28.47 ID:zygDXSz1
>>186
ご愁傷さまです。
188 :
2014/11/29(土) 13:01:53.24 ID:OX49RFg5
>>188
189 :
2014/12/10(水) 19:56:15.27 ID:veDvxwge
Swift スレでクロージャの話題で荒れそうだったので、こちらへ移動しとく
 http://peace.2ch.net/test/read.cgi/tech/1415860741/153

--
Swift や Ruby を含む多くの言語では常識であるけど Python では異なるものとして、
関数型言語に由来した(無名関数やラムダ式とも呼ばれる)クロージャがある
たとえば "The Swift Programming Language" の "Closure" の章にある map メソッドを使った
サンプルコードは、Ruby でも同じスタイルの良く似たコードで書き直せる:
 http://ideone.com/TsGD6B
これは Ruby だけでなく、JavaScript でも同じ
Swift や Ruby と比べて構文が簡潔な JavaScript ではいくらか冗長にはなるけれど、
何の苦もなく Swift と同じスタイルで書き直せる:
 http://ideone.com/74oNVU

同様に、「あるテーブルから特定の行だけを抽出し、加工して、集計する処理」は、
Swift だと table.filter { .... }.map { .... }.reduce { .... } とメソッドを連結(チェイン)させた式で書ける
これは Ruby なら table.select { .... }.map { .... }.inject { .... } と書き直せる
ここで、クロージャ内の ..... の部分には、上記のサンプルのように「任意の文(statements)が書ける」

もしかすると、いやこんなの高階関数のプログラミングを知っている人なら当たり前だろ、と感じるかもしれない
ところが Python だけはクロージャの本体に(任意の文ではなく)「式(expression)しか書けない」:
 http://ideone.com/tDaDkL  # --> Syntax Error になってしまう
だから、他の言語のクロージャに相当するコードを(名前のある)関数としてわざわざ宣言しなければならない:
 http://ideone.com/R7twCQ

結果として、Python は手続き型プログラミングであれば簡潔で可読性に優れたコードが書けるスクリプト言語だけれど、
関数型プログラミングには適さず、こうした関数型プログラミングは推奨されていないらしい(これを "酸っぱい葡萄" と言ふ)
 http://peace.2ch.net/test/read.cgi/tech/1345123070/70-71

これが Swift や Ruby 等と比較すると、関数型プログラミングで Python が劣る典型的な一例になる
190 :
2014/12/10(水) 20:24:01.24 ID:Q728OFWk
と言うかどう見てもこないだまでこのスレに居た俺俺定義の人ですな
191 :
2014/12/10(水) 20:43:29.64 ID:Q728OFWk
よく見たら、そのスレで誘導かけてるの、話振ったお前本人じゃねーかw
俺俺定義が認められなかったから逃げて来たのか?
192 :
2014/12/10(水) 21:30:40.85 ID:AwBDqpLr
クロージャの定義は>>4って書かれてたがStandard MLにラムダ式はない
けど当然SMLにはクロージャがあるわけで
ソースはThe Definition of Standard ML, revised edition
193 :
2014/12/10(水) 21:46:37.74 ID:ZY5znPCs
関数型プログラミングってどういうのを指して言ってるんだろ
194 :
2014/12/10(水) 21:50:32.14 ID:gkNqf6iG
>>189のサンプルが手続き型全開の書き方で笑った


>>193
関数(に名前付けたくない)型プログラミング
195 :
2014/12/11(木) 21:30:20.83 ID:GpAyUabF
>>191
Swift スレの質問「Python が Swift や Ruby より劣ってるのは何か」に答えただけ
で、具体的に反論できないから罵倒を始めて Swift スレが荒れそうだったから、
こちらへ移動してきた


>>192
>>4 の定義において、局所環境やラムダ式は(クロージャという概念の構成要素であるけど)、
一般の言語だと直接的に対応する具象構文として存在していない(自分は知らない)
その書籍は読んでいないけど、おそらく Standard ML では "fn" <match> という具象構文を
「関数(function)」または「関数式(function expression)」と呼んでいると思う
>>4 だと、その具象構文 "fn" <match> はクロージャに対応する

またクロージャ(日本語では「閉包」)という用語は馴染みづらいので、
クロージャの具象構文を指して(便宜的に)無名関数/匿名関数/ラムダ関数/ラムダ式/関数式 ...etc と
別名で呼ばれることがある:
・Standard ML では、単純に「関数」や「関数式」と呼ぶ
・JavaScript では、"ECMAScript Specification" では(SML と同様に)「FunctionExpression」と呼ばれ、
 サイ本では「関数リテラル」と呼ばれている
  ・13 関数定義 (Function Definition) -- Under Translation of ECMA-262 3rd Edition
    http://www2u.biglobe.ne.jp/~oz-07ams/prog/ecma262r3/13_Function_Definition.html
・Python では、その言語リファレンスで「ラムダ式」と呼ばれている:
  ・6. 式 (expression) ― Python 3.4.2 ドキュメント
   http://docs.python.jp/3.4/reference/expressions.html#lambda
196 :
2014/12/11(木) 21:48:16.84 ID:AENhOzwc
>>195
肝心のクロージャの定義の引用はまだですか?
俺俺定義はお腹いっぱいなんですよ
197 :
2014/12/11(木) 22:44:15.05 ID:GpAyUabF
調べてみると、Python のラムダ式で任意の文が書けないという問題(>>189)は、
過去に何度もネット上で話題になっていたようだね:
・Is it possible to have multiple statements in a python lambda expression? - Stack Overflow (May 14 '09)
 http://stackoverflow.com/questions/862412/is-it-possible-to-have-multiple-statements-in-a-python-lambda-expression
・syntax - No Multiline Lambda in Python: Why not? - Stack Overflow (Aug 5 '09)
 http://stackoverflow.com/questions/1233448/no-multiline-lambda-in-python-why-not
・Why doesn't Python allow multi-line lambdas? - Programmers Stack Exchange (Aug 7 '11)
 http://programmers.stackexchange.com/questions/99243/why-doesnt-python-allow-multi-line-lambdas

そして、この問題を解決すべく数多くの提案が出された:
・AlternateLambdaSyntax - Python Wiki
 https://wiki.python.org/moin/AlternateLambdaSyntax

それら提案の中には、Ruby のブロックを真似しよう(similar to Ruby's blocks)、というものまであった
・[Python-ideas] Proposal for function expressions - Grokbase
 http://grokbase.com/t/python/python-ideas/097ccjz2c3/proposal-for-function-expressions

しかし残念ながら、これ以上続けても収束しそうもないから議論は打ち切り、とGuido氏が宣言(強権発動?)して終わった
・[Python-Dev] Let's just *keep* lambda
 https://mail.python.org/pipermail/python-dev/2006-February/060415.html
この顛末をGuido氏は「複数行のラムダは解けないパズル(unsolvable puzzle)」と語っている
・Language Design Is Not Just Solving Puzzles
 http://www.artima.com/weblogs/viewpost.jsp?thread=147358

まさに「みんなを納得させるほどの「結論」じゃない」というのは、こういう状況を指しているんだろね....
 http://peace.2ch.net/test/read.cgi/tech/1417333026/9
198 :
2014/12/11(木) 22:55:21.60 ID:aWaBOmKM
>>189
普段Python書かないからPythonicではないかもしれないが、だいたいこんな感じだろう。
http://ideone.com/0vAET2

それで、何が問題なんだ?
199 :
2014/12/11(木) 23:02:23.22 ID:GpAyUabF
>>196
ではクロージャ定義の引用元ソースを示そうね

答えは書籍「計算機プログラムの構造と解釈」、いわゆるSICP本だ
その中の節「3.2.1 評価の規則」に手続きオブジェクトが、いわゆるクロージャに対応する
 http://sicp.iijlab.net/fulltext/x321.html

そしてクロージャを視覚化したのが、
このページの図3.2にあるオタマジャクシの卵が2つ並んだ図形になる

単純な話だと思うけど、難しいかな?
200 :
2014/12/11(木) 23:27:50.83 ID:GpAyUabF
>>198
関数を宣言せずに書くという制約の元ですから、とてもPythonらしいコードだと思います
しかもループの代わりに関数再帰を使っているのですから、より関数型プログラミングらしいとも言えます

ただし、元々 Swift で書かれていたサンプルコードを各 LL へと書き直しているのですから、
もし以下の点を改善できれば(Pythonらしさという意味では)完璧でしょう:
・中間変数 f を宣言せず、リスト内包式の中にラムダ式をインラインで書く
・Swift のコードは辞書を使っているのですから、それを(勝手に)配列 digits へ改変せず、
 Python でも(Ruby や JavaScript と同様に)辞書を使って書く
201 :
2014/12/12(金) 00:10:51.51 ID:kNbqUbaQ
>>200
注文が多いな。
http://ideone.com/KWnSgA
202 :
2014/12/12(金) 09:01:50.64 ID:hLblKLHb
>>199
で、どこに「クロージャは無名関数でなければダメ」と書いてあるの?
「Schemeという特定の言語」で「クロージャはlambda式で作られる」と書いてあるだけだが?

いい加減、誤摩化して逃げ回るのは止めたら?
203 :
2014/12/12(金) 19:05:12.73 ID:1wfis/cT
別にPythonのラムダに式が書けないから問題だと言うだけなら荒れねーよ
そこで「だからPythonにはクロージャが無い」って言う
決して成り立たない等式を持ち込むから「いやそのりくつはおかしい」って言われてんのに
そしたら既存のクロージャという用語の定義のほうを弄ろうとするから叩かれてんだろうが

プログラミングに例えるなら、お前は自分の書いた関数で
組み込み整数型の値にそのままリスト処理を適用しようとして例外吐かれたから、と
整数クラスのほうがリストとして振る舞うようにメソッドを書き換えようとしてる
204 :
2014/12/12(金) 22:20:24.14 ID:ZYnyJXBo
>>201
お疲れさまです
中間変数 f は消えましたが、今度は中間変数 applyf が現れてしまいましたね....
205 :
2014/12/12(金) 22:38:08.46 ID:hhr7pvhS
206 :
2014/12/12(金) 22:42:02.66 ID:hLblKLHb
>>204
とりあえずクロージャの定義を貼っておきますね
反論よろしく

https://www.princeton.edu/~achaney/tmve/wiki100k/docs/Closure_(computer_science).html


> In computer science, a closure is a first-class function with free variables that are bound in the lexical environment.


ここの文章も良く読んでね

> The term closure is often mistakenly used to mean anonymous function.
> This is probably because most languages implementing anonymous functions allow them
> to form closures and programmers are usually introduced to both concepts at the same time.
> These are, however, distinct concepts.
207 :
2014/12/12(金) 23:33:45.85 ID:ZYnyJXBo
>>202
> で、どこに「クロージャは無名関数でなければダメ」と書いてあるの?

もちろん「クロージャは無名関数でなければダメ」とは書かれていない
同時に「ラムダ式に文が書かなくともクロージャである」とも書かれていない
SICP本を理解するには、記述されている定義から類推によって解釈できる知性が必要だね


>「Schemeという特定の言語」で「クロージャはlambda式で作られる」と書いてあるだけだが?

この節で記述されているのはクロージャの一般的な概念であり、特定の言語や実装には限定されない
ここで記述されている概念に沿って設計された言語であれば、たとえば:
・Scheme なら (lambda (x) .... ) で、
・Standard ML なら fn x => .... で、
・JavaScript なら function(x) { ..... } で、
・Ruby なら proc { |x| .... } で作られる
ここで.... の部分には、破壊的代入や入出力等の副作用を伴う任意のコードが書ける
唯一、書けないのは Python だけ

で、どこに「Schemeという特定の言語」と書いてあるの?
いい加減、誤摩化して言い逃れをするのは止めたら?
208 :
2014/12/12(金) 23:54:36.75 ID:ZYnyJXBo
>>205
ありがとうございます、これで完璧ですね

これで「何が問題なんだ?(>>198)」という議論を続けることができます
具体的には、>>189 の Swift/Ruby/JavaScript で書かれたコードと
>>205 の Python で書かれたコードを比較して、
「どちらがわかりやすいか/読みやすいか/書きやすいか?」という話です

で、これらは主観による評価ですから、
いくら議論しても誰もが納得できる結論へとは収束しないでしょう
すべての Pythonista にとって >>205 が読みやすく書きやすいと感じるのなら、
それはそれでいいんじゃないでしょうか
209 :
2014/12/13(土) 00:01:46.30 ID:HrrHquek
一時変数を消すためにそんなパズルみたいな事やって読みやすいわけないだろw
210 :
2014/12/13(土) 00:13:09.40 ID:HrrHquek
>>207
schemeではlambdaが本質的なもので(define (f x) 〜)はシンタックスシュガーだけど、
pythonではdefが本質的なものでlambdaの方がシンタックスシュガーなのでは。
211 :
2014/12/13(土) 00:39:02.24 ID:gzcIElev
>>206
Wikipedia 英語版の解説と同じに見えるけど、何を言いたいのかな?
・Closure (computer programming) - Wikipedia, the free encyclopedia
 http://en.wikipedia.org/wiki/Closure_(computer_programming)
単に他人の文書をコピペして終わりにするだけでなく、引用した文書(ソース)を元に、
自分なりの意見を思考しそれを自分の文章として表現できるようになったほうがいいと思う


で、とりあえず反論しておくと、その文書(= Wikipedia)の
章「mplementation and theory」には、冒頭に以下の記述がある

> Closures are typically implemented with a special data structure that
> contains a pointer to the function code, plus a representation of
> the function's lexical environment (i.e., the set of available variables)
> at the time when the closure was created.

この理論としてのクロージャ定義は、SICP本(>>119) および >>4 のそれと矛盾していない
そして Haskell のような純粋関数型言語に限定した文脈ではないのだから、
文中の "function code" は(>>207 で書いたように)単なる式だけではなく
破壊的代入や入出力等の副作用を伴う任意のコードも書けると解釈するのが自然だと考える
212 :
2014/12/13(土) 02:01:28.39 ID:6/3yjF6w
>>4
>クロージャを識別子に束縛したものが一般的な「関数宣言」である

よかった、pythonにもちゃんとクロージャあった
213 :
2014/12/13(土) 02:13:23.84 ID:6/3yjF6w
foo = lambda bar: bar
これはクロージャである

っていうのが偽であることを定義から証明すればいいんじゃないかな
反例あげればいいだけだよね?
214 :
2014/12/13(土) 02:17:02.89 ID:6/3yjF6w
あ、まちがえたそれはクロージャじゃない
def foo():
bar = 1

これに訂正
215 :
2014/12/13(土) 07:14:46.97 ID:toJAZvUP
>>208
それはPythonの書き方じゃないんだよ。
お前が>>200で指定したから、結果的にそうなっただけで。

それで、結局「クロージャを書けない」から「読みにくい」に問題をすり替えて終わりか?
216 :
2014/12/13(土) 08:00:50.00 ID:1EyzOdES
217 :
2014/12/13(土) 10:42:15.83 ID:ygYpq94K
イデオンこわい
218 :
2014/12/13(土) 12:26:47.45 ID:sGDpUYPr
>>207
> もちろん「クロージャは無名関数でなければダメ」とは書かれていない

なんだ、Pythonのdefで良かったんだ

知らないみたいだから教えてあげるけど、Pythonではdefで関数定義すると
環境を持ったクロージャになってるんだよ、勉強になったね
219 :
2014/12/13(土) 12:40:53.92 ID:sGDpUYPr
>>208
>>201のapplyfは、特定のロジックに依存しない汎用的な関数だけど、
こういうものの定義や使用も認めないってことは
ライブラリによる拡張も否定するってことでOK?

ライブラリを使わないと外部イテレータが使えないRubyをdisってるの?
220 :
2014/12/13(土) 14:05:13.26 ID:ZLG0O37u
>>207
書かれてない要素を勝手に追加するから
オレオレ定義って言われるんだよ

クロージャの定義には無名関数であることも、文が書けるor書けないことも、
含まれてないんたから、勝手に条件に追加すんな
221 :
2014/12/13(土) 14:39:36.41 ID:1EyzOdES
>>217
>>216 はPythonのlambdaからでも副作用を伴うメソッド呼べますよってコードだな
222 :
2014/12/13(土) 20:13:18.59 ID:gzcIElev
>>210
本質という言葉の定義が曖昧ですが、自分なりにコメントします

まず >>206(= Wikipedia, >>211)の章「2.1 First-class functions」には、
その冒頭に以下の記述があります

> Closures typically appear in languages in which functions are first-class values ―
> in other words, such languages enable functions to be passed as arguments,
> returned from function calls, bound to variable names, etc.,
> just like simpler types such as strings and integers.

つまりクロージャは「一級の値( first-class values)」であると定義しています
従って(一級市民ではない関数宣言 def よりも)一級市民であるクロージャ lambda を
本質とするのが正しいのではないかと思います
(「宣言された関数は一級市民だけど、宣言そのものはそうではない」という意味です、念の為)

(あくまで私見ですが)可能性があるのは、関数スコープ方式の手続き型言語である Python では、
関数型言語の特性を追加する際にクロージャを(lamda ではなく)宣言された関数へ実装したほうが
(開発工数や難易度の視点からは)容易だったのではないかと推測します(詳細は省略....)
一言で言えば「Python は手続き型言語だから」ということですね
223 :
2014/12/13(土) 20:39:14.11 ID:HrrHquek
>>222
本質的ってのは、よりプリミティブなものっていう意味で書いたんだよ。

first-class valueってのは、変数に代入したり、関数の引数に渡したり、
関数の値として返したりできるオブジェクトの事だよ。
def だの lambda だのっていうのはそういうオブジェクトであるクロージャを作り出すための構文だよ。

pythonは手続き型言語だっていうけど、そんなの当たり前だろw
rubyだのjavascriptだのだって手続型言語だよ。
224 :
2014/12/13(土) 21:42:39.17 ID:gzcIElev
>>223
> 本質的ってのは、よりプリミティブなものっていう意味で書いたんだよ。

その意味であれば、関数型言語と Ruby/JavaScript だと
関数定義よりもクロージャのほうがが本質的だね
プリミティブな名前とクロージャから関数(or メソッド)が作られるという
因果関係があるのだから

ただし、Python だけは違うみたいだね


> rubyだのjavascriptだのだって手続型言語だよ。

外見は手続き型言語だけど、どちらの言語もLISPをベースに設計されている
だから最初から関数型言語と同等なクロージャを備えて誕生した
それが知られるようになったのは最近だから、知らない人は多いけどね.....
手続き型言語として生まれ、後付けで関数型を増築した Python とは違うのだよ
 http://peace.2ch.net/test/read.cgi/tech/1409526637/857

--
> パクリどころか Ruby と JavaScript は、これらの作者自身が
> Lisp を基礎として言語を設計したと語っている
>
> ・Lisp から Ruby への設計ステップ
>  http://yohshiy.blog.fc2.com/blog-entry-250.html
> ・JavaScript: The World's Most Misunderstood Programming Language
>  http://www.crockford.com/javascript/javascript.html
> (邦訳版「JavaScriptの勉強:世界で最も誤解されたプログラミング言語」へのリンクは閉鎖)
>
> だから関数型プログラミングという土俵の上で Ruby や JavaScript に
> 手続き型言語の Python がいくら挑戦しても勝てずに負け続けているのは、
> しごく当然な結果なわけ
225 :
2014/12/13(土) 22:07:55.30 ID:HrrHquek
>外見は手続き型言語だけど、どちらの言語もLISPをベースに設計されている

S式で表現されてなきゃlispじゃねえよ。
226 :
2014/12/13(土) 22:14:57.19 ID:HrrHquek
だいたいlispが関数型言語だって言うことにも抵抗がある。
227 :
2014/12/13(土) 23:06:18.71 ID:gzcIElev
>>224
>手続き型言語として生まれ、後付けで関数型を増築した Python とは違うのだよ

自己レスで補足する(すべての手続き型言語が Python と同じではない....

同じ手続き型言語に関数型の特性を追加した言語でも、
調べた範囲だと少なくとも Perl5/Java8/C++11 のクロージャは
>>4,>>119 のクロージャ定義に沿って設計され、
・クロージャ内で任意の文が書ける
ただしそれら言語がクロージャをサポートした時期は遅かった
真面目に設計したからだろう

対して Python の関数型サポートは素早かったけど、検討が不十分だったと言うほかない
リリース後に改善要望/議論紛糾したあげく、結論を出せず現在に到る(>>197)
228 :
2014/12/13(土) 23:27:26.05 ID:fdPKe7oz
横だけど、
Rubyのブロックはラムダじゃないしファーストクラスでもないよね

メソッドにラムダを渡すこともできるけど、不格好なんだが?
これって、ここのオレオレ定義にてらすとどうなの?

なんだか、ラムダに文を書けない(書かない)ようにしている
Pythonの仕様をあげつらうためだけにオレオレ定義をこねくって
悦に入ってるPythonアンチがいるって感じがするだけなんだが。
229 :
2014/12/14(日) 00:01:22.20 ID:Gw1grNBM
Rubyのブロックの中に副作用をジャンジャン書いて
それを繋げるスタイルを関数型と言われても困るわ

文推奨の時点で関数型とは言い難いわけだし
230 :
2014/12/14(日) 00:38:38.65 ID:iRnVJ1/v
オレオレクロージャ君は言葉が通じないし、
必死でググった的外れで糞長い引用でしか反応しないし、
相手するだけ無駄。
231 :
2014/12/14(日) 02:05:45.83 ID:sl2oQCLD
うん、ただのPythonアンチでしか無いと思うよ。
Ruby好きでPython嫌いな俺は、Pythonのlambdaが使いにくいのには同意するが
そのためにクロージャの定義のほうを捻じ曲げるのは、ありえないと感じるよ。
そもそも、その定義だとRubyどーなんねん、と思うし。

Rubyには「他言語の関数」に相当するものがなく、
一定の条件を満たし、見かけ上、関数のような呼び出しが可能なメソッドを
便宜的に「関数」と呼んでいるだけだし。

クロージャはブロックという形で存在はしているが、
彼の言う定義に従うならブロックはファーストクラスでなければならない。
でもRubyのブロックはファーストクラスとは言い難い。
lambda関数(実際はもちろんメソッド)が返すのはProcクラスのインスタンスだけれども、
ブロック.is_a? Procインスタンス では無い。そしてメソッドや、ましてや関数でもない。
そもそもブロック単体では値としては取り回せないからProcクラスがあるんだし。
232 :
2014/12/14(日) 10:29:16.99 ID:63H3dBz7
オレオレクロージャ君って少し前に某スレでPython disってた人にそっくり
233 :
2014/12/14(日) 14:05:17.21 ID:2A/iPobJ
lambda

ラ…ランバダ…
234 :
2014/12/14(日) 14:52:29.83 ID:VBy2GaOL
>>233
もっと勇気をもって!
ランバダ!
235 :
2014/12/14(日) 15:49:06.80 ID:hNeAViIY
       ,-----、
      /     ヽ.
      | (・) (・) |
  /ヽ ̄       ̄ノヽ
 /   ヽ_____/  ヽ
 |   /    l   |    |\
 |   |  。ノ ヽ。 .|___|  \
 ヽ___ヽ    +   ノ,、_、_、_ヽ  \
  |  ヽ| ̄ ̄ ̄ ̄ | ;;;;;;;;;;;;;;;\_ ノ
 < ````/\     /\;;;;;;;;;;;;;;;;;/
  ヽ;;;;;;|  \_/   ヽ;;;;;;;;;;;ノ
    ̄.|___/   \__) ̄   .____
    /   |     |   |    \ /
   (___|     |__)===⊃

      勇者の父 ランバダ
236 :
2014/12/14(日) 15:54:41.51 ID:KqwrXZGg
無駄にMP消費していざという時に足りなくなって犬死にする無能
237 :
2014/12/14(日) 20:48:34.17 ID:lkA9lgpO
>>228
>Rubyのブロックはラムダじゃないしファーストクラスでもないよね?

Python や JavaScript のクロージャは、(名前が宣言された)関数と同様に
クロージャへ引数を渡すだけで評価される
  closure = function(x) { return x + 1 }  # クロージャを生成して名前に束縛
  succ_of_one = closure(1)  # クロージャを評価
それに対して Ruby だと、メソッド Proc#call を呼ばなければ評価されない
  block = lambda { |x| x + 1 }  # ブロックを生成して名前に束縛
  succ_of_1 = block.call(1)  # ブロックを評価
従って >>4(>>199) の関数型言語におけるクロージャ定義に当てはめれば
「Ruby のブロックは(本物の)クロージャではない」あるいは「....はクロージャもどきである」
またRuby のブロックの意味はオブジェクト(Procクラスのインスタンス)だからファーストクラスである

>メソッドにラムダを渡すこともできるけど、不格好なんだが?

たしかに不格好だ
 def foo(x, y, &block); .... ; end  # メソッドを定義
 foo(x, y, lambda { |z| .... })  # メソッドの呼び出し
だから Ruby には「ブロック付きメソッド呼び出し」という構文糖が最初から用意されている
 def foo(x, y); .... ; end  # メソッドを定義
 foo(x, y) { |z| .... }  # メソッドの呼び出し

>Pythonの仕様をあげつらうためだけにオレオレ定義をこねくって

>>4 のクロージャ定義の引用元(ソース)は >>199 で示したが、まともな反論はない
むしろオレオレ定義と騒ぎ立てていた連中がSICP本を読んだ事もないお馬鹿達だったのでは?
あるいはSICP本を読んでいなくても、関数型言語の操作的意味論や処理系実装の知識があれば
>>4 がオレオレ定義でないことは直ぐに理解できていたはず
238 :
2014/12/14(日) 21:10:51.70 ID:Gw1grNBM
>>237

後から言い逃れようとしても、掲示板にはログが残ってるから無駄ですよ
>>98に対する>>102の返答の時点で、何も分かってなかったのは明らか
239 :
2014/12/14(日) 21:42:31.25 ID:k3gK/GUJ
>>237
RubyのブロックはProcクラスのインスタンスではないよ
ブロックそのものは、メソッド呼び出し文法の一部でしかない
そのブロックを、それのみで値として扱うためのラッパがProc
240 :
2014/12/14(日) 21:59:53.72 ID:Y1wljoB2
Rubyistは全員クロージャを間違った解釈してるのか?
それとも、奴だけなのか?

そこが気になるな。
241 :
2014/12/14(日) 22:03:54.59 ID:lkA9lgpO
>>229
残念ながら Ruby の関数型プログラミングというスタイルは、
全世界の Ruby コミュニティですでに認知されている
・Functional programming with Ruby
 http://code.google.com/p/tokland/wiki/RubyFunctionalProgramming 
・Rubyによる関数型プログラミング(上記文書の日本語訳)
 www.h6.dion.ne.jp/~machan/misc/FPwithRuby.html
また Ruby の「ブロック付きメソッド呼び出し」とそれらを並べる(=チェーンさせる)スタイルは、
Apple の新言語である Swift にそのまま採用された
他の言語、たとえばラムダ式が導入された Java 8 だと、このスタイルをストリームと呼んでいる
・ラムダ式で本領を発揮する関数型インターフェースとStream APIの基礎知識 (2/3) -- @IT
 http://www.atmarkit.co.jp/ait/articles/1404/30/news017_2.html

個人的には、Ruby と多くのOOP言語で採用されているメソッドチェーン・スタイルは:
・データの流れ(いわゆるデータフロー)とメソッドの並びが一致し、
・カッコが入れ子にならない
から、可読性が高いと思う
 table.select { |r| .... }.map { |r| .... }.inject(0) { |n, r| .... }  # >>189 を参照
それに対して、Python 伝統的な関数適用スタイルでは:
・データの流れ(いわゆるデータフロー)とメソッドの並びが逆転し、
・カッコが入れ子になる
 reduce(lambda n, r: ...., 0, map(lambda r: ...., filter(lambda r: ...., table)))
どちらを優れているか?という評価は主観だから、各自で判断してもらいたい


(まだ続くので、ここで切る)
242 :
2014/12/14(日) 22:48:49.10 ID:lkA9lgpO
>>238
次に、関数型プログラミングと(文の評価によって起こる)副作用との関連について

まず関数型プログラミングで副作用は推奨されていない
基本的には map/filter/reduce (Ruby では map/select/inject) といった高階関数を使った
(副作用の無い)参照透明性のあるコードが推奨されている
これは >>241 の文書「Rubyによる関数型プログラミング」で具体的なコード例を使って解説されている

おそらく誤解したのは >>189 の Swift/Ruby/JavaScript コードで while 文と
ローカル変数への破壊的代入を用いていたのを見たからだと思うけど、
これは、「わざわざ」副作用を使った手続き型プログラミングほうが簡潔になる「お題」を選んだからだ
実際、副作用の代わりに再帰を使った Python コード >>205 は「普通のプログラマ」には分かりにくい
(Python だけでなく、この「お題」は Ruby であっても再帰を使えば同じく分かりにくいコードになる)

また(Ruby を含む)大半の手続き型言語処理系だと、TCO(末尾再帰最適化)は実装されていないか不完全である
だから手続き型言語における関数型プログラミングにおいて、
再帰プログラミングには(分かりづらいだけでなく)実用上の制限があるから
ツリーのような再帰的データ構造の探索問題などに限定して利用すべき(上記文書の節「再帰」を参照)

これらの判断について、上記の文書では以下のように記述されている(節「おわりに」から引用):
 「Rubyは基本的には命令型言語であるけれど、 関数型プログラミングへの際立った潜在能力があるのだから、
  それらをいつどのように使うか(そして、いつ使わないか)を知っておくべきである。 」
243 :
2014/12/14(日) 22:59:19.75 ID:iRnVJ1/v
もうみんなgaucheに改宗しようぜ
244 :
2014/12/14(日) 23:34:55.92 ID:lkA9lgpO
>>231
>Rubyには「他言語の関数」に相当するものがなく、......

これは(>>237 に書いたけど)、まったくそのとおり


>でもRubyのブロックはファーストクラスとは言い難い。

ここの「....とは言い難い」という文章表現は曖昧だね
(なぜ「....ではない」と断定的に言い切れなかったのだろうか?)

まず >>237 で書いたように、Ruby の「ブロック付きメソッド呼び出し」は構文糖だ
(対して、簡潔な構文を追求した Smalltalk では、常にブロックはオブジェクトである)
これを構文糖にした理由の一つはメソッド呼び出しコードを簡潔にする目的(>>237)であるが、
ブロックを多用する Ruby のプログラミングスタイルでは、ブロックを評価するたびに
Procオブジェクトを生成していたのでは実行効率の面でオーバヘッドが大きいという理由がある
このためRubyインタプリタの内部だと、
ブロックは(重いオブジェクトを表すC構造体ではなく)専用の軽量なC構造体で表現されている

ただし、(たとえ内部表現が Proc オブジェクトと異なっていても)プログラマから見れば問題にならない
なぜなら、渡されたブロックをいつでも Proc オブジェクトへ変換できる構文糖が最初から用意されているから....
たとえば foo(x, y) { |z| .... } という「ブロック付きメソッド呼び出し」に対して(>>237):
・def foo(x, y); .... ; end
・def foo(x, y, &block); .... ; end
 という2つのメソッド定義は「いつでも」交換できる

まとめると:
 Ruby のブロックは内部表現だと Proc オブジェクトではないが、
 プログラマ目線ではファーストクラスのオブジェクトとして扱うことができる
245 :
2014/12/14(日) 23:42:14.32 ID:NejhiS1a
gaucheいいよね
246 :
2014/12/14(日) 23:49:27.85 ID:lkA9lgpO
>>238
つまり「Ruby のブロックはクロージャである」という初歩的なミスについて、
>>102 をレスした時点から数えて >>228 が指摘するまでの間には
誰一人気付けなかった事実が「掲示板にはログが残ってるから明らか」になるわけですね



た い へ ん わ か り や す い で す
247 :
2014/12/14(日) 23:57:54.55 ID:pRYhwT4i
最近はほぼgaucheでしかプログラム書いてない。
もう止められない体になってしまった。。。
248 :
2014/12/14(日) 23:58:44.82 ID:iRnVJ1/v
俺、numpyとscipyとopencvのサポートがgaucheにくっ付いたら、python捨てるんだ!(遠い目
249 :
2014/12/15(月) 00:02:02.47 ID:wtT+wvpm
common lisp処理系の方が速いのあるしライブラリも充実してるし良いよ
250 :
2014/12/15(月) 00:07:51.10 ID:G9R+2lJx
ループしないで全部再帰で書きたい
251 :
2014/12/15(月) 00:08:50.51 ID:YlFhPVoF
lisp-2なのが何となく嫌
252 :
2014/12/15(月) 00:31:53.12 ID:K7E8QpHY
>>250 いいよ
253 :
2014/12/15(月) 08:42:12.40 ID:J0ddkTzC
>>246
だってRubyなんてマイナー言語どうでも良いし?
254 :
2014/12/15(月) 11:24:34.16 ID:yMEZ5G45
>>240
こいつだけです。と言うかRubyに対しての知見も怪しい

>>244
Rubyのブロック付きメソッド呼び出しのほうを構文糖と。またオレオレ定義?
「ブロック付きメソッド呼び出し」は文法だ、これはlambdaより先に実装されてる
そのブロック部分のみを扱うためにProcクラスもlambdaより先に実装されていて、
そのProcを簡便に扱うためにlambdaと言う構文糖が後から出来た

と言うか「ブロック付きメソッド呼び出し」、昔は「イテレータ呼び出し」だった
イテレータ呼び出しを汎化した結果生まれたのが、ブロック付きメソッド呼び出し
その時代からmapやselectなどの
今で言う関数型的なメソッド群を実装するモジュールEnumerableは
「これをincludeするクラスにはeachメソッドを実装すること」としていた

もしRubyが関数型として設計されていてProcが主なら
call必須なんてことにはしなかっただろうし
関数がメソッドの一種なんてことにはなってない
そしてEnumerableはeachではなく、Array辺りを要求する高階関数群だっただろう
RubyはOOPLとして設計され、それが主で
関数型プログラミングは結果として付いてきた
そこでProcに関数型のラムダ的な挙動を付加し生成するlambdaも出来たんだよ
255 :
2014/12/15(月) 20:13:34.89 ID:AoWRRy2d
>>241
> また Ruby の「ブロック付きメソッド呼び出し」とそれらを並べる(=チェーンさせる)スタイルは、
> Apple の新言語である Swift にそのまま採用された
Obj-C が inline Smalltalk が書ける C なのに、Swift が Ruby をまねたみたいなデマはやめてくれる?

それと、 Ruby で関数型スタイルのプログラムを書けるということを、Ruby で書いたら関数型プログラムになるかのように書くのもやめてくれる?
256 :
2014/12/15(月) 21:18:41.61 ID:QjagSoag
主観を事実であるかのように語る客観性の無さ

オレオレ定義の根拠を問われて自身の過去の書き込みを引用するコミュニケーション不全

完全に論破されると、自分の間違った主張を相手が言い出したと歴史歪曲しようとする卑怯さ


全てを兼ね備えると>>241みたいな奴になる
257 :
2014/12/15(月) 22:27:41.97 ID:eMlPsgxM
>>254
>そのブロック部分のみを扱うためにProcクラスもlambdaより先に実装されていて、
>そのProcを簡便に扱うためにlambdaと言う構文糖が後から出来た

lambda はメソッドであって、構文糖ではない
>>231 では「もちろん(lamda は)メソッド」と主張しているから、もしも同一人物のカキコなら矛盾している
いったいどちらが正しいの?

>イテレータ呼び出しを汎化した結果生まれたのが、ブロック付きメソッド呼び出し

その「汎化」とは具体的には何を指しているのかな?

もともとイテレータという概念と用語は手続き型言語 CLU で生まれ、Ruby でも採用された
ただし CLU のイテレータは for ... in 構文というループ処理での利用に制限されたのに対して、
(クロージャとしての)ブロックを備えた Ruby ではループ処理以外にも利用できる形で「最初から設計された」
・Rubyist のための他言語探訪 【第 2 回】 CLU
 http://magazine.rubyist.net/?0009-Legwork
このためループ処理でもないのにイテレータ(iterator, 反復子)という用語は紛らわしいという声が挙り、
用語「イテレータ呼び出し」は「ブロック付きメソッド呼び出し」へと名称が「後から変更された」

つまり単に用語の命名が「後から」改められだけで、言語仕様の基本は「最初から」何も変わっていないはずです

>RubyはOOPLとして設計され、それが主で関数型プログラミングは結果として付いてきた

スマンが、いいかげん説明は面倒なので以下を読んでください
・Lisp から Ruby への設計ステップ
 http://yohshiy.blog.fc2.com/blog-entry-250.html
ただし、もともとメソッド lambda は proc の別名で同じ意味でしたが、
1.8 の時代に lambda の挙動が変更されメソッドとして独立しました
その変更の理由は関数型プログラミングと関連する可能性はありますが、詳しい背景を自分は知りません
言語仕様として「関数型プログラミング向けに後から追加/変更」されたのは、自分の記憶だとコレくらいしかありません
258 :
2014/12/15(月) 22:40:54.50 ID:G9R+2lJx
俺が平安時代に読んだ本だと、iteratorはアイテレータって書かれてたな。
あとhierarchyはハイアラーキだった。
259 :
2014/12/15(月) 22:46:59.52 ID:G9R+2lJx
そんなにlispに憧れてるなら、lispを使えばいいのに。
260 :
2014/12/15(月) 22:47:19.92 ID:BuhXHDiL
> 1.8 の時代に lambda の挙動が変更されメソッドとして独立しました
> その変更の理由は関数型プログラミングと関連する可能性はありますが、詳しい背景を自分は知りません

RubyのProc.newで作られるオブジェクトは
returnの挙動が普通の関数と違ってキモすぎるので
lambdaの方だけでも普通に直したんでしょう
261 :
2014/12/15(月) 23:02:52.91 ID:BuhXHDiL
さらに言えば、Rubyのブロック変数のスコープの扱いが1.9で仕様変更されてるけど、
それについてmatz自身が

> それは、Rubyが最初から関数型言語としてスタートしてないからであって、言語が違うからですよね。

と語っているね


http://www.atmarkit.co.jp/news/200907/24/ruby.html
262 :
2014/12/15(月) 23:10:49.42 ID:eMlPsgxM
>>255
>Obj-C が inline Smalltalk が書ける C なのに、Swift が Ruby をまねたみたいなデマはやめてくれる?

スマン、ここは説明が足りなかった、Tailing Closure のことを言いたかった
Objective-C を含むほとんどの言語では、引数をカッコで囲んで関数(or メソッド)へ渡す文法になる
基本的には Swift も同じですが、引数リストの最後がクロージャである場合に限り、
そのクロージャ引数を閉じカッコの直後に置く事ができます
・collection.map({ ..... })  // 一般的(常識的?)な書き方
・collection.map() { ..... }  // クロージャを引数リストの直後へ移動できる
・collection.map { ..... }  // さらには丸カッコ () も省略できる
これを Ruby で書くと、以下のようになります
・collection.map(lambda { ..... })  # Ruby だと一般的ではない
・collection.map() { ..... }  # ブロックを引数リストの直後へ移動できる(ブロック付きメソッド呼び出し)
・collection.map { ..... }  # さらには丸カッコ () も省略できる(これが普通の Ruby らしい書き方)
これと同じ書き方ができる言語を Swift と Ruby の他に自分は知りません
そして発表時期的に Ruby の後に Swift が生まれたから、ここは Ruby の影響ではないかと「推測」しました
Tailing Closure の由来に関するソースは持っていないので、デマと言われてもしかたがありませんね....


>それと、 Ruby で関数型スタイルのプログラムを書けるということを、Ruby で書いたら関数型プログラムになるかのように書くのもやめてくれる?

Ruby は手続き型言語なのだから、プログラマが意識しなければ関数型プログラミングのスタイルにならないのは当たり前
いいかげん説明は面倒なので、以下の文書をよく読んでください:
・Rubyによる関数型プログラミング
 www.h6.dion.ne.jp/~machan/misc/FPwithRuby.html
もし具体的な疑問/質問があれば、個別に返答します
263 :
2014/12/15(月) 23:24:28.86 ID:eMlPsgxM
>>260
おそらくその通りだと思います


>>261
もしも Matz が Lisper ではなく Schemer であったなら、
違った結果になっていたかもしれませんね
264 :
2014/12/16(火) 00:31:08.98 ID:IiuX/rSM
自己レスになりますが、>>242 では:
> (Python だけでなく、この「お題(>>189)」は Ruby であっても再帰を使えば同じく分かりにくいコードになる)
とカキコしました
で、後から考え直して「手続き型のループ&破壊的代入」ではなく、しかも「関数再帰」も使わずに、
参照透明性がある関数型プログラミングのコードを考えてみました
 http://ideone.com/UrfbuL
ポイントは「反復に組み込みメソッド loop」を「ブロック脱出に引数付のbreak文」を使った2点です
なおメソッド loop は一般に loop do .... end という手続き型のスタイルで書かれることが多いために
ループ構文の一種と誤解されがちですが、(lambda を構文糖であると >>254 が 勘違いしたように....)
loop はメソッドですので(コードで示したように) inject へチェーンさせることができます

また「参照透明性はあっても、手続き型の制御構造であるbreak文の利用は反則ではないか?」という
指摘を予測して、
同じスタイルで(break文の代わりに)組み込みメソッド catch と throw を使ったコードも書きました
 http://ideone.com/SaCAFi
ただし、この catch/throw は大域脱出のために用意されたメソッドですから、
今回の「お題」のように単一ブロックを脱出するだけならbreak文を使うのが素直だと考えます

ついでに(catch/throw の代わりに)Scheme 由来の継続(continuation)を使ったコードも書きました
 http://ideone.com/5t1VEq
265 :
2014/12/16(火) 02:54:32.21 ID:178msYck
こんな無駄に遠回しなコード沢山書いてどんだけオナニー好きなんだよ。
266 :
2014/12/16(火) 02:58:06.18 ID:178msYck
>>198の爪の垢でも煎じて飲めよ。
267 :
2014/12/16(火) 07:18:26.71 ID:/LiRSDzk
>>257
もちろん、本当はただのメソッドであってlambdaは文法要素ではない
あたかも「ブロックはlambdaの構文糖」であるかのような主張をするから、その対比としてそう書いたまでだよ
分かりにくかったね、「構文糖のような存在のメソッド」と修正しておくよ
268 :
2014/12/16(火) 07:24:54.85 ID:/LiRSDzk
まあ、「構文糖のような存在のメソッド」って用語がおかしいというなら
「真のクロージャ」って用語もおかしいのだと気付いて欲しいな
269 :
2014/12/16(火) 07:48:21.23 ID:PApLEh59
なんか知らんけど伸びてて嬉しいです
目標はGCスレ超えです
270 :
2014/12/16(火) 08:02:21.01 ID:/LiRSDzk
一応lambdaというメソッドの実装された時期について調べてみたら、結構昔から存在自体はしてたのね
元々procと同じなのに字数多い&Procなのにlambdaって覚えにくいのと1.4当時は関数型とか知らんかったからスルーしてたのかな
そこは俺の記憶違いだったわ
271 :
2014/12/16(火) 08:45:33.81 ID:7mh816Ug
クロージャがなければ参照カウント型のGCで済むんじゃないか説があるし
ワンチャンあるよ
272 :
2014/12/16(火) 08:47:53.04 ID:7mh816Ug
構文糖衣とかいいながら
ラムダって名前から甘そうな印象をうけない
名前が悪いよ考え直すべき
273 :
2014/12/16(火) 08:56:24.06 ID:7mh816Ug
クロージャって名前も固いし
意味わかんねえから
貝殻のclamを頑張ってもじって
クリームって名前にするくらいの
努力はあってよかった
274 :
2014/12/16(火) 09:58:24.78 ID:/LiRSDzk
>>272
そういう意味ではfunctionを名前ありの関数にもラムダにも使ったJavaScriptは上手いと思う
らむだ何ソレ?な人にも「関数名書かないで使うと無名の関数も作れるよ」って説明で事足りるもんね
275 :
2014/12/16(火) 10:58:59.39 ID:gf3D6lb/
ブロックとProc.newとprocとlambdaと->があるRubyはやり過ぎ
276 :
2014/12/16(火) 11:12:47.94 ID:/LiRSDzk
>>275
まあ、Rubyは他の組み込みライブラリでも
エイリアスや似たようなメソッド、所属モジュールが違う同様のメソッドとか持つのは普通だからね
俺は昔からproc派、RubyのProcとλ算法は別物だと思うからあの挙動でいいし、早く書けるし
277 :
2014/12/16(火) 22:27:19.26 ID:IiuX/rSM
>>267
>あたかも「ブロックはlambdaの構文糖」であるかのような主張をするから、

いや「あるかのよう」ではない、>>244 で以下のように、断定的に明記したとおり:
 > まず >>237 で書いたように、Ruby の「ブロック付きメソッド呼び出し」は構文糖だ
Ruby インタブリタの内部では「ブロック付きメソッド呼び出し」と
「値渡しされた Proc オブジェクト」とは別の表現(C構造体)が用いられ、それらを相互変換している
ただし Ruby プログラマの視点では、値渡しされたProc オブジェクトで「あるかのように」
(すなわちファーストクラスとして)ブロックを扱う事ができる、だから「ブロックは構文糖」になる

ブロックを評価するのにメソッド Proc#call が必須(>>254)なのは、また別の理由....
それらをごっちゃにすべきではない


>>268
>まあ、「構文糖のような存在のメソッド」って用語がおかしいというなら

いや「構文糖のような」という比喩表現であれば、何の問題も無い

>「真のクロージャ」って用語もおかしいのだと気付いて欲しいな

>>4 でクロージャ定義を示してから >>199 までソースを明かすのを遅らせたのは意図的だったけど、
「真のクロージャ」という曖昧な表現でいらぬ混乱を与えたことは余計だったと反省している
最初からストレートに「関数型言語のクロージャ」とすべきだったね
278 :
2014/12/16(火) 23:35:24.13 ID:178msYck
関数型言語のクロージャと非関数型言語のクロージャはナニが違うですか。
279 :
2014/12/17(水) 00:34:28.88 ID:NwnPjzlT
結局、Pythonのクロージャは本物で、Rubyのブロックは偽物って結論になったんか?
280 :
2014/12/17(水) 06:09:12.08 ID:4QPsGplH
>>279
彼の中だけではそういうことらしい
281 :
2014/12/17(水) 06:10:48.27 ID:HxoNcsla
環境もちこしてる関数っぽいやつならクロージャでいいじゃん
282 :
2014/12/17(水) 06:13:43.20 ID:4QPsGplH
って彼の中だけでは逆か

>>281
と言うか元々環境持ち越すのがクロージャの要件でしょ
283 :
2014/12/17(水) 06:16:00.02 ID:HxoNcsla
なんで突っ込まれてるのかさっぱりわからん
284 :
2014/12/17(水) 06:21:06.36 ID:4QPsGplH
>>283
突っ込んでないよ、超同意してんだよ
285 :
2014/12/17(水) 07:54:17.64 ID:HxoNcsla
まじかよ世界は平和だった
286 :
2014/12/17(水) 20:35:47.86 ID:JUumI3zm
>>278
もともとクロージャの概念/用語は関数型言語で生まれたものだから、
「非関数型言語のクロージャ」とは:
  「関数型言語のクロージャ」の定義に対して、どれくらい忠実に実装されているか?
という相対的な評価になるね
287 :
2014/12/17(水) 21:10:46.15 ID:cFsqVLS5
そして、オリジナルのクロージャーが
一番優れているとかいう信者が現れるわけかw

普通はオリジナルを改良した方が
優れているんだがな。
288 :
2014/12/17(水) 21:39:32.52 ID:JUumI3zm
>>279
でれでは、ここまでの結論をまとめてみる
まず最初は。>>286 の評価結果から:
[Python:X]
  Python の lambda 構文は式しか書けないという制限があるから、
  クロージャ固有の局所環境を持つことができない
  したがって、Python の lambda 構文は「関数型言語のクロージャ」ではない
[Ruby:X]
  Ruby のブロックはオブジェクトであるから、
  その評価にはメソッド Proc#call をコールしなければならない
  したがって、Ruby のブロックは「関数型言語のクロージャ」ではない
[JavaScript:O]
  JavaScript の関数リテラルは任意の書けるからクロージャ固有の局所環境を持てるし、
  なおかつ引数に適用するだけで評価できる
  したがって、JavaScript の関数リテラルは「関数型言語のクロージャ」である
  結果として、最も忠実に「関数型言語のクロージャ」が実装されている(>>274)、と言える

続けて、この評価結果が現実のプログラミングに与える影響をまとめる
ここでは Apple 公式リファレンスに含まれる Swift クロージャのサンプルコードを「お題」とした(>>189)
・高階関数 map に与えるクロージャをインラインで書ける
  [Python:X]
  ・インラインでは関数再帰を使った可読性の低いコードになってしまう(>>205)
  ・このため、一般には(インラインで書くのはあきらめて)関数定義を使わざるをえない
  [Ruby & JavaScript:O]
  ・インラインで自然な while ループを使った(ふつうのプログラマにとって)分かりやすいコードが書ける
・参照透明性のある関数型プログラミングで書ける
  [Python:X] 関数再帰で書けるが、可読性の低いコードになってしまう(>>205)
  [Ruby:O] (関数再帰の代わりに)組み込みの高階関数風メソッドを使うことで、可読性の高いコードが書ける(>>264)
  [JavaScript:?] (書けるか否か、現時点では不明)
289 :
2014/12/17(水) 21:47:14.69 ID:JUumI3zm
>>279 を一部訂正

X:JavaScript の関数リテラルは任意の書けるから
O:JavaScript の関数リテラルは任意の文が書けるから
290 :
2014/12/17(水) 22:23:00.08 ID:NwnPjzlT
>>288
再帰関数よりwhileループが読みやすいレベルの人間が
関数型プログラミングについて語るなんて滑稽すぎる
291 :
2014/12/17(水) 22:32:56.00 ID:NwnPjzlT
>>288
あと、>>205じゃなくて>>201を評価すべきだと思うんだけど、
なんでワザワザ可読性を落としてる方を評価してるの?

まさか、Rubyでinjectは使って良いけど、Pythonでapplyfは使っちゃダメとでも言うつもり?
292 :
2014/12/17(水) 22:42:41.33 ID:KZ4YaCx1
可読性の良し悪しなんて定量的ではないものを評価対象にするとか
293 :
2014/12/17(水) 22:47:17.42 ID:ffqYUKYZ
> Python の lambda 構文は式しか書けないという制限があるから、
> クロージャ固有の局所環境を持つことができない


def make_f(n): return lambda x: x + n
f = make_f(1)
n = 1000
f(1) #=> 2

こういう風に、(引数以外の変数を)実行時の環境じゃなくて
自身が定義された環境で解決できればクロージャだよ。
この場合は変数nのことね。
294 :
2014/12/17(水) 23:03:51.76 ID:dyHF3Jr0
>>286
レキシカルクロージャってSchemeが最初だと思うけど、
Schemeって純粋な関数型言語じゃないよね。
295 :
2014/12/17(水) 23:50:33.95 ID:JUumI3zm
>>291
お題に対して「Python だけがわざわざ関数 applyf をユーザ定義しなければならない」ことを問題視している
>>201 のコードは「お題を(勝手に改変せず)インラインで書ける」という観点だと(評価以前に)失格だ

もしも Python コミュニティにおいて関数 applyf が常識的に認知されていたならば、
(map/filter/reduce 等と同様に) applyf は組み込み関数として実装されていたはず
なお、組込み関数の実装レベルは言語によって差異があるものだから、
公平性を考慮して functools のような標準ライブラリを import するのは認める

また Ruby のメソッド Enumerable#inject に対応する Python の関数は reduce だよ
Python で組込み関数 reduce を使うのは、まったく問題無い
296 :
2014/12/17(水) 23:55:13.45 ID:dyHF3Jr0
ていうか、さらっと1個の式で書けないような処理はインラインに書こうとするなよ
っていうのがpythonの求めるところなんじゃないの?
297 :
2014/12/18(木) 00:12:23.41 ID:SaitqfQN
>>201 はインラインでは書けていないけど、>>205 と比べれば可読性の高いコードであると思うから、
>>291 の主張を受け入れて >>288 を以下のように一部改訂する(* で始まる行を変更している)

改定前:
 ・高階関数 map に与えるクロージャをインラインで書ける
   [Python:X]
   ・インラインでは関数再帰を使った可読性の低いコードになってしまう(>>205)
*  ・このため、一般には(インラインで書くのはあきらめて)関数定義を使わざるをえない
 ・参照透明性のある関数型プログラミングで書ける
*  [Python:X] 関数再帰で書けるが、可読性の低いコードになってしまう(>>205)

改訂後:
 ・高階関数 map に与えるクロージャをインラインで書ける
   [Python:X]
   ・インラインでは関数再帰を使った可読性の低いコードになってしまう(>>205)
*  ・このため、一般には(インラインで書くのはあきらめて)関数定義または変数宣言(>>201)を使わざるをえない
 ・参照透明性のある関数型プログラミングで書ける
*  [Python:X] 関数再帰で書けるが、可読性の低いコードになってしまう(>>201,205)
298 :
2014/12/18(木) 00:16:28.27 ID:5LPNbvYA
むしろ標準で用意されてなくてもユーザ定義で拡張できるのは
言語として筋が良いといえる
299 :
2014/12/18(木) 00:18:19.46 ID:wQzGbOYd
謎の標準ライブラリ縛りが入りましたw
300 :
2014/12/18(木) 00:22:42.78 ID:Xu+bpXu3
1個の式で済む以上の事をやろうとする処理に名前を付ける事が、なぜ可読性の低下につながるの?
301 :
2014/12/18(木) 00:29:24.93 ID:wQzGbOYd
再帰は可読性低いって連呼しててワロタ
Rubyユーザって、ブロック使ってるだけで関数型だと思ってるの?
302 :
2014/12/18(木) 00:35:38.77 ID:Xu+bpXu3
Schemeは普通ならループで済むような事まで再帰で書くぜ
303 :
2014/12/18(木) 00:44:04.09 ID:4kRgXtNb
再帰よりnamed let使おう
304 :
2014/12/18(木) 00:52:42.96 ID:Xu+bpXu3
named let は再帰でしょ?
305 :
2014/12/18(木) 01:28:37.32 ID:4kRgXtNb
書いた後に思った
306 :
2014/12/18(木) 08:20:12.81 ID:ETi/Ct7F
>>301
彼だけだよ
307 :
2014/12/18(木) 08:27:40.63 ID:9iQd+rLQ
lispおじさんに言わせれば
全部lispのパクりだから
全部クロージャで問題ないよ
308 :
2014/12/18(木) 09:21:04.09 ID:f+DPSsFx
なんでクロージャスレでClojureを話題にしないの?
309 :
2014/12/18(木) 09:50:43.10 ID:ZOTu6c+H
>>308
若いときは買ってでもするものなあ〜んだ?
310 :
2014/12/18(木) 12:49:08.51 ID:nVA5J83n
>>309
ゲーム
311 :
2014/12/18(木) 19:41:50.11 ID:5ReW54RD
>>189
流れをナナメ読みかつ関数型言語素人なんだけど、
関数型言語だとそのアップルサイトの例はどういうふうに書くもんなの?

let digitNames = [0,"Zero"; 1,"One"; 2,"Two"; 3,"Three"; 4,"Four"; 5,"Five"; 6,"Six"; 7,"Seven"; 8,"Eight"; 9,"Nine"];;
let numbers = [16; 58; 510; 0];;
let strings = List.map (fun n ->
let rec f n acc =
match (n, n / 10) with
(0, 0) -> List.assoc 0 digitNames
| (_, 0) -> List.assoc (n mod 10) digitNames ^ acc
| (_, _) -> f (n / 10) (List.assoc (n mod 10) digitNames ^ acc)
in f n "") numbers;;
List.iter (fun s -> print_endline s) strings;;

言語はOCaml。三つの変数名はオリジナル版を採用。
dictionaryは諸事情でめんどいのでタプルのリストで代用。
関数型言語のことはまったくわからないw
312 :
2014/12/18(木) 22:22:25.63 ID:2b1ZQukZ
>>309
SEX
313 :
2014/12/18(木) 23:09:02.06 ID:SaitqfQN
>>311
Standard ML で素直に末尾再帰を使って書いてみた
 http://ideone.com/WpChMC
314 :
2014/12/19(金) 00:07:27.38 ID:lMWP4GlC
>>313
おおっ!わざわざどうも!
SMLとOCamlの関係だからこういう似たような感じになるのかな?
それともループを再帰に置き換えたらどうせどの言語でもこんな感じかな?

それにしても関数型言語なるものを知るにつれて思うのは、
再帰についてはすがすがしいが、
それ以外についてはタイプ量が増えがちってこと。
ハッシュテーブルひとつ準備するのにもウダウダ。
関数型どうのというより、個別の言語によるのかもしれないけど…。
315 :
2014/12/20(土) 00:24:39.20 ID:0cpPf2uS
>>314
>SMLとOCamlの関係だからこういう似たような感じになるのかな?

SML も OCaml も同じML族の一員ですから、そんな感じになるのも不思議じゃないと思いますね

>それともループを再帰に置き換えたらどうせどの言語でもこんな感じかな?

SML 以外の関数型言語は触った程度のレベルなので、以下はあくまで私見です:
・Lisp でも似た感じの再帰になる
 ただし Lisp は TCO が保証されていないから、一般的な反復処理であれば
 loop や while マクロ(または、その相当品)で手続き的なループで書く
・Scheme は TCO が言語仕様で保証されているので、普通は再帰で書く(>>302)
 また継続(call/cc)があるので、loop や while の相当品を関数として自前で定義することも可能
・Haskell の場合、初めのうちは(ML や Scheme と同様に)再帰で書く
 ただし Haskell だと文字列は文字型のリストであり、標準ライブラリの unfoldl を使う事を学ぶようになる
 ・関数プログラミングの楽しみ
  http://www.amazon.co.jp//dp/4274068056
  第3章「おりがみプログラミング」で詳しく解説されています
ということで Haskell の定義を参考にして、SML でも関数 unfoldl で再帰を抽象化したコードを書きました:
 http://ideone.com/o5JM86
ここで unfold とは、よく知られている fold の双対な概念です
(fold は、Ruby だと inject、Lisp や JavaScript では reduce と呼ばれています)
fold xs が「あるリスト xs を畳んだ値 y」を返すのに対し、
unfold y は「ある値 y を広げたリスト xs」を返します
なお、「畳む/広げる」という言葉よりも「分解する(destruct)/組立てる(construct)」のほうが直感的かもしれません

(* 長いので、続く *)
316 :
2014/12/20(土) 00:32:09.09 ID:0cpPf2uS
(* >>315 の続き *)

なお、map や filter といった高階関数を一般化したものが fold であることは
よく知られていますが、ここでリストを代数(群)に見立てた圏論の視点で再構成すると:
・fold を(更に)一般化したものがカタモルフィズム(catamorphism)である
・unfold を(更に)一般化したものがアナモルフィズム(anamorphism)である
という、本質的な形でリスト処理を定義できるようになります
(モナドとは関連しない)圏論を応用したプログラミングについては、以下のプレゼンがお薦めです
・Introduction to Categorical Programming (Revised)
 http://www.slideshare.net/sakai/introduction-to-categorical-programming-revised
 p.18 の図式を使った「圏論でのリスト型の定義」が直感的です
詳細については、以下の記事で紹介されている論文(英語)が分かりやすかったです
・Haskellと圏論を学んできて、そのまとめとしてちょうどよい論文を見つけたのでメモ。
 https://plus.google.com/+OsamuNagano/posts/7cPfAQ145Yi

>それにしても関数型言語なるものを知るにつれて思うのは、....

ML や Haskell は静的型付けによる安全性と高速化を主眼に設計された言語ですから、
Ruby や Python といったスクリプト言語の置き換えには成り得ないと考えます
これに関しては、以前に別スレ「LLにおける関数型プログラミング」で説明しています
 http://peace.2ch.net/test/read.cgi/tech/1345123070/28
また ML や Haskell の強力な型推論は、データ型に関する矛盾(=バグ)が存在しないことを(実行の前に)証明しますが、
動かしては書き直す(いわゆるトライ&エラー)が一般的なスクリプトプログラミングには不向きだと考えます

(* これで終わり *)
317 :
2014/12/20(土) 07:17:42.63 ID:tzPxF8Oh
長い
3行でまとめろ
318 :
2014/12/20(土) 12:12:13.43 ID:PEBuGla8
珍しく普通に相手にしてもらって
うれしくてたまらない
オレオレクロージャくんであった
319 :
2014/12/20(土) 16:08:48.96 ID:5dXZUu33
>>315-316
> Lisp は TCO が保証されていないから

TCOが保証されての末尾再帰。何がすがすがしいって、これですよね。
これがあるから書いていける。
保証なしで気軽に再帰なんかしてもスタックオーバーフローでげんなりだし。

> Haskell だと文字列は文字型のリストであり、標準ライブラリの unfoldl を

おったまげですね。初めてunfoldなるもんを知りました。
Rubyでinject、OCamlでfold_left/fold_rightは馴染みがあったんですが。
何かHaskellって…グイグイ来てますよね!(小学生並みの感想)。

> cata, ana, 圏論, 圏論でのリスト型の定義

リンク先拝見しましたが現時点でどうも1ミリも理解できていません。半笑いです。

> http://ideone.com/o5JM86

ありがとうございます。よく考えると37行目の「 ^ output」が不要にも見えますね。
320 :
2014/12/20(土) 16:23:01.32 ID:a9XjC0LN
源クロウジャ義経
321 :
2014/12/20(土) 19:01:20.98 ID:tzPxF8Oh
>>318
分かりやすいですー
322 :
2014/12/21(日) 00:04:04.16 ID:YWufr8fT
>>319
>よく考えると37行目の「 ^ output」が不要にも見えますね。

バグ指摘ありがとうございます、変数 output そのものが不要でした
対策を以下へ反映し、ついでに Ruby と Python でも unfold を使って書いてみました
・Standard ML
 http://ideone.com/3L6yJ0
・Ruby
 http://ideone.com/4OzC0s
・Python
 http://ideone.com/8TouzI


>おったまげですね。初めてunfoldなるもんを知りました。

「unfold は fold の双対な概念」であることを知れば、応用範囲は広がります
今回は文字列の unfold でしたが、リスト/配列/辞書/集合/スタック/キューといった
「コレクション・オブジェクトにおける fold/unfold」を考えることから始めませう
323 :
2014/12/21(日) 09:15:25.48 ID:KrmABo99
TCO無くて正格評価なPythonでは
unfoldはループ&ジェネレータで実装した方が良いね
それと文字列に限定する意味って無いよね

http://ideone.com/e1fKAL
324 :
2014/12/21(日) 16:48:41.14 ID:MvQSKDIW
この話題クロージャとか特に関係なく、Pythonの無名関数には文を書けず式しか書けないという単純な事実の指摘でOK?
関数型プログラミングのラムダとしては困らないが、手続き型言語における無名関数としては不便だろうな
自分はPythonを使わないので、Pythonでの「普通の」プログラミングスタイルがどっちなのかは知らん
325 :
2014/12/21(日) 17:05:17.75 ID:MvQSKDIW
Hackで適当に書いてみたら本体は一行だった。PHPの緩さにラムダ加わるの最強

$strings = array_map($n ==> array_reduce(str_split($n), ($s, $d) ==> $s . $digitNames[$d]), $numbers);
326 :
2014/12/21(日) 17:15:45.30 ID:KrmABo99
そんなので良ければPythonでも一行

strings = [''.join(digitNames[x] for x in str(n)) for n in numbers]
327 :
2014/12/21(日) 17:21:26.20 ID:MvQSKDIW
あれ、それdigitNames[x]のxに文字列で渡ると思うけど、Pythonも勝手に数値に変換してくれるんだっけ?
整数に変換してやらないと駄目な記憶があっていちいち面倒くさいと思ってた
328 :
2014/12/21(日) 18:11:16.63 ID:axFrURca
digitnames = { "0": "Zero" ... } なら>>327
digitnames = { 0: "Zero" ... } なら digitNames[int(x)]になるだけだろ。

Perlなら
my @string = map{ join '', @digit_names{split //, $_} } @numbers;

Javascriptなら
var strings = numbers.map(function(number) {
return number.toString().split("").map(function(x) { return digitNames[x] }).join("");
});

Javascriptはアロー演算子が欲しいところだ。
329 :
2014/12/21(日) 18:21:39.18 ID:MvQSKDIW
最強言ったから気に食わなかったならスマンカッタ

PHPの緩さは、こういうのが動くところ。>>325でそのまま動く
$digitNames = ['Zero','One','Two','Three','Four','Five','Six','Seven','Eight','Nine','.'=>'Point','-'=>'Minus'];
$numbers = [1.234, -5.4321];
330 :
2014/12/21(日) 23:04:35.55 ID:YWufr8fT
>>323
>>322 と比較すると:
・わざわざジェネレータで「組立てた」シーケンスを
 reduce で「畳み込んで」いて、二重のループになっているから処理効率(=性能)が悪く、
 なおかつ reduce へ渡すラムダ式が増えているからコードも複雑化してしまっている
・そもそも「Haskell の unfold 定義」に従って関数定義していないから
 その関数の命名 unfold は不適切であり、別の名前を考案すべき
 念の為に「Haskell の unfold 定義」を以下に示す(ただし末尾再帰ではなく一般再帰):
  unfold :: (B -> Maybe (A, B)) -> B -> [A]
  unfold f u = case f u of
          Nothing -> []
          Just (x, v) -> x : (unfold f v)
この「Haskell の unfold 定義」に従った unfold の Python 実装を以下に書いた:
  http://ideone.com/vpTBlR
  ・__unfoldl_string_rec__:一般再帰による実装(>>322 と同じ)
  ・__unfoldl_string_while__:while 文と破壊的代入を使った手続き型実装

あわせて Ruby の実装コードも更新した:
  http://ideone.com/9x6s0h
コードの要点を示す:
・Python のジェネレータを Ruby では外部イテレータ Enumerator と呼ぶが、
 (Ruby 1.9 以降のメソッド定義マナーに従い)ブロックが渡されていない場合には
 (組込みメソッド Object#to_enum を使って)外部イテレータを返すようにした
・3種類のメソッド定義を示した
 ・String#__unfoldl_rec__:一般再帰による実装(>>322 と同じ)
 ・String#__unfoldl_until__:until 文と破壊的代入を使った手続き型実装
 ・String#__unfoldl_loop__:メソッド loop を使った参照透明性のある関数型実装(>>264

最後に、Ruby と同様な「Haskell の unfold 定義」に従った
Python のジェネレータ実装については、>>323 への宿題としておく
(ML や Haskell といった静的型付け関数型言語に慣れていないと、難しいかもしれないが....)
331 :
2014/12/22(月) 08:52:28.54 ID:6avCYBJ9
Pythonの場合リストを返したかったら list(unfold(f, x)) で良くね?
毎回 s += a 等やって組み立てるよりも速いぞ
332 :
2014/12/22(月) 09:03:18.85 ID:6avCYBJ9
あ、もしかしてunfoldlじゃないからダメって言ってんの?
unfoldには unfoldr と unfoldl の二種類あって、HaskellではPreludeにあるのはunfoldrだけだぞ
333 :
2014/12/22(月) 09:04:46.38 ID:6avCYBJ9
ちなみに>>330が自信満々に貼ってる方のHaskellのunfoldの定義はunfoldrの方なw
334 :
2014/12/22(月) 09:07:58.19 ID:ZCDWZl5G
unfold :: (B -> Maybe (A, B)) -> B -> [A]
じゃないから駄目とか言っといて、なんで出してる実装はことごとく
unfold :: (B -> Maybe (A, B)) -> B -> A
なの? バカなの?
335 :
2014/12/22(月) 14:26:58.64 ID:51sTiTTJ
またオレオレ定義君がやらかしちゃったかー
336 :
2014/12/22(月) 21:08:27.40 ID:8h2AGQmm
cにクロージャくれよっておもってたけど
今ならgoがあるんだよな
337 :
2014/12/22(月) 21:10:47.28 ID:VRBNRD9f
C++使ったら?スコープ抜けた際どうなるか、必要ならコピーを持たせよう、とかスマポにするかーとか、考える必要はあるけど
338 :
2014/12/22(月) 21:16:46.96 ID:6skO2mFq
>>336
clangならblocksが使えるんじゃないかしら
339 :
2014/12/23(火) 06:28:08.32 ID:pszL50YR
ほー objc じゃなくても使えるのか。
まあ objc に c のソースだけ食わせて使ってもいいんだけど。
340 :
2014/12/23(火) 11:28:17.27 ID:St4HMSPr
boost lambdaで怖い思いしたから
c++はng
コンパイルエラーから黒魔術なコード出されてもこまる
341 :
2014/12/23(火) 11:30:55.43 ID:0dLhalMI
そういうのはreplで対話的に書けたほうがいいな
342 :
2014/12/23(火) 14:09:04.60 ID:Og1JN7U7
このスレのおかげでクロージャの良さと
Ruby信者のキモさが分かりました
ありがとうございました
343 :
2014/12/27(土) 00:25:14.89 ID:randw1SU
クロージャなんて最近の言語は大抵あるからね
次に関数型言語からパクって欲しいのはパターンマッチ
344 :
2014/12/29(月) 07:25:36.12 ID:Br8mMuyh
disると公開される
345 :
2014/12/29(月) 16:50:56.24 ID:9aAL2Pj2
まぁ別にいらないっちゃいらないな。
最近の言語はいろいろ付けすぎだわ。
もっと仕様単純でいいよ。
346 :
2014/12/29(月) 17:19:30.86 ID:LxjJzYoX
パターンマッチの無い言語にパターンマッチを付けられるような言語がいい
347 :
2014/12/29(月) 19:45:55.93 ID:NKff8BVB
>>346
プリプロセッサを使えば、どんな言語でも
なんだって出来るんじゃね?
348 :
2014/12/30(火) 17:09:02.43 ID:AU/nggqJ
その万能プリプロセッサがあればいいんだけど
349 :
2014/12/30(火) 18:06:56.67 ID:mxKZGqd3
m4通すとか?
350 :
2014/12/30(火) 18:40:21.70 ID:AU/nggqJ
その言語処理系を書かた言語のコードを直接書き変えるような書き方じゃなくて
その言語自体で新しい表現(パターンマッチとか)を定義出来るようにするってこと
351 :
2014/12/30(火) 19:32:00.99 ID:tU/2zS2Z
>>346
lispおじさんだ!
352 :
2014/12/30(火) 20:40:47.63 ID:LKC757rT
lispでマクロ使えばおk
353 :
2014/12/31(水) 23:19:03.80 ID:tqgvohnx
>>350
たぶんschemeにドハマリするタイプ
354 :
2015/01/01(木) 00:15:11.77 ID:6s4ScpeL
on lispとかlet over lambdaがあるcommon lispの方がいいんじゃね
355 :
2015/01/01(木) 08:49:44.48 ID:Vz2QaCIS
あなほりマクロ怖い
356 :
2015/01/01(木) 19:26:59.51 ID:LWrX8qsS
やっぱりpythonとかhaskellのコードと比べると
専用の構文があった方がスッキリ書ける
でもそうすると自由度が無くなってマクロがうまく使えないジレンマ
357 :
2015/01/01(木) 19:31:53.89 ID:LWrX8qsS
一応リーダマクロを使えば解決するんだけど結局使わなくなる
358 :
2015/01/02(金) 09:58:20.63 ID:ie8IusfS
lispおじさんのせいで
すっかりマクロ談義スレになったな
359 :
2015/01/02(金) 10:14:10.05 ID:PL75YfkA
真のクロージャとマクロ、どっちがマシか難しいところだな
360 :
2015/01/02(金) 11:28:56.61 ID:Ur5QsT6D
二つのいいところを組み合わせたものが最強ではないだろうか?

つまりマクロージャー
361 :
2015/01/02(金) 12:10:26.52 ID:ie8IusfS
マクロにコンテクストが付いて回るclの事だよねそれ
362 :
2015/01/02(金) 15:30:32.04 ID:/upm+g4t
マクロとクロージャを組み合わせればOOPも継続も後から付けられる
363 :
2015/01/02(金) 15:37:48.79 ID:Ur5QsT6D
いろんなことができる。そうマクロージャならね!
364 :
2015/01/02(金) 20:00:41.84 ID:ZuY3pBgY
>>362
継続渡しではないですよね?
マクロとクロージャーで継続をどう実装するか
ぱっとは思いつかなかったのでよかったら教えてください。
365 :
2015/01/02(金) 20:28:34.80 ID:UWr+Udi0
onlispでは継続を表わすクロージャを引数で渡してそれをマクロで包んでる
これだと使う側が末尾呼出的に書かないといけない縛りがある
cl-contは式をwithマクロで包んでその式をcodewalkしてcps変換してる
366 :
2015/01/02(金) 21:04:50.09 ID:ZuY3pBgY
ありがとうございます。On Lisp 読んでみます。
367 :
2015/01/09(金) 13:33:15.35 ID:3m5OEfmN
そもそも関数が一級オブジェクトである必要があるのかどうか疑問が出てきました
ifelse( aaa, xxx,
ifelse( bbb, yyy,
ifelse( ccc, zzz,
      iii )))
       ↑死ね
IDE使えってことなんでしょうけど認知に負荷をかける言語仕様は間違ってると思うんですよね
これよりはメソッドチェーンの方がかなりスマートだと思う
foo(aaa){xxx}.bar(bbb){yyyy}.baz(ccc){zzz}
368 :
2015/01/11(日) 21:16:33.98 ID:8HLn7hr5
それだと全てのメソッドで条件分岐を想定した実装にしなくちゃいけなくなるのでは
369 :
2015/01/16(金) 01:40:03.14 ID:U7RTYgR7
Pythonはパターンマッチ以前にSwichtすらない
370 :
2015/01/16(金) 08:39:36.86 ID:oLGQ6wLb
>>369
そんなもんがある言語を見たことないが
371 :
2015/01/16(金) 23:23:44.50 ID:obgM8cFp
なんかドイツ語?みたいな切り方だな
372 :
2015/01/21(水) 16:33:15.48 ID:Out9u5nx
ゲルマンおじさんこわい!
373 :
2015/01/22(木) 01:37:45.45 ID:8pwMw7VT
スウィヒトとか読むの?ドイツ語ってよくわからんタイミングで濁るイメージあ?からジットとかかな
374 :
2015/01/22(木) 08:08:05.98 ID:VatMjg6z
スヴィヒトだな、あえてカタカナを当てれば
375 :
2015/01/24(土) 00:56:47.04 ID:hSO7J5Oj
中二病みたい
376 :
2015/01/27(火) 21:37:55.87 ID:x1TLH4fz
ここまでnonlocalなし
377 :
2016/01/10(日) 19:01:54.47 ID:sdj7zt3O
Objective-Cのblocksが便利だというからいろいろ読んでみたが
使い道がよーわからん。他言語のクロージャやラムダだということで
他言語のクロージャやラムダについて読んでたらもっと混迷が深まった。
378 :
デフォルトの名無しさん
2016/03/29(火) 09:21:36.23 ID:/c8bAcK4
サッカーブッシュ日本代表日程ぷあたん(しゅっちょうまいくろ教育長交代)春文執行40代売上差額シュガーチョコ
https://www.youtube.com/watch?v=NDq1QoJY0nY宇ドナルドアナリストパワーストーンコーチングとしまえん
サッカーブッシュ日本代表日程古本屋よしたけしゅっちょうちょこしゅがー
ディーラー税務署天才開発者死亡詰みヨミドクターマイクロサービス不足
サッカーブッシュ日本代表日程ぷあたんシフト光金さかい強制バイト人権侵害問題
春分資源執行ニューヨーク低原価ぼったステーキソルトレイク福岡横浜新橋奴隷課金パチシフト強制バイト問題新潟米センター生残
コスメ24チャリティー隠れ40代生活保護プレイボーイバイトレードいたりあん接待問題
マスコミKARDローンケーオーサービス不足婚活パーティー寄付金執行原発ビジネス
FBIチャイニーズタイホテル売上事務所ガチャ決算ガチャキャンペーン(販売報道陣過激派組織向携帯最新情報提供終了
校長発言細心注意ノートン産廃エラー(著作権クレーム中国反応融資高額教育費)(中国捕鯨団体40代社員サッカーコメント
高額入学金ヤフウ新橋大学ヤフウ新橋理事長FX経費 おじや50代資産ガリバズフィード40代エリート
379 :
デフォルトの名無しさん
2016/05/01(日) 14:33:24.76 ID:tKi6j9CT
匿名通信(Tor、i2p等)ができるファイル共有ソフトBitComet(ビットコメット)みたいな、
BitTorrentがオープンソースで開発されています

言語は何でも大丈夫だそうなので、P2P書きたい!って人居ませんか?

Covenantの作者(Lyrise)がそういう人と話したいそうなので、よろしければツイートお願いします
https://twitter.com/Lyrise_al

ちなみにオイラはCovenantの完成が待ち遠しいプログラミングできないアスペルガーw


The Covenant Project
概要

Covenantは、純粋P2Pのファイル共有ソフトです

目的

インターネットにおける権力による抑圧を排除することが最終的な目標です。 そのためにCovenantでは、中央に依存しない、高効率で検索能力の高いファイル共有の機能をユーザーに提供します

特徴

Covenant = Bittorrent + Abstract Network + DHT + (Search = WoT + PoW)

接続は抽象化されているので、I2P, Tor, TCP, Proxy, その他を利用可能です
DHTにはKademlia + コネクションプールを使用します
UPnPによってポートを解放することができますが、Port0でも利用可能です(接続数は少なくなります)
検索リクエスト、アップロード、ダウンロードなどのすべての通信はDHT的に分散され、特定のサーバーに依存しません
186KB

新着レスの表示

★スマホ版★■掲示板に戻る■全部前100次100最新50

名前:E-mail: