Re: call, call(), .call, and captures
On 9/20/06, Aaron Sherman [EMAIL PROTECTED] wrote: Larry Wall wrote: What we really need is a unary operator that is sugar for [,](=(...)). Just don't anyone suggest *. :-) I was thinking about that. I wonder if [\] would make sense, or is that just begging to have in-editor parsers fall over screaming ;) That would be quite close to [\+] [\,] etc.. from S03: S03 say [\+] 1..* # (1, 3, 6, 10, 15, ...) -- Markus Laire
Dumb list-flattening question.
Ok, I dkimmed through the synopses again and didn't see this offhand. If I have two arrays @a and @b and I wish to create a two-element list out of them - a la Perl5 ([EMAIL PROTECTED], [EMAIL PROTECTED]) - what's the correct way to do that in Perl6? If it's still ([EMAIL PROTECTED], [EMAIL PROTECTED]), then what do we call what the \ is doing there, now that references are supposed to be a behind-the-scenes automagical thing? -- Mark J. Reed [EMAIL PROTECTED]
Re: Dumb list-flattening question.
Mark J. Reed skribis 2006-09-21 9:53 (-0400): If I have two arrays @a and @b and I wish to create a two-element list out of them - a la Perl5 ([EMAIL PROTECTED], [EMAIL PROTECTED]) - what's the correct way to do that in Perl6? If it's still ([EMAIL PROTECTED], [EMAIL PROTECTED]), then what do we call what the \ is doing there, now that references are supposed to be a behind-the-scenes automagical thing? They're captures. I personally wouldn't mind unary $, to supplement unary @ and %. -- korajn salutojn, juerd waalboer: perl hacker [EMAIL PROTECTED] http://juerd.nl/sig convolution: ict solutions and consultancy [EMAIL PROTECTED]
Captures: Synopsis update
[EMAIL PROTECTED] wrote: Maintainer: Larry Wall [EMAIL PROTECTED] Date: 10 Aug 2004 - Last Modified: 18 Sept 2006 + Last Modified: 20 Sept 2006 Number: 2 - Version: 69 + Version: 70 +| capture/arguments/match +|$args; # all of the above I'll read that as conversation terminated. Can you please update S03's Junctive operators section to note how the ambiguity of the following are resolved: a|$b a | $b a |$b I presume that it will be based on whitespace, but they could also be based on an inspection of a's signature (if a takes no parameters, then the only useful meaning of Ca|$b is Cinfix:|(a(), $b), I think). I further presume that such an update will be required for the pugs/v6 team to correctly implement this.
Re: Dumb list-flattening question.
Mark J. Reed wrote: Ok, I dkimmed through the synopses again and didn't see this offhand. If I have two arrays @a and @b and I wish to create a two-element list out of them - a la Perl5 ([EMAIL PROTECTED], [EMAIL PROTECTED]) - what's the correct way to do that in Perl6? If it's still ([EMAIL PROTECTED], [EMAIL PROTECTED]), then what do we call what the \ is doing there, now that references are supposed to be a behind-the-scenes automagical thing? To expand on the previous answer, unary backslash as described in S03 captures its argument and various representations can be extracted. In this case, you are capturing an array, and creating a list of arrays. This is done by reference, we presume, but that detail is not available to the programmer the way it was in P5. Other forms of capture: \$var; # Capture a scalar \%var; # Capture a hash \(...); # Capture parameters \\$foo (as in Perl 5) is not a capture to a capture, it simply acts like \$foo.
Re: Dumb list-flattening question.
Mark J. Reed wrote: Ok, I dkimmed through the synopses again and didn't see this offhand. That's what I get for dkimming instead of reading. Or even skimming. OK, so Capture objects fill the ecological niche of references in Perl 6. Got it. Perhaps we should also mention the use of Captures to prevent list flattening somewhere in S09. So now we have | as the all of the above dereferencer. I like the mnemonic association with junctions, since |$x is logically similar to ($$x|@$x|%$x). I dislike adding yet more whitespace-resolved ambiguity to the grammar, though. -- Mark J. Reed [EMAIL PROTECTED]
Re: Captures: Synopsis update
On Thu, Sep 21, 2006 at 10:29:57AM -0400, Aaron Sherman wrote: : I'll read that as conversation terminated. The conversation is never terminated. However, every now and then I make feeble attempts to be decisive. :) : Can you please update S03's Junctive operators section to note how the : ambiguity of the following are resolved: : : a|$b : a | $b : a |$b : : I presume that it will be based on whitespace, but they could also be : based on an inspection of a's signature (if a takes no parameters, then : the only useful meaning of Ca|$b is Cinfix:|(a(), $b), I think). There's no whitespace dwimmery here. Either 'a' takes an argument list or it doesn't, based on its signature. If it doesn't, all those are infix:|. If it does, they are all prefix:|, except that we specifically outlaw the first; list operators in Perl 6 require a space after them. : I further presume that such an update will be required for the pugs/v6 : team to correctly implement this. Don't think so. The situation is exactly analogous to: a+$b a + $b a +$b and even more exactly analogous to: a%$b a % $b a %$b The cultural ambiguity is also being reduced insofar as we're trying to discourage use of bare constants in favor of sigilled constants. If you see a bare function name you should generally assume it has arguments in Perl 6. We could probably go as far as to issue an optional warning on the middle cases above based on whitespace dwimmery and on whether the program gets in trouble later. But it would be a mistake to base the actual parsing on that. That's the sort of trick Perl 5 would have attempted, and I hope I know better now. Larry
Re: Captures: Synopsis update
On 9/21/06, Larry Wall [EMAIL PROTECTED] wrote: : note how the ambiguity of the following are resolved: : : a|$b : a | $b : a |$b : Don't think so. The situation is exactly analogous to: a%$b a % $b a %$b The cultural ambiguity is also being reduced insofar as we're trying to discourage use of bare constants in favor of sigilled constants. Which means that argumentless subroutine calls will presumably be rare in P6 code, but what about methods? Methods with no arguments (apart from the invocant) will always be commonplace, and it seems to me that you have exactly the same ambiguity there: $o.a%$b $o.a % $b $o.a %$b -- Mark J. Reed [EMAIL PROTECTED]
Re: Captures: Synopsis update
On 9/21/06, Larry Wall [EMAIL PROTECTED] wrote: A method never takes arguments unless you use : or (), so those are all infix. Well, all righty then. Yay for unambiguity! Or disambiguation. Or nonambiguosity. Or whatever... The design team worked Really Hard to get rid of that particular ambiguity in Perl 6. Thank you, design team. -- Mark J. Reed [EMAIL PROTECTED]
The bare constants bear
All sounds good up to: Larry Wall wrote: The cultural ambiguity is also being reduced insofar as we're trying to discourage use of bare constants in favor of sigilled constants. If you see a bare function name you should generally assume it has arguments in Perl 6. Well, in that case, should pi, e, et al. become $pi, $e, @et al.? ;) Seriously, though, I think we discussed this before, and we kept those constants as bare, but if there's a cultural shift, then those would probably be its poster-children. I'm also in favor of the $π type Unicode equivalents for uniformity. Boolean constants are more questionable, as is the zeroary undef, which is pretty hard-coded in the brain of the average Perl programmer. Right now, in the Math::Basic API doc, we have: =head2 Constants To export the constants provided by CMath::Basic use the C:constants tag when importing: use Math::Basic :constants; =over =item e constant Num Math::Basic::e The constant Ce, roughly equal to C2.71828182845905. =item euler_constant constant Num Math::Basic::γ constant Num Math::Basic::euler_constant The Euler constant (or Euler-Mascheroni constant or simply γ), roughly equal to C0.57721566490153286. This constant should not be confused with Ce. =item golden_ratio constant Num Math::Basic::φ constant Num Math::Basic::phi constant Num Math::Basic::golden_ratio The golden ratio, roughly equal to C1.6180339887498948. =item i constant Complex Math::Basic::i The constant Ci, which is defined as the square root of C-1. =item one constant Complex Math::Basic::one The constant value C1. =item pi constant Num Math::Basic::π constant Num Math::Basic::pi The constant Cpi, roughly equal to C3.14159265358979. =item zero constant Complex Math::Basic::zero The constant value C0. =back Yes, I've spotted the bug in one and zero being complex for no good reason. If you think that we should change to sigiled constants, then I will make it: =head2 Constants To export the constants provided by CMath::Basic use the C:constants tag when importing: use Math::Basic :constants; =over =item $e constant Num $Math::Basic::e The constant Ce, roughly equal to C2.71828182845905. =item $euler_constant constant Num $Math::Basic::γ constant Num $Math::Basic::euler_constant The Euler constant (or Euler-Mascheroni constant or simply γ), roughly equal to C0.57721566490153286. This constant should not be confused with Ce. =item $golden_ratio constant Num $Math::Basic::φ constant Num $Math::Basic::phi constant Num $Math::Basic::golden_ratio The golden ratio, roughly equal to C1.6180339887498948. =item $i constant Complex $Math::Basic::i The constant Ci, which is defined as the square root of C-1. =item $one constant Int $Math::Basic::one The constant value C1. =item $pi constant Num $Math::Basic::π constant Num $Math::Basic::pi The constant Cpi, roughly equal to C3.14159265358979. =item $zero constant Int $Math::Basic::zero The constant value C0. =back
Re: Good list-flattening question.
Mark J. Reed wrote: Ok, I dkimmed through the synopses again and didn't see this offhand. If I have two arrays @a and @b and I wish to create a two-element list out of them - a la Perl5 ([EMAIL PROTECTED], [EMAIL PROTECTED]) - what's the correct way to do that in Perl6? If it's still ([EMAIL PROTECTED], [EMAIL PROTECTED]), then what do we call what the \ is doing there, now that references are supposed to be a behind-the-scenes automagical thing? I think it's a good question, considering this is worked for me in Perl 6: my @c = ([EMAIL PROTECTED], [EMAIL PROTECTED]); I'm not sure how to reconcile that with the spec I found for \: The unary backslash operator captures its arguments, and returns an object representing those arguments. Mark
Re: Capture sigil
Larry Wall wrote: Okay, I think this is worth bringing up to the top level. Fact: Captures seem to be turning into a first-class data structure that can represent: argument lists match results XML nodes anything that requires all of $, @, and % bits. Also; role type parameters Sam.
Capture Literals
How would I construct a capture literal that has both an invocant and
at least one positional argument? How do I distinguish this from a
capture literal that has no invocant and at least two positional
arguments?
Gut instinct: if the first parameter in a list is delimited from the
rest using a colon instead of a comma, treat it as the invocant;
otherwise, treat it as the first positional argument.
This would mean that the rules for capturing are as follows:
* Capturing something in scalar context: If it is a pair, it is
captured as a named argument; otherwise, it is captured as the
invocant.
* Capturing something in list context: Pairs are captured as named
arguments; the first non-pair is captured as the invocant if it is
followed by a colon, but as a positional argument otherwise; all other
non-pairs are captured as positional arguments.
So:
$x = /$a; # $$x eqv $a
$x = /:foo;# %$x eqv { foo = 1 }
$x = /($a,); # @$x eqv ( $a ); is the comma neccessary, or are the
() enough?
$x = /($a:); # $$x eqv $a
$x = /(:foo); # %$x eqv { foo = 1 }; assuming that adverbs can go
inside ().
$x = /($a, $b) # @$x eqv ($a, $b)
$x = /($a: $b) # $$x eqv $a; @$x eqv ($b)
$x = /:foo ($a: $b, $c):barbaz == $d, $e == flag = 0; # results
on next three lines:
# $$x eqv $a
# @$x eqv ($b, $c, $d, $e)
# %$x eqv { foo = 1, bar = 'baz', flag = 0 }
Note that this approach makes it impossible for a pair to end up
anywhere other than as a named argument in the capture object; while
this makes sense when the capture object is being used as a proxy
argument list, it makes less sense when it is being used as the
equivalent of perl 5's references, and thus is probably a bug.
--
Jonathan Dataweaver Lang
Re: Capture sigil
Two questions: 1. How would the capture sigil affect the use of capture objects as replacements for perl5's references? 2. With the introduction of the capture sigil, would it be worthwhile to allow someone to specify a signature as a capture object's 'type'? That is: my :(Dog: Str $name, Num :legs) |x = /($spot: Spot):legs4; in analogy to 'my Dog $spot'? -- Jonathan Dataweaver Lang
Re: Capture Literals
On Thu, Sep 21, 2006 at 10:03:45PM -0700, Jonathan Lang wrote:
: How would I construct a capture literal that has both an invocant and
: at least one positional argument? How do I distinguish this from a
: capture literal that has no invocant and at least two positional
: arguments?
:
: Gut instinct: if the first parameter in a list is delimited from the
: rest using a colon instead of a comma, treat it as the invocant;
: otherwise, treat it as the first positional argument.
That is correct.
: This would mean that the rules for capturing are as follows:
:
: * Capturing something in scalar context: If it is a pair, it is
: captured as a named argument; otherwise, it is captured as the
: invocant.
:
: * Capturing something in list context: Pairs are captured as named
: arguments; the first non-pair is captured as the invocant if it is
: followed by a colon, but as a positional argument otherwise; all other
: non-pairs are captured as positional arguments.
Capture literals ignore their context like [...] does.
: So:
:
: $x = \$a; # $$x eqv $a
: $x = \:foo;# %$x eqv { foo = 1 }
: $x = \($a,); # @$x eqv ( $a ); is the comma neccessary, or are the
: () enough?
I think the () is probably enough.
: $x = \($a:); # $$x eqv $a
: $x = \(:foo); # %$x eqv { foo = 1 }; assuming that adverbs can go
: inside ().
: $x = \($a, $b) # @$x eqv ($a, $b)
: $x = \($a: $b) # $$x eqv $a; @$x eqv ($b)
: $x = \:foo ($a: $b, $c):barbaz == $d, $e == flag = 0; # results
: on next three lines:
:# $$x eqv $a
:# @$x eqv ($b, $c, $d, $e)
:# %$x eqv { foo = 1, bar = 'baz', flag = 0 }
Ignoring the syntax error, yes.
: Note that this approach makes it impossible for a pair to end up
: anywhere other than as a named argument in the capture object; while
: this makes sense when the capture object is being used as a proxy
: argument list, it makes less sense when it is being used as the
: equivalent of perl 5's references, and thus is probably a bug.
If you say flag = 0 it comes in as a pair rather than a named arg.
Larry
