[心得] ludy 0.0.4 released
edited:
gem install ludy
to see detail.
花了一點時間再測試了一下 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 的實做，離完善還有很大的一段距離。
雖然心血來潮度極高，但好像還算有進展？
--
By Gamers, For Gamers - from the past Interplay
--
※ 發信站: 批踢踢實業坊(ptt.cc)
◆ From: 220.135.28.18
※ 編輯: godfat 來自: 220.135.28.18 (08/13 01:04)
Ruby 近期熱門文章
PTT數位生活區 即時熱門文章
