> >Should be part of the want() context.
>
> It is. I interpreted Damian's remark to mean that it would be good if
> readline() took advantage of it, and that should be RFC'ed.
That's indeed precisely what I meant. In fact, all list-returning built-ins
ought to be optimized this wa
In message <[EMAIL PROTECTED]>
Nathan Torkington <[EMAIL PROTECTED]> wrote:
> Peter Scott writes:
> > >> ($a, $b, $c) = ;
> > >> or
> > >> @a[4,1,5] = ;
> > >> only read three lines?
> > >
> > >I think this is a superb idea, and look forward to someone's RFC'ing
Jeremy Howard wrote:
>
> The problem with making these builtins respect the number of return values
> context in want() is that, as Nate mentions, the expressions may have
> side-effects that are desired for the whole list.
>
> An alternative approach is to make these builtins respect lazy(), as
Nathan Wiger wrote:
> Tom Christiansen wrote:
> >
> > Ever consider then having
> >
> > ($a, $b, $c) = ;
> > or
> > @a[4,1,5] = ;
> >
> > only read three lines? I mean, how many if any builtins would it
> > make sense to make aware of this, and do something "different"?
>
> Personally, I
At 11:54 AM 9/4/00 -0700, Nathan Wiger wrote:
> > Seems a bit rare and unimportant -- until one observes how this
> > would also solve the problem of people being confused by this
> > gobbling up their handle:
> >
> > my($line) = ;
>
>And a nice side effect too. As Peter says, the only problem
Tom Christiansen wrote:
>
> Ever consider then having
>
> ($a, $b, $c) = ;
> or
> @a[4,1,5] = ;
>
> only read three lines? I mean, how many if any builtins would it
> make sense to make aware of this, and do something "different"?
Personally, I think this would be really cool; stuff l
At 10:52 AM 9/4/00 -0600, Nathan Torkington wrote:
>Peter Scott writes:
> > >> ($a, $b, $c) = ;
> > >> or
> > >> @a[4,1,5] = ;
> > >> only read three lines?
> > >
> > >I think this is a superb idea, and look forward to someone's RFC'ing it.
>
>Should be part of the want() c
Peter Scott writes:
> >> ($a, $b, $c) = ;
> >> or
> >> @a[4,1,5] = ;
> >> only read three lines?
> >
> >I think this is a superb idea, and look forward to someone's RFC'ing it.
Should be part of the want() context. Permit operations to discover
(as does split) how many el
At 11:48 AM 9/3/00 +1100, Damian Conway wrote:
>> Ever consider then having
>>
>> ($a, $b, $c) = ;
>> or
>> @a[4,1,5] = ;
>>
>> only read three lines?
>
>I think this is a superb idea, and look forward to someone's RFC'ing it.
I like it too. Anyone working on
> Ever consider then having
>
> ($a, $b, $c) = ;
> or
> @a[4,1,5] = ;
>
> only read three lines?
I think this is a superb idea, and look forward to someone's RFC'ing it.
Damian
> > Here is my suggestion: What if other functions were able to backtrace
> > context and determine how many arguments to return just like split can?
>I have an RFC on that:
> RFC 21: Replace C with a generic C function
>C takes a list of strings that describe aspects of the
>
> Here is my suggestion: What if other functions were able to backtrace
> context and determine how many arguments to return just like split can?
I have an RFC on that:
RFC 21: Replace C with a generic C function
C takes a list of strings that describe aspects of the
> "Tom" == Tom Christiansen <[EMAIL PROTECTED]> writes:
Tom> Wherever you think you need one of these, try to think again. Either
Tom> it's already in list context, in which case it's silly to put in
Tom> the list thing, or else there's always a better way to accomplish
Tom> whatever you're
Tom Hughes wrote:
> > For example, in Perl you have for a long time been able to do this:
> >
> >($one, $two) = grep /$pat/, @data;
> >
> > However, what currently happens is grep goes to completion, then
> > discards possibly huge amounts of data just to return the first two
> > matches. For
In message <[EMAIL PROTECTED]>
Nathan Wiger <[EMAIL PROTECTED]> wrote:
> For example, in Perl you have for a long time been able to do this:
>
>($one, $two) = grep /$pat/, @data;
>
> However, what currently happens is grep goes to completion, then
> discards possibly huge amounts of
Tom Christiansen wrote:
>
> >Well, it only does this if it's not something like 'split', then!
>
> Yes, it does "do it" with split. split is defined to do what it
> does, how it does it. *This* is the kind of senseless harping that
> annoys me, Nathan.
H. I'm apparently not making myself
>Well, it only does this if it's not something like 'split', then!
Yes, it does "do it" with split. split is defined to do what it
does, how it does it. *This* is the kind of senseless harping that
annoys me, Nathan.
> So it's not 100% consistent.
Wrong: It's 100% consistent with the docume
> >Let me shift gears and instead ask whether anyone thinks this:
>
> >> > $y = ($first, $second) = grep /$pat/, @data;
>
> >Returning "5" has any value? If you're going to do this, it seems like
> >you'd want the number that were really returned (since scalar grep
> >will give you the total n
>Let me shift gears and instead ask whether anyone thinks this:
>> > $y = ($first, $second) = grep /$pat/, @data;
>Returning "5" has any value? If you're going to do this, it seems like
>you'd want the number that were really returned (since scalar grep
>will give you the total number found an
Tom Christiansen wrote:
>
> % man perlfunc
> ...
> When assigning to a list, if LIMIT is omitted, Perl supplies a
> LIMIT one larger than the number of variables in the list, to
> avoid unnecessary work.
As usual I picked a bad example. And I did read the perlfunc manpage,
bu
>> If you write
>>
>> $burp = LISTIFY( grep {EXPR} @data );
>>
>> What's in the burp?
>By this argument, then why aren't these different?
It depends on whether you think the alpha or beta are
what you want. It's highly unclear why you aren't just
using straight scalar context t
Tom Christiansen wrote:
>
First off, thanks for taking the time to present such a thorough
document. Well-reasoned arguments is exactly what the Perl 6 project
needs, IMO.
I read this early last night, and have been postulating on it ever
since. In the process of trying what feels like 100's of
>I read your message and agree. Not that I liked the idea that much even
>before considering the ramifications. But do you agree that even
>seasoned perlers have trouble anticipating how a list/array is going to
>be converted to a scalar?
A list or array? No, I don't agree. How to predict what
On Fri, Sep 01, 2000 at 11:23:16AM -0700, Steve Fink wrote:
> I read your message and agree. Not that I liked the idea that much even
> before considering the ramifications. But do you agree that even
> seasoned perlers have trouble anticipating how a list/array is going to
> be converted to a sca
> for reality here. That should be written more like:
>
> 1 while ; $burp = $.;
>
> or even:
>
> for ($burp = 0; my $line = ; $burp++) {}
I'd go for
my $burp = 0; $burp++ while ;
> This proposal should be dropped.
I read your message and agree. Not that I liked the
Bart, until you've read my long message, you're wasting my time.
Please read it.
--tom
>To be consistent, "scalar list" should return the number of elements.
Says who? $x = ("foo", "bar") produces "bar", not 2.
It's all a big looney tune. "scalar list" makes negative sense.
If you want a count function, write one, but don't pretend that
"scalar list" is such a thing, nor that "s
On Fri, 01 Sep 2000 07:30:54 -0600, Tom Christiansen wrote:
> % man perldata
>
> List assignment in a scalar context returns the number of
> elements produced by the expression on the right side of
> the assignment:
>
> $x = (($foo,$bar) = (3,2,1)); # set $x to
Bart Lateur wrote:
>
> $\ = "\n"; print $a = () = qw(a b c);
> -->
> 3
>
> All those who expected that the list would be evaluated in array (not
> list!) context, raise your hands.
this illustrates why the whole subject is, or can be, so confusing.
That qw() list was NOT evaluated
> $\ = "\n"; print $a = () = qw(a b c);
>-->
> 3
>All those who expected that the list would be evaluated in array (not
>list!) context, raise your hands. Not many, I would think.
What the devil is "array context"? You mean the thing that push expects
for its first argument? Just w
>Let's fall back to what we have already:
> $\ = "\n"; print $a = () = qw(a b c);
>-->
> 3
>All those who expected that the list would be evaluated in array (not
>list!) context, raise your hands. Not many, I would think.
Read my last letter--the one nobody commented on. What do y
On Fri, 1 Sep 2000 13:25:07 +1100 (EST), Damian Conway wrote:
>More than anything I think the inability to write C DWIMishly
>argues that we need it built-in. But we also need a *very* careful design
>of the semantics.
Well, except that it isn't clear which DWIM you want. Does DWIM mean,
the eff
> > This is the kind of thing that keeps Perl instructors in business...
>And Perl out of businesses :-(
>More than anything I think the inability to write C DWIMishly
>argues that we need it built-in. But we also need a *very* careful design
>of the semantics.
I'd like to see from this measu
> This is the kind of thing that keeps Perl instructors in business...
And Perl out of businesses :-(
More than anything I think the inability to write C DWIMishly
argues that we need it built-in. But we also need a *very* careful design
of the semantics.
Damian
At 11:46 PM 8/31/00 +0200, Bart Lateur wrote:
>On Fri, 1 Sep 2000 07:27:24 +1100 (EST), Damian Conway wrote:
>
> > > > And has anyone pointed out that C is just:
> > > >
> > > > sub list {@_}
> > >
> > > Um no. I would expect it to be
> > >
> > > sub list { @_[0..$#_] }
> >
> >It's
On Fri, 1 Sep 2000 07:27:24 +1100 (EST), Damian Conway wrote:
> > > And has anyone pointed out that C is just:
> > >
> > > sub list {@_}
> >
> > Um no. I would expect it to be
> >
> > sub list { @_[0..$#_] }
>
>It's too early in the morning.
>The subtlety here escapes me
Graham Barr wrote:
> On Thu, Aug 31, 2000 at 03:55:28PM +1100, Damian Conway wrote:
> > And has anyone pointed out that C is just:
> >
> > sub list {@_}
>
> Um no. I would expect it to be
>
> sub list { @_[0..$#_] }
According to my quickie tests, both have the desired effect
(supplying l
> > And has anyone pointed out that C is just:
> >
> > sub list {@_}
>
> Um no. I would expect it to be
>
> sub list { @_[0..$#_] }
It's too early in the morning.
The subtlety here escapes me.
Damian
On Thu, Aug 31, 2000 at 03:55:28PM +1100, Damian Conway wrote:
> And has anyone pointed out that C is just:
>
> sub list {@_}
Um no. I would expect it to be
sub list { @_[0..$#_] }
Graham.
[EMAIL PROTECTED] wrote:
>
> (yes, I'm in an RFC-commenting mood today...)
>
> On Wed, Aug 30, 2000 at 02:22:31AM -, Perl6 RFC Librarian wrote:
> >Add C keyword to force list context (like C)
>
> Makes sense to me. Does it connect in any way with Damian's generic
> want() function?
Implic
> On Wed, Aug 30, 2000 at 02:22:31AM -, Perl6 RFC Librarian wrote:
> >Add C keyword to force list context (like C)
>
> Makes sense to me. Does it connect in any way with Damian's generic
> want() function?
Only in that it would explicitly cause C to return true.
And has anyo
(yes, I'm in an RFC-commenting mood today...)
On Wed, Aug 30, 2000 at 02:22:31AM -, Perl6 RFC Librarian wrote:
>Add C keyword to force list context (like C)
Makes sense to me. Does it connect in any way with Damian's generic
want() function?
K.
--
Kirrily Robert -- <[EMAIL PROTECTED]> --
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Add C keyword to force list context (like C)
=head1 VERSION
Maintainer: Nathan Wiger <[EMAIL PROTECTED]>
Date: 29 Aug 2000
Mailing List: [EMAIL PROTECTED]
Version: 1
Number: 175
Status: De
43 matches
Mail list logo
