Chaim Frenkel wrote:
>
> NW> @stuff = docoolstuff(%hash, $var, @array);
> NW> @stuff = docoolstuff(%hash, $var) = @array;
>
> Then assignment arguments must be a the tail of the prototype. A bit
> of limitation.
No, that's not true:
@stuff = docoolstuff(@stuff) = %hash, $var;
@st
> "NW" == Nathan Wiger <[EMAIL PROTECTED]> writes:
NW> If arrays are maintained "properly" (not flattened) in Perl, then they
NW> will remain separate, whether as parameters, across = assignments, etc,
NW> etc. The same goes true for mixing arrays and scalars and hashes:
NW> @stuff = doc
Chaim Frenkel wrote:
>
> NW>$old = assign($var, $val);
> NW>$old = assign($var) = $val;
> NW>$old = assign = $var, $val;
>
> I don't think that the assigned values should be moved by perl into
> the argument list.
> You are reintroducing another version of the list flattening problem
> "NW" == Nathan Wiger <[EMAIL PROTECTED]> writes:
NW> Can be called as any of these forms by default:
NW>$old = assign($var, $val);
NW>$old = assign($var) = $val;
NW>$old = assign = $var, $val;
NW> Make sense? This RFC doesn't address true lvalue subs, rather that
NW> rvalue su
Chaim Frenkel wrote:
>
> Why this limitation?
>
> If the lvalue is a fundemental type (whatever that is) everything works
> as if the lvalue were actually in place
>
> sub foo { return $a }
> foo =~ s///;# same as $a =~ s///;
This is not the type of lvalue sub that th
> "PRL" == Perl6 RFC Librarian <[EMAIL PROTECTED]> writes:
PRL> The key to the proposal is this: lvalue and rvalue versions of a sub
PRL> would work I, and both would be enabled by default.
PRL> I, assignment is the only valid operator for these default
PRL> lvalue subs. Attempts to use other
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Simple assignment lvalue subs should be on by default
=head1 VERSION
Maintainer: Nathan Wiger <[EMAIL PROTECTED]>
Date: 24 Aug 2000
Version: 1
Mailing List: [EMAIL PROTECTED]
Number: 154
S
