[OT] Re: [svn:perl6-synopsis] r14501 - doc/trunk/design/syn
--- 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. === Hodges' Rule of Thumb: Don't expect reasonable behavior from anything with a thumb. Never miss a thing. Make Yahoo your home page. http://www.yahoo.com/r/hs
Re: [svn:perl6-synopsis] r14501 - doc/trunk/design/syn
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 specify : > : $^foo's type as 'Dog'. Though if you start doing too much of that, : > : you're almost certainly better off explicitly defining a signature. : > : > Indeed. : : So we're agreed that it could be abused if permitted. Still, is it permitted? No. The only twigils currently permitted in a signature (and what follows a declarator is a signature even if it doesn't look like it) are "." and "!". I don't see a good case for relaxing this. I don't think we should allow a "my" to retroactively override a parameter's type in any case. : > : Also, how much trouble would we get in if we spelled the ubiquitous : > : alias for a method's invocant as C< $^_ > instead of C< $self >? : > : > Then we're back to confusing people over the difference between the : > object and the topic, and the topic-as-self breaks as soon as you : > topicalize some other way. And you can always throw in a "$_ := self" : > or a "given self" if you really want it. Plus $.foo is still only : > one character longer than .foo so it doesn't really get you much most : > of the time. : : Huh. My intention was not to topicalize the invocant. Rather, I : thought that $_ and $^_ would be treated as two separate variables: $_ : would be the topic, while $^_ would be the invocant. I'm trying to : think of why this distinction might not be. Right now the placeholder twigils are specced in terms of rewrite rules to twigil-less signatures, so the real variables never actually carry the twigil. Therefore $^foo and $foo are the same underlying variable as it currently stands, just as $+foo really maps to a contextual variable name somewhere that has no '+' as part of its name. Note also that $!foo and $foo are likewise really the same variable within a method. The $! form is just more emphatically private. : Unless I'm missing something, it would be very much like what we have : now, except that '$self' would be spelled '$^_' (shorter and not tied : to English, but instead evocative of "I'm using a parameter that I may : not have declared in the signature, sort of like what placeholder : parameters do" and "I'm using the parameter that defines what this : routine is talking about, sort of like what the topic variable does"). There is no $self, it's just the 0-ary function "self". There is only a variable if you specify it explicitly as the invocant in a signature. Besides $^_ is just uglier than anything else I've seen today... Larry
Re: [svn:perl6-synopsis] r14501 - doc/trunk/design/syn
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 that, > : you're almost certainly better off explicitly defining a signature. > > Indeed. So we're agreed that it could be abused if permitted. Still, is it permitted? > : Also, how much trouble would we get in if we spelled the ubiquitous > : alias for a method's invocant as C< $^_ > instead of C< $self >? > > Then we're back to confusing people over the difference between the > object and the topic, and the topic-as-self breaks as soon as you > topicalize some other way. And you can always throw in a "$_ := self" > or a "given self" if you really want it. Plus $.foo is still only > one character longer than .foo so it doesn't really get you much most > of the time. Huh. My intention was not to topicalize the invocant. Rather, I thought that $_ and $^_ would be treated as two separate variables: $_ would be the topic, while $^_ would be the invocant. I'm trying to think of why this distinction might not be. Unless I'm missing something, it would be very much like what we have now, except that '$self' would be spelled '$^_' (shorter and not tied to English, but instead evocative of "I'm using a parameter that I may not have declared in the signature, sort of like what placeholder parameters do" and "I'm using the parameter that defines what this routine is talking about, sort of like what the topic variable does"). -- Jonathan "Dataweaver" Lang
Re: [svn:perl6-synopsis] r14501 - doc/trunk/design/syn
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. Binding to a : > bare block conveniently leaves the topic in C<$_>, so the final form : > -above is equivalent to a C. (Placeholders parameters may : > +above is equivalent to a C. (Placeholder parameters may : > also be used in the bare block form, though of course their types : > cannot be specified that way.) : : 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 that, : you're almost certainly better off explicitly defining a signature. Indeed. : Also, how much trouble would we get in if we spelled the ubiquitous : alias for a method's invocant as C< $^_ > instead of C< $self >? Then we're back to confusing people over the difference between the object and the topic, and the topic-as-self breaks as soon as you topicalize some other way. And you can always throw in a "$_ := self" or a "given self" if you really want it. Plus $.foo is still only one character longer than .foo so it doesn't really get you much most of the time. Larry
Re: [svn:perl6-synopsis] r14501 - doc/trunk/design/syn
> +++ 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 final form > -above is equivalent to a C. (Placeholders parameters may > +above is equivalent to a C. (Placeholder parameters may > also be used in the bare block form, though of course their types > cannot be specified that way.) 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 that, you're almost certainly better off explicitly defining a signature. Also, how much trouble would we get in if we spelled the ubiquitous alias for a method's invocant as C< $^_ > instead of C< $self >? -- Jonathan "Dataweaver" Lang
[svn:perl6-synopsis] r14501 - doc/trunk/design/syn
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 PROTECTED] or *%_ to the signature
Methods without signatures may use placeholders
Modified: doc/trunk/design/syn/S02.pod
==
--- doc/trunk/design/syn/S02.pod(original)
+++ doc/trunk/design/syn/S02.podTue Feb 5 09:55:29 2008
@@ -12,9 +12,9 @@
Maintainer: Larry Wall <[EMAIL PROTECTED]>
Date: 10 Aug 2004
- Last Modified: 17 Jan 2008
+ Last Modified: 5 Feb 2008
Number: 2
- Version: 126
+ Version: 127
This document summarizes Apocalypse 2, which covers small-scale
lexical items and typological issues. (These Synopses also contain
@@ -1292,7 +1292,8 @@
$fooordinary scoping
$.foo object attribute accessor
-$^foo self-declared formal parameter
+$^foo self-declared formal positional parameter
+$:foo self-declared formal named parameter
$*foo global variable
$+foo contextual variable
$?foo compiler hint variable
@@ -1583,6 +1584,10 @@
my ($a, $, $c) = 1..3;
print unless (state $)++;
+Outside of declarative contexts you may use C<*> for a placeholder:
+
+($a, *, $c) = 1..3;
+
=item *
Ordinary package-qualified names look like in Perl 5:
Modified: doc/trunk/design/syn/S03.pod
==
--- doc/trunk/design/syn/S03.pod(original)
+++ 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 final form
-above is equivalent to a C. (Placeholders parameters may
+above is equivalent to a C. (Placeholder parameters may
also be used in the bare block form, though of course their types
cannot be specified that way.)
Modified: doc/trunk/design/syn/S06.pod
==
--- doc/trunk/design/syn/S06.pod(original)
+++ doc/trunk/design/syn/S06.podTue Feb 5 09:55:29 2008
@@ -13,9 +13,9 @@
Maintainer: Larry Wall <[EMAIL PROTECTED]>
Date: 21 Mar 2003
- Last Modified: 2 Jan 2008
+ Last Modified: 5 Feb 2008
Number: 6
- Version: 91
+ Version: 92
This document summarizes Apocalypse 6, which covers subroutines and the
@@ -151,10 +151,15 @@
means the declared formal parameter is I considered readonly; only
its elements are. See L below.
-Note also that if the sub's block contains placeholder variables (such
-as C<$^foo>), it is considered to have a formal signature already, so
-no implicit bindings to C<@_> or C<%_> are assumed (nor is an explicit
-signature allowed.) So in that case, this section does not apply.
+Note also that if the sub's block contains placeholder variables
+(such as C<$^foo> or C<$:bar>), those are considered to be formal
+parameters already, so in that case C<@_> or C<%_> fill the role of
+sopping up unmatched arguments. That is, if those containers are
+explicitly mentioned within the body, they are added as slurpy
+parameters. This allows you to easily customize your error message
+on unrecognized parameters. If they are not mentioned in the body,
+they are not added to the signature, and normal dispatch rules will
+simply fail if the signature cannot be bound.
=head2 Blocks
@@ -1508,25 +1513,42 @@
Even though every bare block is a closure, bare blocks can't have
explicit parameter lists. Instead, they use "placeholder" variables,
-marked by a caret (C<^>) after their sigils.
+marked by a caret (C<^>) or a colon (C<:>) after their sigils.
+The caret marks positional placeholders, while the colon marks named
+placeholders.
Using placeholders in a block defines an implicit parameter list. The
-signature is the list of distinct placeholder names, sorted in Unicode order.
-So:
+signature is the list of distinct positional placeholder names,
+sorted in Unicode order, following by the named placeholder names in
+any order. So:
-{ $^y < $^z && $^x != 2 }
+{ say "woof" if $:dog; $^y < $^z && $^x != 2 }
is a shorthand for:
--> $x,$y,$z { $y < $z && $x != 2 }
+-> $x,$y,$z,:$dog { say "woof" if $dog; $y < $z && $x != 2 }
Note that placeholder variables syntactically cannot have type constraints.
Also, it is illegal to use placeholder variables in a block that already
has a signature, because the autogenerated signature would conflict with that.
-Placeholder names consisting of a single uppercase letter are disallowed,
+Positional placeholder names consisting of a sing
