Author: larry
Date: Tue Feb 5 09:15:04 2008
New Revision: 14500
Modified:
doc/trunk/design/syn/S03.pod
Log:
Clarify that lhs of list assignment is list of containers, not thunks
Modified: doc/trunk/design/syn/S03.pod
==
Author: larry
Date: Tue Feb 5 09:55:29 2008
New Revision: 14501
Modified:
doc/trunk/design/syn/S02.pod
doc/trunk/design/syn/S03.pod
doc/trunk/design/syn/S06.pod
Log:
Added named placeholders using $:foo twigil; idea from cognominal++:
Placeholder subs can now also autoadd [EMAIL PROTECT
> +++ doc/trunk/design/syn/S03.podTue Feb 5 09:55:29 2008
> @@ -2791,7 +2791,7 @@
> are insufficient for defining the "pecking order" of code. Note that
> you can bind to either a bare block or a pointy block. Binding to a
> bare block conveniently leaves the topic in C<$_>, so the fi
On Tue, Feb 05, 2008 at 10:42:35AM -0800, Jonathan Lang wrote:
: > +++ doc/trunk/design/syn/S03.podTue Feb 5 09:55:29 2008
: > @@ -2791,7 +2791,7 @@
: > are insufficient for defining the "pecking order" of code. Note that
: > you can bind to either a bare block or a pointy block. Bindi
Larry Wall wrote:
> : Is it forbidden to use placeholder parameters in conjunction with
> : "my"? Or would it simply not do anything useful? I ask because "Do
> : what I mean" would seem to imply that 'my Dog $^foo' would specify
> : $^foo's type as 'Dog'. Though if you start doing too much of t
On Tue, Feb 05, 2008 at 11:57:37AM -0800, Jonathan Lang wrote:
: Larry Wall wrote:
: > : Is it forbidden to use placeholder parameters in conjunction with
: > : "my"? Or would it simply not do anything useful? I ask because "Do
: > : what I mean" would seem to imply that 'my Dog $^foo' would spec
--- Larry Wall <[EMAIL PROTECTED]> wrote:
> Besides $^_ is just uglier than anything else I've seen today...
lol -- I thought of it as a rather cute peeking-wink with a cauliflower
ear, but that's probably much more cutesiness than we want to encourage
in our language design.
===
At 9:15 AM -0800 2/5/08, [EMAIL PROTECTED] wrote:
+The left side is evaluated completely for its sequence of containers before
+any assignment is done. Therefore this:
+
+my $a = 0; my @b;
+($a, @b[$a]) = 1, 2;
+
+assigns 2 to @b[0], not @b[1].
Personally, I think this is a particularl
On Feb 5, 2008 5:34 PM, Darren Duncan <[EMAIL PROTECTED]> wrote:
> >+my $a = 0; my @b;
> >+($a, @b[$a]) = 1, 2;
> >+
> >+assigns 2 to @b[0], not @b[1].
>
> Personally, I think this is a particularly welcome change.
It is certainly less surprising, I'd say. But is there a LET*
analogue to
On Tue, Feb 05, 2008 at 02:34:35PM -0800, Darren Duncan wrote:
> At 9:15 AM -0800 2/5/08, [EMAIL PROTECTED] wrote:
>> +The left side is evaluated completely for its sequence of containers before
>> +any assignment is done. Therefore this:
>> +
>> +my $a = 0; my @b;
>> +($a, @b[$a]) = 1, 2;
On Tue, Feb 05, 2008 at 05:42:28PM -0500, Mark J. Reed wrote:
: On Feb 5, 2008 5:34 PM, Darren Duncan <[EMAIL PROTECTED]> wrote:
: > >+my $a = 0; my @b;
: > >+($a, @b[$a]) = 1, 2;
: > >+
: > >+assigns 2 to @b[0], not @b[1].
: >
: > Personally, I think this is a particularly welcome change.
On Feb 5, 2008 8:11 PM, Larry Wall <[EMAIL PROTECTED]> wrote:
> Oh wait, I lied. You can get pugs to do it with:
>
> my $a = 0; my @b; (lazy { VAR($a) }, lazy { VAR(@b[$a]) }) = 1,2; say
> @b.join(':')
>
> Now just put that in a macro...
Ah, macros, is there no problem you can't solve? :)
T
12 matches
Mail list logo
