Well, that didn't take long. Although I sadly can not read
Japanese, from this:
···
Thu Oct 30 02:46:35 2003 Yukihiro Matsumoto <matz@ruby-lang.org>
* eval.c (proc_invoke): single array value to normal Proc#call
(i.e. not via lambda call), should be treated just like yield.
[ruby-dev:21726]
http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-dev/21726
...it appears that yield was broken and so it was decided to break
Proc#call to match it, rather than fixing yield. It appears that that
was done by adding the following:
from eval.c near line 7175:
pcall = data->flags & BLOCK_LAMBDA ? YIELD_PROC_CALL : 0;
if (!pcall && RARRAY(args)->len == 1) {
avalue = Qfalse;
args = RARRAY(args)->ptr[0];
}
(NOTE: I do not claim to be C programmer, and this is just is just a
preliminary exploration).
I will admit, having just spent six months full time getting 14,000
lines of code in ruby 1.8.0 to validate against a legacy code test
suite, including several out of state trips for multi-day meeting to
justify the validation process, etc. I a tad worried that what I had
thought would be a week or so of re-running the tests on 1.8.1 & 1.8.2
is looking like something that will be much, much worse.
Ok, not a tad worried. Near panic maybe?
I can of course back the change out (hurray for open source!) but
that would mean a fork forever more, or having my successors repatch
each new version for the rest of time--neither of which I care for. So:
* Is there anyone who reads Japanese or who is aware of any
discussion of this point in english that can point out to me if
I am looking at things incorrectly?
* Is it too late to argue against this change?
* It goes against POLS, since 1) adding an argument to an
argument list can _reduce_ the number of arguments seen
by the Proc, 2) adding or removing one argument can
change the class of another argument, 3) it makes it
impossible (so far as I can see) to write iterators that
process nested arrays in a reasonable fashion.
* It breaks a design pattern (head,*rest) with a forty
year history which is used in a great quantity of
published literature, including the heritage of lisp,
prolog, smalltalk, etc.
* If changed back, anyone wanting the "new" behavior could
get it by simply placing an "*" before the parameter
passed in
* If NOT changed, it is not at all clear how the behavior
could be cleanly worked around
* If I am too late to this debate, is there anyway that this could
be made conditional, e.g. by putting a flag on the Proc, or
adding a global setting or...? I would want something that was
within the ruby code, rather than something that affected the
compilation of ruby (e.g. a compilation/configuration option)
because having multiple versions of ruby floating around with
different semantics is dangerous.
I am willing to do the work on this, but I will need someone to vet
my C, and could use some guidance as to the best route to proceed.
-- Markus