On Fri, May 06, 2005 at 10:45:57AM -0600, Luke Palmer wrote: : On 5/6/05, Juerd <[EMAIL PROTECTED]> wrote: : > When piping to a scalar, I assume its reftype will determine what will : > happen. But what if the scalar is undef? Is it then assumed to want to : > behave like an array? : : If you're piping into a scalar without parens, I think it should : always become an array ref.
I think it would be more general to return an iterator or some kind of "promise", insofar as it doesn't commit to storing the values, but merely to returning them in the order produced. You can always use $foo for the other meaning. Alternately, we could make =$foo an lvalue, but ==> =$foo is a bit strange, and people will think it means to write to filehandle $foo. Or we could force people to say something evil like ==> my $foo is Iterator. I guess the real question is whether ==> my $x is really assigning a list or binding an iterator to a Lazy slot somewhere. It feels like the latter is more useful. Which means that ==> @x can return as soon as it binds the iterator to @x.specs. It doesn't have to wait for all the values to be produced, which an assignment implies (kinda sorta). Which, if we continue with () as an explicit pipe target, ==> @x = () would force assignment semantics. Alternately we could assume assignment and force binding with ==> @x := (). Just depends on how lazy we want to be by default, I guess. I don't have a good feeling for how to answer that. I guess you want to be as lazy as possible without getting into trouble. Larry