花了一點時間再測試了一下 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.
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.