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.


Reply via email to