Duck-language
Duck-language copied to clipboard
Closure class may cause unreliable behavior
The Closure class relies heavily on Ruby's Proc#curry
function to create partially applied functions. This works well for functions of simple arguments, such as arithmetic, where for instance the duck int(5)
responds to the message :+
by producing a Closure representing the partial application of addition, 5+?
. The Ruby code involved uses Proc#curry
to create this result.
The problem is that Ruby's Proc#curry
creates a Binding instance that's associated with the arguments passed in, and that Binding includes links to the arguments by reference.
In the case of 5+?
, the integer value 5
is immutable; we've got no problem. The 5
is the 5
forever.
In the case of (1, 2, 3) + ?
, which in my shorthand represents a Duck List
looking for another List
to concatenate with, the link by ref to the argument means that if some other event changes it, we can get into trouble.
Now I've been careful to treat arguments as immutable. But there are obviously some mysterious problems floating around in the mix still, because random stress-testing eventually (but rarely) creates a Closure that causes a Ruby error.
The obvious solution is to re-write the Closure class so that it doesn't rely on Binding objects.
Until then, expect arbitrary (and nigh undetectable) errors to crop up from time to time.