Re: when calling sets of methods, what happens to the return values?
Mark Stosberg wrote: > S12 describes a feature to call sets of methods at the same time: > > http://feather.perl6.nl/syn/S12.html#Calling_sets_of_methods > > I would like the spec to clarify what happens to the return values of > all these methods. > > I'm fine with a simple answer, such as that they are not available, or > only the first or last set of return values is returned. > > As a "use case", we may use of basically this feature in > CGI::Application in Perl5, as part the plugin system. Each plugin > location is like a method name, and as we get to each point in the code, > we look up through the inheritance tree, executing methods at each location. So, Audrey implemented the beginning of this functionality: $obj.*$meth, for single inheritance. As part that she implemented return values. Her design was to compose the final return value as an unconcatenated list of each method's return value. Example: If C.foo returns (1,2,3) and D.foo returns(4,5,6) you get $obj.*$meth.[0][0] == 1 $obj.*$meth.[1][0] == 4 That works OK for me. If there's a downside, if there is a downside, it's that it could be hard to track down where a mysterious return value came from, since the return value object doesn't tell you exactly which methods were called, and in which order. Mark
clarify: how WALK arguments can be combined
In the Objects chapter, a WALK pseudo-class is spec'ed for using when calling sets of methods: http://feather.perl6.nl/syn/S12.html#Calling_sets_of_methods These are the arguments listed that can be used with WALK: :canonical # canonical dispatch order :ascendant # most-derived first, like destruction order :descendant # least-derived first, like construction order :preorder # like Perl 5 dispatch :breadth# like multi dispatch First, it would be nice if the comments "like Perl 5" and "like multi dispatch" could be expanded, if only to provide references to their complete specs. Also, if "canonical" means something besides "I don't care", it would be nice to have a reference for that, too. My concern for the moment is clarification how these options can be combined. Clearly, combining ":ascendant" and ":descendant" doesn't make sense. But, I assume a "self.*meth" call can work along both the inheritance axis and the multi method access. Therefore, it seems fair to combine one option that affects each axis. As a "use case", in CGI::Application we traverse classes ":ascendant" but then execute what would be "multi methods" in the order they are defined, which sounds like perhaps ":preorder" to me. Mark
Re: multi method dispatching of optional arguments (further refined)
2006/9/4, Ph. Marek <[EMAIL PROTECTED]>: On Sunday 03 September 2006 14:25, Mark Stosberg wrote: > Luke Palmer wrote: > > On 9/3/06, Mark Stosberg <[EMAIL PROTECTED]> wrote: > >> Note that the variant /with/ the parameter can be considered an exact > >> match, but but the variant /without/ it cannot be considered an exact > >> match. Excuse me for getting into this thread with only minor knowledge about perl6, but will there be MMD based on the *value* of parameters? Like Haskell has. Why, yes, see the various Unpacking sections in S06, as well as "where" type constraints. We're st^H^Hadapting as much as we can. :-) Audrey
Re: clarifying the spec for 'ref'
HaloO,
Luke Palmer wrote:
Removing abilities, counterintuitive though it may seem on the
surface, makes the type *larger*. It is not adding constraints, it is
removing them (you might not be able to call set($x) on this object
anymore).
Welcome to the co- and contra-variance problem again. We must
distinguish two sets:
(1) the set of all conceivable instances
(2) the set of constraints
Larry means (2) while Luke is talking about (1) in the
particular case of record subtyping I think. That is
methods are arrow typed slots of the object record (That is
they have type :(Object --> ::X --> ::Y)). Interestingly Perl6
doesn't provide a sound sublanguage for defining constraints
in a way that is amenable for predicate dispatch. I would
expect the where blocks to be under very strict control of the
type system but seemingly they aren't.
In order to resolve the linguistic conundrum of "when Array", we could
say that the Array role in fact implements a constant Array. If you
would like to be a mutable array, you implement MutableArray or
something. That would make code like this:
given $x {
when Array { $x[42] = 42; }
}
broken from a pure point of view. You may not be able to set element
42 of that array. Perl would still allow the code to compile, of
course, because Perl is a laid-back language.
The point is that reference types are co-variant for reading and
contra-variant for writing. The only escape for rw access is mandating
type equality which in Perl6 comes as 'does Array' and has got the
rw interface.
Constness is something that exists, so we have to solve it somehow.
Yes, but it's only half the story! The other thing that has to be
solved is writeonlyness. Both in isolation result in type soundness
in the presence of subtype directed dispatch. But both at the same
time lose this and mandate type equality.
Note that a rw Array is nicely applicable where either a readonly
or writeonly subtype is expected. The only difference is in the
return type handling, of course! Also sharing parts of the Array
implementation is orthogonal to the question of subtyping.
But
pretending that const arrays are arrays with the added capability that
they throw an error when you try to write to them is going to get us
to a broken type model.
I think type inference should be strong enough to find out that
an Array parameter of a sub is consistently used readonly or writeonly
and advertise this property accordingly to the typechecker and the
dispatcher.
Regards,
--
Re: but semantics (was Re: Naming the method form of s///)
HaloO,
Trey Harris wrote:
I do not think that C should mutate its LHS, regardless what its
RHS is.
I strongly agree. We have the mutating version
$p but= { .y = 17 };
which is just one char longer and nicely blends as a meta operator.
But are assignment ops allowed as initializer?
my $z = $p but= { .y = 17 };
Regards,
--
Re: clarify: how WALK arguments can be combined
Mark Stosberg wrote:
In the Objects chapter, a WALK pseudo-class is spec'ed for using
when calling sets of methods:
http://feather.perl6.nl/syn/S12.html#Calling_sets_of_methods
These are the arguments listed that can be used with WALK:
:canonical # canonical dispatch order
:ascendant # most-derived first, like destruction order
:descendant # least-derived first, like construction order
:preorder # like Perl 5 dispatch
:breadth# like multi dispatch
First, it would be nice if the comments "like Perl 5" and "like multi
dispatch" could be expanded, if only to provide references to their
complete specs. Also, if "canonical" means something besides "I don't
care", it would be nice to have a reference for that, too.
I think Class::C3 on CPAN describes and implements the Perl 6 dispatch
algorithm in Perl 5. I don't know if it's in the Synopses, etc.
My concern for the moment is clarification how these options can be
combined. Clearly, combining ":ascendant" and ":descendant" doesn't make
sense.
But, I assume a "self.*meth" call can work along both the inheritance
axis and the multi method access.
Therefore, it seems fair to combine one option that affects each axis.
Wouldn't ":breadth" just be the breadth first order of the same set
of methods? Mentioning multi dispatch kind of confusing...
So I think the permitted combinations are:
One sorting adverb (defaulting to :canonical):
:canonical, :ascendant, :descendant, :preorder, :breadth
Some number of filtering adverbs:
:super # only immediate parent classes
:method # only classes containing method declaration
:omit(Selector) # only classes that don't match selector
:include(Selector) # only classes that match selector
There does seems to be a bit of slack in this section of the Synopsis,
particularly with regard to multi methods. Perhaps I'm just reading
out of context.
As a "use case", in CGI::Application we traverse classes ":ascendant"
but then execute what would be "multi methods" in the order they are
defined, which sounds like perhaps ":preorder" to me.
I'd like to be able to access the list of methods returned by
the WALK traversal. Perhaps it is:
@methods = $object.*WALK::can('meth');
You may want to combine method calls in other ways, with
a short circuiting && or || for example. "last METHOD" could be
used to short-circuit but then the methods can't be composed
using with different logic.
Maybe some of the adverbs above could be replace by a grep on the
method list. Although, a) short-hand++ b) the grep is dynamic
and the adverbs are declarative.
Brad
--
There are two things that will blemish a retainer, these are riches and
honor. But if one remains in strained circumstances he will not be
marred. -- Hagakure http://bereft.net/hagakure/
Re: multi method dispatching of optional arguments (further refined)
On Monday 04 September 2006 16:21, Audrey Tang wrote:
> 2006/9/4, Ph. Marek <[EMAIL PROTECTED]>:
> > Excuse me for getting into this thread with only minor knowledge about
> > perl6, but will there be MMD based on the *value* of parameters? Like
> > Haskell has.
>
> Why, yes, see the various Unpacking sections in S06, as well as "where"
> type constraints. We're st^H^Hadapting as much as we can. :-)
Hello Audrey!
I now had a look at http://dev.perl.org/perl6/doc/design/syn/S06.html but
didn't find what I meant.
Sorry if I'm just dumb and don't understand you (or S06); I'll try to explain
what I mean.
In Haskell you can eg. write:
SomeThing :: Int -> Int -> Int
SomeThing a b
| a = 4 : b+2
| b = 3 : a+1
| otherwise : a*b
or
AnotherThing :: Int -> Int -> Int
AnotherThing 4 b = b+2
AnotherThing b 3 = a+1
AnotherThing a b = a*b
In Perl5 this looks like
sub SomeThing
{
my($a, $b)[EMAIL PROTECTED];
return b+2 if ($a == 4);
return a+1 if ($b == 3);
return a*b;
}
Which is a bit wrong IMO, because the condition should be first.
But
sub SomeThing
{
my($a, $b)[EMAIL PROTECTED];
if ($a == 4) { return b+2 }
if ($b == 3) { return a+1 }
return a*b;
}
is a bit of a hazzle with the {} and repeated if()s.
What I am asking is whether there will be some multimethod dispatch depending
on the *value*, not the *type*, of parameters.
Perl6 could possibly do something with "given"; but matching on multiple
variables seems to be verbose, too.
I'm looking for something in the way of
sub SomeThing(Num $a, Num $b) where $a==4 is $b+2;
sub SomeThing(Num $a, Num $b) where $b==3 is $a+1;
sub SomeThing(Num $a, Num $b) { return $a * $b }
but without specifying the signature multiple times (or maybe we should, since
it's MMD). Now
sub SomeThing(Num $a, Num $b)
{
if $a==4 { return $b+2;}
if $b==3 { return $a+1;}
return $a * $b;
}
would almost do what I want, but I don't know if the compiler would optimize
that in the way it could for direct MMD depending on types.
Regards,
Phil
Re: multi method dispatching of optional arguments (further refined)
In a message dated Tue, 5 Sep 2006, Ph. Marek writes:
I now had a look at http://dev.perl.org/perl6/doc/design/syn/S06.html
but didn't find what I meant. Sorry if I'm just dumb and don't
understand you (or S06); I'll try to explain what I mean.
I don't think you're dumb; the Synopses just require that you intuit
certain things from each other, from examples in other Synopses, and so on
in a Perlish sort of way; what you're looking for is not spelled out
explicitly. It can be found by noticing how you specify subtypes, along
with noticing that subtypes can be specified as parameter types. There's
also an example showing explicitly what you want in S12.
In Perl5 this looks like
sub SomeThing
{
my($a, $b)[EMAIL PROTECTED];
return b+2 if ($a == 4);
return a+1 if ($b == 3);
return a*b;
}
[...]
What I am asking is whether there will be some multimethod dispatch depending
on the *value*, not the *type*, of parameters.
Perl6 could possibly do something with "given"; but matching on multiple
variables seems to be verbose, too.
I'm looking for something in the way of
sub SomeThing(Num $a, Num $b) where $a==4 is $b+2;
sub SomeThing(Num $a, Num $b) where $b==3 is $a+1;
sub SomeThing(Num $a, Num $b) { return $a * $b }
It's just
multi sub SomeThing(Num $a where {$^a == 4}, Num $b) { $b + 2 }
multi sub SomeThing(Num $a, Num $b where {$^b == 3}) { $a + 1 }
multi sub SomeThing(Num $a, Num $b) { $a * $b }
but without specifying the signature multiple times (or maybe we should, since
it's MMD). Now
Yes, the signatures are different--the first two multis specify subtypes
as their signatures, the last specifies a canonical type.
Trey
Re: multi method dispatching of optional arguments (further refined)
On Tuesday 05 September 2006 07:52, Trey Harris wrote:
> I don't think you're dumb; the Synopses just require that you intuit
> certain things from each other, from examples in other Synopses, and so on
> in a Perlish sort of way; what you're looking for is not spelled out
> explicitly. It can be found by noticing how you specify subtypes, along
> with noticing that subtypes can be specified as parameter types. There's
> also an example showing explicitly what you want in S12.
Ok, I'll try to dive through the documentation before asking questions.
> It's just
>
> multi sub SomeThing(Num $a where {$^a == 4}, Num $b) { $b + 2 }
> multi sub SomeThing(Num $a, Num $b where {$^b == 3}) { $a + 1 }
> multi sub SomeThing(Num $a, Num $b) { $a * $b }
>
> Yes, the signatures are different--the first two multis specify subtypes
> as their signatures, the last specifies a canonical type.
Thank you *very* much! That clears it up.
Regards,
Phil
