Re: supertyping redux
HaloO,
Larry Wall wrote:
Then we'd write our "done_by" role above as:
role Num-1.3-JRANDOM does STD:Num does Complex;
method re (--> STD:Num) { self }
method im (--> STD:Num) { 0.0 }
The first issue I see with this approach is that we get one
more contender for the plain name Complex because I think
one wants to define an authority Complex along with a role
and a class. I.e. I would want the import site to read:
use Complex:Num;
Which also brings us to the second issue. To actually use
the Complex itself one then needs to write:
use Complex;
use Complex:Num;
unless Complex is a module that provides in addition to
homonymous role and class Complex a modified version of
Num under authority Complex. How would such a module be
defined?
module Complex
{
role Complex {...} # for the type
class Complex does Complex {...} # for instanciation
role Num-1.3-Complex does STD:Num does Complex
{
method re (--> STD:Num) { self }
method im (--> STD:Num) { 0.0 }
}
}
Regards, TSa.
--
Re: Junctions as arguments (Pugs bug)
Ovid wrote:
(reversed the message a bit)
> is 'b', any('a' .. 'h'), 'junctions should work';
This looks like a Test "bug"; it's doing something like:
is 'b', 'a' # not ok
is 'b', 'b' # ok
is 'b', 'c' # not ok
...
If you write:
ok 'b' === any('a'..'h')
The result is one passing test.
> That outputs something like the following on my system (Version: 6.2.13
> (r14927))
>
> any(VInt 1,VInt 2,VInt 3,VInt 4)
> any(VRef )
My question is, what is the expected output of say-ing a junction?
Should "say (1|2|3)" randomly print 1, 2, or 3? Should "say (1&2&3)"
say 1, then say 2, then say 3?
I can understand it going either way (although I'd lean towards what
Ovid is expecting), but it would be good to hear what others think
before tests are committed.
--
package JAPH;use Catalyst qw/-Debug/;($;=JAPH)->config(name => do {
$,.=reverse qw[Jonathan tsu rehton lre rekca Rockway][$_].[split //,
";$;"]->[$_].q; ;for 1..4;$,=~s;^.;;;$,});$;->setup;
Re: Junctions as arguments (Pugs bug)
On Wed, Dec 20, 2006 at 10:26:41AM -0600, Jonathan Rockway wrote:
: Ovid wrote:
: (reversed the message a bit)
: > is 'b', any('a' .. 'h'), 'junctions should work';
:
: This looks like a Test "bug"; it's doing something like:
:
:is 'b', 'a' # not ok
:is 'b', 'b' # ok
:is 'b', 'c' # not ok
:...
:
: If you write:
:
:ok 'b' === any('a'..'h')
:
: The result is one passing test.
:
:
: > That outputs something like the following on my system (Version: 6.2.13
: > (r14927))
: >
: > any(VInt 1,VInt 2,VInt 3,VInt 4)
: > any(VRef )
:
: My question is, what is the expected output of say-ing a junction?
: Should "say (1|2|3)" randomly print 1, 2, or 3? Should "say (1&2&3)"
: say 1, then say 2, then say 3?
:
: I can understand it going either way (although I'd lean towards what
: Ovid is expecting), but it would be good to hear what others think
: before tests are committed.
What you're seeing is standard autothreading behavior, which is
described in S09, "Junctions". To avoid autothreading, a routine must
declare itself prepared to handle junctions with an appropriate type
signature, and I'm not sure we want to complicate Test to that extent,
since it makes it harder to port.
Larry
Re: [svn:perl6-synopsis] r13495 - doc/trunk/design/syn
[EMAIL PROTECTED] writes: > New Revision: 13495 >doc/trunk/design/syn/S12.pod > > +In addition to C, the special functions C, > +C, C, and C dispatch to the next > +candidate, possibly with a new argument list, and if the "next" > +variant is used, without returning: > + > +callsame; # call with the original arguments (return here) > +callwith(); # call with no arguments (return here) > +callwith(1,2,3);# call with a new set of arguments (return here) > +nextsame; # redispatch with the original arguments (no return) > +nextwith(); # redispatch with no arguments (no return) > +nextwith(1,2,3);# redispatch with a new set of arguments (no return) So C sometimes has the meaning of jumping to the next iteration of the current loop (as in Perl 5), and sometimes means to invoke a different method in place of the current one; nextsame and nextwith are related to the latter meaning. Won't that be confusing? Or hard to teach? The 'loop' use of C is likely to be encountered by learning programmers far earlier than 'method' use, leaving the latter as something to trip them up when they finally meet it. Smylers
[svn:perl6-synopsis] r13497 - doc/trunk/design/syn
Author: larry
Date: Wed Dec 20 18:42:50 2006
New Revision: 13497
Modified:
doc/trunk/design/syn/S03.pod
Log:
Made Range objects smarter about transforms.
Modified: doc/trunk/design/syn/S03.pod
==
--- doc/trunk/design/syn/S03.pod(original)
+++ doc/trunk/design/syn/S03.podWed Dec 20 18:42:50 2006
@@ -12,9 +12,9 @@
Maintainer: Larry Wall <[EMAIL PROTECTED]>
Date: 8 Mar 2004
- Last Modified: 5 Dec 2006
+ Last Modified: 20 Dec 2006
Number: 3
- Version: 77
+ Version: 78
=head1 Changes to Perl 5 operators
@@ -535,6 +535,35 @@
so C<^Moose> is short for C or C. It still kinda
means "what is this thing's domain" in an abstract sort of way.
+=item * Since use of C objects in scalar context is usually
+non-sensical, a C object used as an operand for scalar operators
+will generally attempt to distribute the operator to its endpoints and
+return another suitably modified C instead. (Notable exceptions
+include C<< infix:<~~> >>, which does smart matching, and C<< prefix:<+> >>
+which returns the length of the range.) Therefore if you wish to
+write a slice using a length instead of an endpoint, you can say
+
+@foo[ start() + ^$len ]
+
+which is short for:
+
+@foo[ start() + (0..^$len) ]
+
+which is equivalent to something like:
+
+@foo[ list do { my $tmp = start(); $tmp ..^ $tmp+$len } ]
+
+In other words, operators of numeric and other ordered types are
+generally overloaded to do something sensible on C objects.
+In particular, multiplicative operators not only multiply the endpoints
+but also the "by" of the C object:
+
+(1..11:by(2)) * 5 # same as 5..55:by(10)
+5,15,25,35,45,45,55
+
+Conjecture: non-linear functions might even produce non-uniform "by" values!
+Think of log scaling, for instance.
+
=item * The C<...> operator is the "yada, yada, yada" list operator,
which is used as the body in function prototypes. It complains
bitterly (by calling C) if it is ever executed. Variant C
Re: [svn:perl6-synopsis] r13495 - doc/trunk/design/syn
On Wed, Dec 20, 2006 at 10:24:55PM +, Smylers wrote: : [EMAIL PROTECTED] writes: : : > New Revision: 13495 : >doc/trunk/design/syn/S12.pod : > : > +In addition to C, the special functions C, : > +C, C, and C dispatch to the next : > +candidate, possibly with a new argument list, and if the "next" : > +variant is used, without returning: : > + : > +callsame; # call with the original arguments (return here) : > +callwith(); # call with no arguments (return here) : > +callwith(1,2,3);# call with a new set of arguments (return here) : > +nextsame; # redispatch with the original arguments (no return) : > +nextwith(); # redispatch with no arguments (no return) : > +nextwith(1,2,3);# redispatch with a new set of arguments (no return) : : So C sometimes has the meaning of jumping to the next iteration of : the current loop (as in Perl 5), and sometimes means to invoke a : different method in place of the current one; nextsame and nextwith are : related to the latter meaning. : : Won't that be confusing? Or hard to teach? : : The 'loop' use of C is likely to be encountered by learning : programmers far earlier than 'method' use, leaving the latter as : something to trip them up when they finally meet it. Fact is, there *is* a loop there, at least for method dispatch. That's how "next METHOD" works, after all. And if every word we put into Perl prevents us from using longer words that start with the same letters, we're in deep yogurt. Larry
