ludy 0.0.4 released

花了一點時間再測試了一下 curry 的實做，i am glad to announce that ludy 0.0.4 is released. 原本的 Proc#curry 被改名為 Proc#__curry__, 我很想把他
deprecate 掉，但是後來的 Kernel#curry 也有運用到該實做，是有在考慮把他從 public 改到 private, 但考慮到也許還有用處，還是暫時放在 public 下，以後如果發現真的沒用了，會改到 private 下。

現在的用法是：

multiply = lambda{|l,r| l*r}

double = multiply.curry[2]
assert_equal 8, double[4]
assert_equal 6, double[3]

xd = multiply['XD', 5]
assert_equal 'XDXDXDXDXD', xd

assert_equal 29, :+.to_proc.curry[18][11]
assert_equal (0..4).to_a, lambda{|a,b,c,d,e|[a,b,c,d,e]}.curry[0][1][2][3][4]

只要呼叫到了 Kernel#curry, 且 caller 本身回應（respond_to?）:call 和 :[], 則回傳一個 curry function, 這樣就可以有更強的 consistency, 不需要注意什麼時候使用 () 而什麼時候使用 [], 請一律使用 function call/[], 不用擔心參數是否足夠，足夠時就會回傳真正的答案，否則再度傳回 curry function.

所以其實我是在想，以下兩者是否相同？
class Array; include Curry; end
func1 = [].cfoldr
func2 = [].method(:foldr).curry
func1 == func2 # => true? or false?

我的希望是相同，當然。只是我直接換上這樣的實做似乎有點問題，這個狀況可能在 0.0.5 中解決，使 curry module 和 kernel#curry 也能夠擁有該有的一致性。

另一個棘手問題是 ruby 的 block, 乍看很好用，實際上也是，但是卻造成了很大的不一致。這一點也真的是很難搞定，之前的 this 就有碰上這樣的大問題，使用 yield 似乎無法產生正確的 call stack.

*

最後則是 0.0.4 上的實做問題，由於 :*.to_proc 的這個 proc 無法預測其正確的 arity, 就像 :message_that_you_never_know.to_proc 也不可能能知道他的 arity 是多少一樣，這造成了難以判斷何時該回傳正確的值而非另一個 curry function. 我是想要從 Symbol#to_proc 去竄改，不過這會碰上另外兩個問題：

1. 會跟其他人的實做衝突
2. caller 和 arity 是合併在一起的，意味還沒 call 之前都不會知道 arity, 這樣我就沒辦法強迫 Symbol#to_proc 能產生正確的 arity.

所以我只好用另外一個很愚蠢的方式：trial & error.
begin # let's try if arguments are ready
  self.__send__ :orig_call, *args, &block
rescue ArgumentError # oops, let's curry it
  method(:call).to_proc.__send__ :__curry__, *args
end

效率問題就別提了，我真的覺得這樣很蠢，可是好像也想不到更好的方式。

所以 0.0.4 就只暫時強化了 curry 的實做，離完善還有很大的一段距離。雖然心血來潮度極高，但好像還算有進展？

gem install ludy
to see detail.