Re: [perl #69194] rakudo 2009-08 and when with lists
On 2009-Sep-18, at 8:44 am, Moritz Lenz wrote: Aaron Sherman wrote: 2,3 constructs a list. 2..3 also constructs a list, unless it's in a given/when condition in which case it's just a range. No. 2..3 is always a range. It's just list context that turns it into a list. That seems confusing. It sounds like the split personality of Ranges strikes again. I still think it makes more sense to have one Series-only type and one Range- only type, rather than one Series type and one Range-plus-Series type. -David
Re: [perl #69194] rakudo 2009-08 and when with lists
David (>), Moritz (>>), Aaron (>>>): >>> 2,3 constructs a list. 2..3 also constructs a list, unless it's in a >>> given/when condition in which case it's just a range. >> >> No. 2..3 is always a range. It's just list context that turns it into a >> list. >> >>> That seems confusing. > > It sounds like the split personality of Ranges strikes again. I still think > it makes more sense to have one Series-only type and one Range-only type, > rather than one Series type and one Range-plus-Series type. If for no other reason than to contribute a contrasting viewpoint, I'm not sure I see the problem in this case. A range is an object in Perl 6, in a much more palpable way than in Perl 5. This might be what causes the mental mismatch for Perl5-ers. As far as I can see, the range object already is of your proposed Range-plus-Series type, and when I apply list context to the range, I get your proposed Series-only type (which happens to be an ordinary list, but still). // Carl
Re: [perl #69194] rakudo 2009-08 and when with lists
On Sat, Sep 19, 2009 at 6:48 AM, Carl Mäsak wrote:
> David (>), Moritz (>>), Aaron (>>>):
2,3 constructs a list. 2..3 also constructs a list, unless it's in a
given/when condition in which case it's just a range.
>>>
>>> No. 2..3 is always a range. It's just list context that turns it into a
>>> list.
>>>
That seems confusing.
>>
>> It sounds like the split personality of Ranges strikes again. I still think
>> it makes more sense to have one Series-only type and one Range-only type,
>> rather than one Series type and one Range-plus-Series type.
>
> If for no other reason than to contribute a contrasting viewpoint, I'm
> not sure I see the problem in this case. A range is an object in Perl
> 6, in a much more palpable way than in Perl 5. This might be what
> causes the mental mismatch for Perl5-ers.
>
> As far as I can see, the range object already is of your proposed
> Range-plus-Series type, and when I apply list context to the range, I
> get your proposed Series-only type (which happens to be an ordinary
> list, but still).
The one thing that worries me about this is how :by fits into it all.
rakudo: given 1.5 { when 1..2 { say 'between one and two' }; say 'not'; };
p6eval rakudo 4b141a: OUTPUT«between one and two»
feels like it makes sense to me. But
rakudo: given 1.5 { when Range.new(from => 1, to => 2, by => 1/3) {
say 'between one and two' }; say 'not'; };
p6eval rakudo 4b141a: OUTPUT«between one and two»
makes me very leery. I know :by isn't actually implemented yet, but
what should it do here when it is?
--
Solomon Foster: colo...@gmail.com
HarmonyWare, Inc: http://www.harmonyware.com
r28306 - docs/Perl6/Spec t/spec/S06-other
Author: ruoso
Date: 2009-09-19 15:45:20 +0200 (Sat, 19 Sep 2009)
New Revision: 28306
Added:
t/spec/S06-other/introspection.t
Modified:
docs/Perl6/Spec/S06-routines.pod
Log:
[S06] adds $multi.push($candidate)
[spectest] adds a spec test for the introspection S06 section
Modified: docs/Perl6/Spec/S06-routines.pod
===
--- docs/Perl6/Spec/S06-routines.pod2009-09-19 13:38:22 UTC (rev 28305)
+++ docs/Perl6/Spec/S06-routines.pod2009-09-19 13:45:20 UTC (rev 28306)
@@ -2947,6 +2947,14 @@
This method returns a (potentially lazy) list of the candidates that match the
given
capture.
+=item .push($candidate)
+
+Adds $candidate to the list of candidates for this multi, calling this
+method in an only routine should result in a failure. It is also
+accepted for multis declared in the source code to finalize the list
+of candidates and also return a failure here. But multis created by
+calling Multi.new() should be able add candidates at run-time.
+
=back
=head3 Signature
Added: t/spec/S06-other/introspection.t
===
--- t/spec/S06-other/introspection.t(rev 0)
+++ t/spec/S06-other/introspection.t2009-09-19 13:45:20 UTC (rev 28306)
@@ -0,0 +1,65 @@
+use v6;
+
+use Test;
+
+plan 20;
+
+#?rakudo: 20 skip "routine introspection NYI"
+
+# L
+
+# introspecting only subs
+only sub only-sub($a, $b) { "only" };
+
+# .candidates
+is(&only-sub.candidates.elems,1,"an only subs lists itself in the
.candidates");
+is(&only-sub.candidates[0].(1,2),"only","an only subs lists itself in the
.candidates");
+
+# .cando
+is(&only-sub.cando(\(1,2)).elems,1,"an only sub implements .cando");
+is(&only-sub.cando(\(1,2)).[0].(1,2),"only","an only sub implements .cando");
+
+# .signature
+ok(&only-sub.signature ~~ \(1,2),"an only sub implements .signature");
+
+# introspecting multi subs
+multi sub multi-sub(1,2) { "m1" };
+multi sub multi-sub(1) { "m2" };
+multi sub multi-sub(){ "m3" };
+
+# .candidates
+is(&multi-sub.candidates.elems,3,"a multi sub returns all its candidates");
+
+# .cando
+is(&multi-sub.cando(\(1,2)).[0].(1,2),"m1","you can invoke through
introspection");
+is(&multi-sub.cando(\(1)).[0].(1),"m2","you can invoke through introspection");
+is(&multi-sub.cando(\()).[0].(),"m3","you can invoke through introspection");
+
+# .signature
+my $sig = &multi-sub.signature;
+ok($sig ~~ \(1,2),"junction sig matches first candidate");
+ok($sig ~~ \(1),"junction sig matches second candidate");
+ok($sig ~~ \(), "junction sig matches third candidate");
+
+# creating a multi in runtime
+my $multi = Multi.new();
+ok($multi,"One can create a new multi at run time");
+
+# let's populate this runtime multi.
+$multi.push(sub (1,2) { "m1" });
+$multi.push(sub (1) { "m2" });
+$multi.push(sub (){ "m3" });
+
+# .candidates
+is($multi.candidates.elems,3,"runtime multi sub returns all its candidates");
+
+# .cando
+is($multi.cando(\(1,2)).[0].(1,2),"m1","you can invoke through introspection");
+is($multi.cando(\(1)).[0].(1),"m2","you can invoke through introspection");
+is($multi.cando(\()).[0].(),"m3","you can invoke through introspection");
+
+# .signature
+my $sig = $multi.signature;
+ok($sig ~~ \(1,2),"junction sig matches first candidate");
+ok($sig ~~ \(1),"junction sig matches second candidate");
+ok($sig ~~ \(), "junction sig matches third candidate");
Re: perl6.org (Was: Re: How can i contribute for perl 6 ?)
Moritz Lenz wrote: > In other words, we need to scale. Please check perl6.org again, mostly the scaling is done now. Cheers, Moritz
Implicit die in CATCH blocks
In the process of writing some more tests for CATCH blocks, I've noticed
what appears to be a contradiction between Synopsis 4 on the one hand
and pugs/t/spec/S04-statements/try.t and Rakudo's current behavior on
the other. The specification says "there is an implicit C just
inside the end of the C block", and that if you want to catch an
exception you haven't explicitly smart-matched, you need to use a
C block. But look at this test:
{
# try with a catch
my $caught;
try {
die "blah";
CATCH { $caught = 1 }
};
ok($caught, "exception caught");
};
The "blah" ought to be rethrown by the CATCH block, avoiding the ok()
entirely, but instead, Rakudo passes this test. Is this a mistake on the
part of the test and the implementation, or on the part of the
specification? It confuses matters that CATCH is defined to act like a
switch statement, and
given EXPR { default { ... } }
is the same as
given EXPR { ... }
, making C strictly redundant in given blocks but not
(according to the spec) CATCH blocks.
Re: [perl #69194] rakudo 2009-08 and when with lists
On 2009-Sep-19, at 5:53 am, Solomon Foster wrote:
On Sat, Sep 19, 2009 at 6:48 AM, Carl Mäsak wrote:
David (>>>),
It sounds like the split personality of Ranges strikes again. I
still think
it makes more sense to have one Series-only type and one Range-
only type,
rather than one Series type and one Range-plus-Series type.
If for no other reason than to contribute a contrasting viewpoint,
I'm
not sure I see the problem in this case. A range is an object in Perl
6, in a much more palpable way than in Perl 5. This might be what
causes the mental mismatch for Perl5-ers.
Well, I wonder if the journey from a P5 point of view is the
historical reason why we ended up with Range+series ".." and Series
"...". Otherwise what's the rationale for having Range-:by separate
from "..."?
As far as I can see, the range object already is of your proposed
Range-plus-Series type,
But that's the problem; I'm proposing there shouldn't be a Range-plus-
Series type, because it mixes two different concepts. As a range it
works one way (basically representing an ordered pair of endpoints),
but if you use :by() it looks like a discrete list... even though
really it still is "just" a Range object.
and when I apply list context to the range, I get your proposed
Series-only type (which happens to be an ordinary list, but still).
I think a Range shouldn't turn into a list, at least not implicitly.
Some ranges have an obvious coercion (e.g. "a".."c" becomes ),
but some don't (e.g. 1..5, which should encompass all nums between 1
and 5, not just the Ints. Unless we distinguish Int(1)..Int(5) from
Num(1)..Num(5), which only raises the potential for confusion).
The one thing that worries me about this is how :by fits into it all.
rakudo: given 1.5 { when 1..2 { say 'between one and two' }; say
'not'; };
rakudo: given 1.5 { when Range.new(from => 1, to => 2, by => 1/3) {
makes me very leery. I know :by isn't actually implemented yet, but
what should it do here when it is?
Exactly: 1.5 is "between" 1 and 2, but if you're counting by thirds,
1.5 is not in the list(1..2 :by(1/3)). Sure, we can stipulate that
this is simply how the rules work, but people are still going to get
confused. On the other hand, we can get rid of the list/series/:by
part of Ranges without losing any power (move that capability to ...
instead), and cut down on the confusion.
-David
Re: [perl #69194] rakudo 2009-08 and when with lists
On Sat, Sep 19, 2009 at 9:45 PM, David Green wrote:
> On 2009-Sep-19, at 5:53 am, Solomon Foster wrote:
>
> The one thing that worries me about this is how :by fits into it all.
>>rakudo: given 1.5 { when 1..2 { say 'between one and two' }; say
>> 'not'; };
>>rakudo: given 1.5 { when Range.new(from => 1, to => 2, by => 1/3) {
>> makes me very leery. I know :by isn't actually implemented yet, but what
>> should it do here when it is?
>>
>
> Exactly: 1.5 is "between" 1 and 2, but if you're counting by thirds, 1.5 is
> not in the list(1..2 :by(1/3)). Sure, we can stipulate that this is simply
> how the rules work, but people are still going to get confused. On the
> other hand, we can get rid of the list/series/:by part of Ranges without
> losing any power (move that capability to ... instead), and cut down on the
> confusion.
1..2 is used abstractly to indicate a range, even though it's actually an
iterator that will return two values. However, once you apply an explicit
:by, I think you've gone past that abstraction, and it's no longer
reasonable to expect that values that fall between your iterations will
match.
