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.
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
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: 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
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: [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
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 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
