Notice of intent to freeze RFCs 204, 206, and revise 207

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                             bmbuck@14850.com
"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

• Notice of intent to freeze RFCs 204, 206, and revise 207 by Buddha Buck
• Re: Notice of intent to freeze RFCs 204, 206, and revise 207 by Jeremy Howard