Unless I hear otherwise, I plan on freezing RFC 204 and RFC 206 this
evening (17:30 New York time), and issue a revised version of 207. The
frozen versions will be substantially identical to the versions ow
released.
On RFC 204 (LOL refs as indices), I have followed the discussion from
Ilya that list references will have problems when objects that used
blessed references to lists as their internal representation are used
as indices. This does indeed seem to be a problem, but I'm uncertain
how big of a problem.
Would it help if the RFC stated that the index had to be either a
scalar integer or an ARRAY ref of integers? Since objects would be
blessed as something other than ARRAY, they would need to be converted
first. If it was an object, it would try to call standard methods to
convert to a scalar integer, a list of integers, or an ARRAY ref of
integers. Just an idea.
I will include Ilya's objections (and a more formal version of the
above suggestion) in a "Summary of Discussion" section.
On RFC 206 (@#arr as bounds-fetcher), I have not really heard any
substantive comments, but most of what I've heard is positive. Please
point out to me anything I may have missed.
I will freeze 206 as-is, unless someone has something to add.
On RFC 207 (efficient array loops), based on discusion and additional
thought on my part, I want to clarify and change the syntax used in the
RFC. I also want to go into more detail about how the scope of the
efficient array loops is derived.
Here is a summary of changes:
1) Replace use of |i as a "list-like" expression to use of |i as a
"scalar-like" expression. This would prefer syntax like:
@newarray = $a[|i]*$b[|j];
over
@newarray = @a[|i]*@b[|j];
I originally viewed |i as being syntactically a replacement for a range
(0..$max), but I think that view is potentially confusing.
2) In v1, iterators converted the minimal expression containing all
iterators in a statement into a loop (or nested loops). This
unfortunately led to such clumsiness as:
{my @temp; $temp[|i] = dotproduct += $a[|i]*$b[|i];} # Not DWIMish
where it isn't clear why the @temp needs to be created and destroyed.
The RFC also required the creation of a potentially huge
multidimensional array even if such an array would then simply be
thrown away. Worse, in the "dotproduct" example above, both the
implicit array and the @temp array would be created and destroyed for
no good reason.
v2 will have iterator scope and implicit array creation dependant on
context:
Starting with the minimal expression containing all iterators in a
statement:
a) If the expression is in list context, generate an implicit temporary
array.
b) If the expression is in void context, do not generate an implicit
temporary array
c) If the expression is in any other context (scalar, lvalue, etc)
expand the expression to the minimal proper superexpression (i.e., go
up one level on the parse tree) until you have list or void context.
That would make
dotproduct += $a[|i]*$b[|i];
Do The Right Thing.
I would also state that although some of the examples used can be
better done under RFC 82, this RFC is not intended to compete with RFC
82. RFC207 and RFC82 provide two different sets of functionality that
partially overlap.
Comments? Criticism? Complaints?
Later,
Buddha
--
Buddha Buck [EMAIL PROTECTED]
"Just as the strength of the Internet is chaos, so the strength of our
liberty depends upon the chaos and cacophony of the unfettered speech
the First Amendment protects." -- A.L.A. v. U.S. Dept. of Justice
