On Tue, Aug 15, 2000 at 08:05:25PM -, Perl6 RFC Librarian wrote:
>=head1 TITLE
>
>lvalue subs should receive the rvalue as an argument
>
>=head1 VERSION
>
>Maintainer: Andy Wardley <[EMAIL PROTECTED]>
>Date: 15 Aug 2000
>Version: 1
>Mailing List: [EMAIL PROTECTED]
>Number:
> "NW" == Nathan Wiger <[EMAIL PROTECTED]> writes:
NW> The concept isn't that hard ":lvalue makes it so you can assign to
NW> subs". But the hard part is deciding *where* it should be used. I think
NW> it puts an unfair burden on a CPAN author to try and forsee all the
NW> possible uses of a
- Original Message -
From: "Jonathan Scott Duff" <[EMAIL PROTECTED]>
Sent: Wednesday, August 16, 2000 10:00 AM
Subject: Re: Make lvalue subs the default (was Re: RFC 107 (v1) lvalue subs
should receive the rvalue as an argument)
> On Wed, Aug 16, 2000 at 12:14:09AM
Chaim Frenkel writes:
> CN> Can we please cut down on the traffic to perl-announce, maybe make it
> CN> moderated? Thanks,
>
> Perhaps, the esteemed Librarian could make the -announce a Bcc?
One of the moderators was a little too approval-happy. I believe
this has been fixed as of a few hours
On Wed, Aug 16, 2000 at 01:51:09PM -0600, Nathan Torkington wrote:
> Nathan Wiger writes:
> > Nonetheless, I think a better thing would be to figure out if it's
> > possible to "fix" this issue. I would *really* like lvalue subs ==
> > rvalue subs.
>
> I think conflating:
>foo(@vals)
> and
>
> "CN" == Chris Nandor <[EMAIL PROTECTED]> writes:
CN> Can we please cut down on the traffic to perl-announce, maybe make it
CN> moderated? Thanks,
Perhaps, the esteemed Librarian could make the -announce a Bcc?
--
Chaim FrenkelNonlinear Knowledge,
> I think conflating:
>foo(@vals)
> and
>foo() = @vals
>
> is misleading and going to cause more confusion that it solves.
In simple cases, yes. The above looks misleading. Advanced stuff like
chaining though would be really cool. I could come up with oodles of
examples. :-)
> What kind
Nathan Wiger writes:
> Nonetheless, I think a better thing would be to figure out if it's
> possible to "fix" this issue. I would *really* like lvalue subs ==
> rvalue subs.
I think conflating:
foo(@vals)
and
foo() = @vals
is misleading and going to cause more confusion that it solves.
>
Nathan Torkington wrote:
>
> > Then I think both of these should act exactly the same:
> >
> > somesub(@values);
> > somesub = @values;
>
> EUGH. No way!
>
> Assignment should be used to reflect (get this) assignment. Using
> it as argument passing is disgusting. I'm assuming you're n
Nathan Torkington wrote:
>
> I think I failed to explain Damian's use of the word 'dangerous'.
>
> my $var;
> sub routine {
> $var;
> }
>
> This, by virtue of rvalue subs being default, keeps the lexical $var
> private. Damian's big on privacy.
> (2) Changing variables in the subrou
Jonathan Scott Duff wrote:
>
> Hrm. Perhaps you aren't explaining yourself clearly. Let's pretend
> that there is a magical value called $LVALUE that contains the thing
> being assigned. Are you saying that in
>
> somesub = $value;
>
> the subroutine C, being lvaluable by default is f
Nathan Wiger writes:
> sub somesub {
> my(@stuff) = @_;
> # do nothing
> }
>
> Then I think both of these should act exactly the same:
>
> somesub(@values);
> somesub = @values;
EUGH. No way!
Assignment should be used to reflect (get this) assignment. Using
it
Nathan Wiger writes:
> Well, this argument makes more sense. However, I still have to disagree.
> In fact, I think the opposite: ALL subs *should* be lvaluable by
> default. Here's why.
I think I failed to explain Damian's use of the word 'dangerous'.
my $var;
sub routine {
$var;
}
T
At 04:14 PM 8/16/00 +0100, Andy Wardley wrote:
>On Aug 16, 9:06am, Jonathan Scott Duff wrote:
> > Passing the lvalue via some other means eliminates this problem. I
> > forget who suggested it (Buddha Buck?) but
> >
> > sub foo : lvalue($value) { ... }
>
>That should tie in with function p
On Wed, Aug 16, 2000 at 08:40:18AM -0700, Nathan Wiger wrote:
> See, I don't see it as that big a deal, especially not if lvalue and
> rvalue subs work identically.
Hrm. Perhaps you aren't explaining yourself clearly. Let's pretend
that there is a magical value called $LVALUE that contains the
> > Ooops! The author didn't use :lvalue. So even though this makes perfect
> > sense to be able to do, since the author forgot to use :lvalue, you lose
> > a really cool syntactic tool. This seems backwards.
>
> Seems right to me. I'd rather assignment to a function work on
> purpose rather tha
On Aug 16, 8:32am, Nathan Wiger wrote:
> Maybe this is the confusion. I'm not saying subs should ONLY be lvalue.
> I think they should be both rvalue and lvalue at the same time.
Point noted and understood, but I'm with the general consensus here.
Lvalue subs should have to be explicitly marked
> And if lvalue access were made the only way of doing assignment of
> params in this context then a whole bunch of the code in param could
> be removed.
Maybe this is the confusion. I'm not saying subs should ONLY be lvalue.
I think they should be both rvalue and lvalue at the same time.
Automat
On Aug 16, 9:06am, Jonathan Scott Duff wrote:
> Passing the lvalue via some other means eliminates this problem. I
> forget who suggested it (Buddha Buck?) but
>
> sub foo : lvalue($value) { ... }
That should tie in with function prototypes in general, but I suspect
that the prototype sho
On Wed, Aug 16, 2000 at 10:59:38AM +0100, Piers Cawley wrote:
> Perl6 RFC Librarian <[EMAIL PROTECTED]> writes:
> > This RFC proposes that lvalue subs, when invoked as such, should receive
> > the rvalue being assigned to it as an argument.
>
> I'm kind of in two minds about this. Most of the tim
Jonathan Scott Duff <[EMAIL PROTECTED]> writes:
> On Wed, Aug 16, 2000 at 10:59:38AM +0100, Piers Cawley wrote:
> > Perl6 RFC Librarian <[EMAIL PROTECTED]> writes:
> > > This RFC proposes that lvalue subs, when invoked as such, should receive
> > > the rvalue being assigned to it as an argument.
On Wed, Aug 16, 2000 at 12:14:09AM -0700, Nathan Wiger wrote:
> No problem. In fact, this fits under your rules. HOWEVER, it also
> assumes that Lincoln thought that param() was :lvalue-worthy. What if he
> forgot? Or didn't think of this case?
Then you email him with a patch, and your reasons wh
Nathan Wiger <[EMAIL PROTECTED]> writes:
> Nathan Torkington wrote:
> > Not every subroutine corresponds to a method call exposing
> > object-internal data. Most of my subroutines *do* something and make
> > no sense to be called lvaluably. Explicit marking the compiler pick
> > up assignments t
Perl6 RFC Librarian <[EMAIL PROTECTED]> writes:
> This RFC proposes that lvalue subs, when invoked as such, should receive
> the rvalue being assigned to it as an argument.
I'm kind of in two minds about this. Most of the time the current
lvalue behaviour does pretty much the Right Thing, and sim
Nathan Torkington wrote:
>
> Not every subroutine corresponds to a method call exposing
> object-internal data. Most of my subroutines *do* something and make
> no sense to be called lvaluably. Explicit marking the compiler pick
> up assignments to non-lvaluable subroutines. It makes sense to
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
lvalue subs should receive the rvalue as an argument
=head1 VERSION
Maintainer: Andy Wardley <[EMAIL PROTECTED]>
Date: 15 Aug 2000
Version: 1
Mailing List: [EMAIL PROTECTED]
Number: 107
26 matches
Mail list logo
