Re: Which brackets should @a.perl use?
Uri, On Sun, 04 Jan 2009 22:37:43 -0500, Uri Guttman wrote: that fails with nested arrays. we don't want them to flatten. my $c = eval '(1, (4, 5), 3)'; will that work as you envision? No, but it's not what I'm proposing. A reference must Perlify as a reference, just as it does today, so that .perl doesn't destroy information by flattening where you don't want it to. Here's what I propose: my @a = 1, 2, 3; @a.perl.say; # (1, 2, 3) my $ra = @a; $ra.perl.say;# [1, 2, 3] my @b = 1, [2, 3], 4; @b.perl.say; # (1, [2, 3], 4) my $rb = @b; $rb.perl.say;# [1, [2, 3], 4] My objection to the current behaviour is that @a and $ra Perlify to the same string -- '[1, 2, 3]' -- losing the information that @a is an array and $ra is a reference to an array. Therefore, if you serialise and unserialise an array, you always get an array of a single element, containing a reference to the real data. What you get back is not what you put in. Markus
Re: Which brackets should @a.perl use?
m == moritz mor...@casella.faui2k3.org writes: m S02 says: m To get a Perlish representation of any object, use the .perl method. Like m the Data::Dumper module in Perl 5, the .perl method will put quotes around m strings, square brackets around list values, m So according to this, Rakudo has it right. m But I think that a .perl()ification as (blue, light, hayard,) would m make much more sense, because simple thing like m @a.push eval(@b.perl) m would then DWIM. for your def of DWIM. i can see wanting an anon array to be pushed onto @a building up a structure. DWIM in the sense that eval($stuff.perl) should behave the same as $stuff itself. since @a.push(@b) flattens @b into @a, why should I expect something different from @a.push(eval(@b.perl))? your example is too simple to really cover this as you could just push @b or a ref to @b (damn, i need to learn more basic p6 syntax! :). If people want @a.push(\...@b) or @a.push([...@b]), they can just write that - and if the want to use eval + perl, they can include the brackets or backslash just as well. a more useful example would be serializing data trees. if you dump @b with .perl do you want the current dumper output of a anon array or your list of values? when serializing a tree, you must get the ref version so that is the common and default usage. your version isn't DWIMmy there at all. Maybe we can construct something magic with slice context and captures instead? Cheers, Moritz
rfc: The values of a junction
I spent a fair amount of time with Rakudo over the holiday break (see
http://dave.whipp.name/sw/perl6 for the writeup). I was generally
impressed with both the language and its implementation. There were,
unsurprisingly, a bunch of things missing. Some of these were things
that are in the spec, but not yet in Rakudo. Others are things that feel
important, but which could be added later, via modules. But one
omission, junctional collapse, appears to me to require core language
support: it is not a feature that can be added as a user module.
The term collapse is a metaphor taken from quantum mechanics. It is
apt, because the concept of the values of a junction makes sense only
in the context of the action of an operator on the junction. It is my
proposal that we add a new meta-operator to S03 that acts to apply other
operators (equality and inequality tests) to junctions:
@domain |op| $junction -- @values ## junction-collapsing grep
@domain !|op| $junction -- @values ## it's negated partner
The operator has the semantics of a grep, but with the ability to
handle infinite ranges in finite time. The reason for this should become
apparent from a motivating example. Consider a blackjack hand: a set of
cards where the value of aces is either 1 or 11. The total value of a
hand can be described as a junction:
my $ace = 1 | 11;
my $seven = 7;
my @hand = $ace xx 3, $seven;
my $junc_value = [+] @hand; ## any( 10, 20, 30, 40 )
There are a bunch of possible values in the junction. The one we care
about is the largest that is not greater than 21. Using Perl6 as it
stands today, the way to extract this value is brute force:
my $concrete_value = max (0..21).grep: { $^score == $junc_value };
This will work, but doesn't scale. Imagine we wanted all the possible
values, and know nothing about their domain:
my @all_values = (-Inf..Inf).grep: { $^score == $junc_value };
This code has an obvious performance problem that would be tricky to
optimize away! And that problem is the justification of my assertion
that junctional collapse requires core language support. Using a grep
meta operator:
my $concrete_value = max 0 .. 21 |==| $junc_value;
my @all_values = -Inf .. Inf |==| $junc_value;
the infinite range can be handled correctly.
Adding a new meta-operator should not be undertaken lightly. I believe
that the collapse of junctions is a necessary feature of the language,
and one that cannot be added as a user-module. Furthermore, alternatives
such as a eigenvalues method on the Junction class fail to address the
core property of junctions that their value depends on the operator that
is used to observe them.
Another hurdle that the meta operator must overcome it to demonstrate
that it is sufficiently general. If the only values of op was ==,
then we wouldn't need a meta. Also, the operator has application
beyond collapsing junctions. Some more examples:
say ^Inf || one 4 .. Inf; ## result == 5
say @lines |~~| /word/;## no junction: a standard grep
An additional feature -- not part of my core proposal, but one that I
think would add value -- would be to allow a typename to be used as the
LHS domain, in place of an infinite range:
say ::Str |eq| any foo bar baz ; ## match against all strings
say ::Str !|ne| all foo bar baz ; ## same result
say ::Str !|eq| none foo bar baz ; ## same again!
or a finite range:
subset BJ_score where { $_ == any 0 .. 21 };
say score is { max( ::BJ_score |==| $junc_score ) // bust }
I'd like to think that this proposal is an obvious way to meet a
necessary need. Even if this exact approach is not chosen, I hope to
have at least convinced you that core language support is needed to
extract the values of a junction; and that a Junction::eigenvalues
method is not the correct way to achieve this.
Dave.
ps. The reason for choosing vertical bars, |op|, as the meta-op syntax
is partly by analogy to the concept of absolute value that
mathematicians express using vertical bars; and partly a less-cute
distillation of a bra-ket suggestion I make in the writeup that I
referenced above.
Re: r24769 - docs/Perl6/Spec
On 2009 Jan 5, at 11:54, pugs-comm...@feather.perl6.nl wrote: + our Str multi method perl (Object $o) + +Returns a perlish representation of the object, so that calling Ceval +on the returned string reproduces the object as good as possible. My inner English teacher cringes in pain. It should be accurately, or possibly completely; good just doesn't fit there. -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allb...@kf8nh.com system administrator [openafs,heimdal,too many hats] allb...@ece.cmu.edu electrical and computer engineering, carnegie mellon universityKF8NH
Re: rfc: The values of a junction
Em Seg, 2009-01-05 às 07:57 -0800, Dave Whipp escreveu:
my $ace = 1 | 11;
my $seven = 7;
my @hand = $ace xx 3, $seven;
my $junc_value = [+] @hand; ## any( 10, 20, 30, 40 )
There are a bunch of possible values in the junction. The one we care
about is the largest that is not greater than 21. Using Perl6 as it
stands today, the way to extract this value is brute force:
my $concrete_value = max (0..21).grep: { $^score == $junc_value };
Well, that considering we don't have any introspection into junctions,
but I think it should be quite straight-forward to make junctions behave
as a list of its members...
my $ace = 1 | 11;
my $seven = 7;
my @hand = $ace xx 3, $seven;
my $junc_value = [+] @hand;
my $concrete_value = max $junc_value.grep: { $^scope 21 };
daniel
r24774 - docs/Perl6/Spec
Author: particle Date: 2009-01-05 20:29:06 +0100 (Mon, 05 Jan 2009) New Revision: 24774 Modified: docs/Perl6/Spec/S19-commandline.pod Log: [S19] note behavior of clustered options with required values Modified: docs/Perl6/Spec/S19-commandline.pod === --- docs/Perl6/Spec/S19-commandline.pod 2009-01-05 19:21:25 UTC (rev 24773) +++ docs/Perl6/Spec/S19-commandline.pod 2009-01-05 19:29:06 UTC (rev 24774) @@ -14,8 +14,8 @@ Maintainer: Jerry Gay jerry@rakudoconsulting.com Date: 12 Dec 2008 - Last Modified: 3 Jan 2009 - Version: 9 + Last Modified: 4 Jan 2009 + Version: 10 This is a draft document. This document describes the command line interface. It has changed extensively from previous versions of Perl in order to increase @@ -122,7 +122,9 @@ =item * -Single-letter options may be clustered. C-ab means C-a -b. +Single-letter options may be clustered. C-ab means C-a -b. When a +single-letter option which requires a value is clustered, the option may +appear only in the final position of the cluster. =item *
r24768 - docs/Perl6/Spec
Author: particle Date: 2009-01-05 17:53:12 +0100 (Mon, 05 Jan 2009) New Revision: 24768 Modified: docs/Perl6/Spec/S19-commandline.pod Log: [S19] provide rules for negated single-character options; rearrange list items for clarity Modified: docs/Perl6/Spec/S19-commandline.pod === --- docs/Perl6/Spec/S19-commandline.pod 2009-01-05 16:39:14 UTC (rev 24767) +++ docs/Perl6/Spec/S19-commandline.pod 2009-01-05 16:53:12 UTC (rev 24768) @@ -126,12 +126,14 @@ =item * -Option names follow Perl 6 identifier naming convention, but C' -is not allowed. +Options may be negated with C/, for example C--/name, C:/name, C-/n. +Each single-letter option in a cluster must be negated separately + (e.g. C-a/n/o is the same as C-a -/n -/o.) =item * -Options may be negated with C/, for example C--/name, C:/name, C-/n. +Option names follow Perl 6 identifier naming convention, except C' is not +allowed, and single-letter options may be any letter or number. =item *
r24779 - docs/Perl6/Spec
Author: particle Date: 2009-01-05 21:29:32 +0100 (Mon, 05 Jan 2009) New Revision: 24779 Modified: docs/Perl6/Spec/S06-routines.pod Log: [S06] add another command-line short name example; modify comment to line up visually with others Modified: docs/Perl6/Spec/S06-routines.pod === --- docs/Perl6/Spec/S06-routines.pod2009-01-05 20:25:22 UTC (rev 24778) +++ docs/Perl6/Spec/S06-routines.pod2009-01-05 20:29:32 UTC (rev 24779) @@ -13,9 +13,9 @@ Maintainer: Larry Wall la...@wall.org Date: 21 Mar 2003 - Last Modified: 2 Jan 2009 + Last Modified: 4 Jan 2009 Number: 6 - Version: 99 + Version: 100 This document summarizes Apocalypse 6, which covers subroutines and the @@ -2741,6 +2741,7 @@ # Short names -n :name -n=value :namevalue +-nvalue:namevalue # only if not declared Bool -n=spacy value :name«'spacy value'» -n='spacy value' :name«'spacy value'» -n=val1,'val 2',etc:name«val1 'val 2' etc» @@ -2756,7 +2757,7 @@ --name 'spacy value' :name«'spacy value'» --name=val1,'val 2',etc:name«val1 'val 2' etc» --name val1 'val 2' etc:name«val1 'val 2' etc» # only if declared @ --- # end named argument processing +-- # end named argument processing # Negation --/name:!name
r24769 - docs/Perl6/Spec
Author: moritz Date: 2009-01-05 17:54:50 +0100 (Mon, 05 Jan 2009) New Revision: 24769 Modified: docs/Perl6/Spec/S29-functions.pod Log: [S29] document isa, can, does, perl and clone Modified: docs/Perl6/Spec/S29-functions.pod === --- docs/Perl6/Spec/S29-functions.pod 2009-01-05 16:53:12 UTC (rev 24768) +++ docs/Perl6/Spec/S29-functions.pod 2009-01-05 16:54:50 UTC (rev 24769) @@ -190,6 +190,22 @@ =head1 Function Packages +=head2 Object + +Every object conforms to the type CObject. The following methods are thusly +available on every object. + +=over + +=item perl + + our Str multi method perl (Object $o) + +Returns a perlish representation of the object, so that calling Ceval +on the returned string reproduces the object as good as possible. + +=back + =head2 Any The following are defined in the CAny role: @@ -206,6 +222,27 @@ from C$by in that each criterion is applied, in order, until a non-zero (equivalent) result is achieved. +=item can + + our Bool multi method can ($self:, Str $method) + +If there is a multi method of name C$method that can be called on +C$self, then closure is return has C$self bound to the position +of the invocant. + +Otherwise an undefined value is returned. + +=item clone + + our multi method clone (::T $self -- T) + our multi method clone (::T $self, *%attributes -- T) + +The first variant retuns an independent copy of C$o that is equivlant +to C$o. + +The second variant does the same, but any named arguments override an +attribute during the cloning process. + =item cmp our Order multi sub cmp (Ordering @by, $a, $b) @@ -219,6 +256,19 @@ (tie) result is achieved. If the values are not comparable, returns a proto COrder object that is undefined. +=item does + + our Bool multi method does ($self:, $type) + +Returns CTrue if and only if C$self conforms to type C$type. + +=item isa + + our Bool multi method isa ($self:, $type) + +Returns true if a the invocant an instance of class C$type, or +of a subset type or a derived class (through inheritance) of C$type. + =back =head2 Num
Re: r24769 - docs/Perl6/Spec
On Mon, Jan 05, 2009 at 05:54:50PM +0100, pugs-comm...@feather.perl6.nl wrote: Author: moritz Date: 2009-01-05 17:54:50 +0100 (Mon, 05 Jan 2009) New Revision: 24769 +=item can + + our Bool multi method can ($self:, Str $method) + +If there is a multi method of name C$method that can be called on +C$self, then closure is return has C$self bound to the position +of the invocant. + +Otherwise an undefined value is returned. then closure is return has ? perhaps: then the closure that is returned has ? If it returns a closure then isn't Bool the signature wrong? Before someone 'fixes' that, though, couldn't can() just return a Bool, and move the 'give me a closure' to another method? Ignoring the performance cost of needlessly creating closures for simple boolean usage, 'can' doesn't seem like a good name for a 'give me a closure' method. +=item clone + + our multi method clone (::T $self -- T) + our multi method clone (::T $self, *%attributes -- T) + +The first variant retuns an independent copy of C$o that is equivlant +to C$o. typos variant returns and equivalant +The second variant does the same, but any named arguments override an +attribute during the cloning process. perhaps: any named arguments are applied to $self as attributes, overriding any attributes with the same names. Makes it clearer that the attributes aren't applied to nested elements. +=item isa + + our Bool multi method isa ($self:, $type) + +Returns true if a the invocant an instance of class C$type, or typos Returns CTrue if the invocant is an instance ... Tim.
Re: returning one or several values from a routine
Daniel Ruoso wrote:
Hi,
As smop and mildew now support ControlExceptionReturn (see
v6/mildew/t/return_function.t), an important question raised:
sub plural { return 1,2 }
sub singular { return 1 }
my @a = plural();
my $b = plural();
my @c = singular();
my $d = singular();
What should @a, $b, @c and $d contain?
@a = 1, 2;
$b = [1, 2];
@c = 1;
$d = 1;
(According to DWIM semantics and my understanding of the specs)
Note that the spec says explicitly that a Capture should be returned,
delaying the context at which the value will be used, this allows
sub named { return :x1 }
my $x := |(named);
So, this also means that assigning
my @a = plural();
my @c = singular();
forces list context in the capture, which should return all positional
parameters, as expected. But
my $b = plural();
my $d = singular();
would force item context in the capture, and here is the problem, as a
capture in item context was supposed to return the invocant.
Maybe we could have a different rule for captures in scalar contexts
that don't have an invocant?
Just my 0.02€,
Moritz
Re: rfc: The values of a junction
That doesn't solve the general problem:
my $junc = any -4 .. Inf;
my @domain = -Inf .. 4;
my @values = @domain |==| $junc;
say @values.perl
[ -4 .. 4 ]
How do you code that using grep?
From: Daniel Ruoso dan...@ruoso.com
To: Dave Whipp d...@dave.whipp.name
Cc: perl6-language@perl.org
Sent: Monday, January 5, 2009 11:24:29 AM
Subject: Re: rfc: The values of a junction
Em Seg, 2009-01-05 às 07:57 -0800, Dave Whipp escreveu:
my $ace = 1 | 11;
my $seven = 7;
my @hand = $ace xx 3, $seven;
my $junc_value = [+] @hand; ## any( 10, 20, 30, 40 )
There are a bunch of possible values in the junction. The one we care
about is the largest that is not greater than 21. Using Perl6 as it
stands today, the way to extract this value is brute force:
my $concrete_value = max (0..21).grep: { $^score == $junc_value };
Well, that considering we don't have any introspection into junctions,
but I think it should be quite straight-forward to make junctions behave
as a list of its members...
my $ace = 1 | 11;
my $seven = 7;
my @hand = $ace xx 3, $seven;
my $junc_value = [+] @hand;
my $concrete_value = max $junc_value.grep: { $^scope 21 };
daniel
Re: rfc: The values of a junction
Daniel Ruoso wrote:
my $concrete_value = max $junc_value.grep: { $^score 21 };
In the general case, both the junction and the domain may be infinite:
my @domain = -Inf .. 3;
my $junc = any -4 .. Inf;
my @values = @domain |==| $junc;
say @values.perl
[-4..3]
Handling all the variations around this (including compound junctions)
will be quite tricky to implement, even if we did have introspection for
junctions. Certainly not stuff I'd want in typical user-code.
Re: returning one or several values from a routine
Daniel Ruoso wrote:
Hi,
As smop and mildew now support ControlExceptionReturn (see
v6/mildew/t/return_function.t), an important question raised:
sub plural { return 1,2 }
sub singular { return 1 }
my @a = plural();
my $b = plural();
my @c = singular();
my $d = singular();
What should @a, $b, @c and $d contain?
Note that the spec says explicitly that a Capture should be returned,
delaying the context at which the value will be used, this allows
sub named { return :x1 }
my $x := |(named);
So, this also means that assigning
my @a = plural();
my @c = singular();
forces list context in the capture, which should return all positional
parameters, as expected. But
my $b = plural();
my $d = singular();
would force item context in the capture, and here is the problem, as a
capture in item context was supposed to return the invocant.
If item context is supposed to return the invocant, then it would seem
to me that returning a single value from a sub would put that value
into the capture object's invocant. This would mean that the problem
crops up under 'my @c = singular()' instead of 'my $b = plural()'.
The idea in the spec is that the capture object can hold an item, a
distinct list, and a distinct hash all at once. The problem that
we're encountering here is that there are times when the difference
between an item and a one-item list is fuzzy. We _could_ kludge it by
saying that when a sub returns an item $x, it gets returned as a
capture object ($invocant := $x: $param1 := $x) or some such; but this
_is_ a kludge, which has the potential for unexpected and unsightly
developments later on.
Another option would be to change the way that applying item context
to a capture object works in general, to allow for the possibility
that a single-item list was actually intended to be a single item: if
there's no invocant, but there is exactly one positional parameter,
return the positional parameter instead:
$a = |(title: 1)
$b = |(title:)
$c = |(1)
$x = item $a; # $x == title
$x = item $b; # $x == title
$x = item $c; # $x == 1
$x = list $a; # $x == [1]
$x = list $b; # $x == []
$x = list $c; # $x == [1]
With this approach, return values would return values as positional
parameters unless a conscious effort was made to do otherwise.
But let's say that you really wanted to get the invocant of a capture
object. You can still do so:
|($x:) = $a; # $x == title
|($x:) = $b; # $x == title
|($x:) = $c; # $x == undef
Likewise, you could specify that you want the first positional
parameter of the capture object by saying:
|($x) = $a; # $x == 1
|($x) = $b; # $x == undef
|($x) = $c; # $x == 1
This isn't as clean as a straight mapping of invocant to item,
positional to list, and named to hash; but I think that it's got
better dwimmery.
--
Jonathan Dataweaver Lang
