Re: Polymorphism and Representations (Was: Re: First look: Advanced Polymorphism whitepaper)
HaloO,
Daniel Ruoso wrote:
hrmm... I might just be overlooking something... but...
sub foo (Point $p) {...}
means...
$signature ~~ $capture
means...
Point $p := $capture[0]
means...
$capture[0] ~~ Point
means...
$capture[0].^does(Point)
The thing is the .^does traverses the meta information
to find the *named* concept Point. The FoxPoint in John's
example doesn't have that and thus nominally fails the
Point test. The idea is now to also have
sub foo (Point $p) {...}
to mean
$capture[0].^like(Point)
which does a *structural* analysis.
Regards, TSa.
--
The unavoidable price of reliability is simplicity -- C.A.R. Hoare
1 + 2 + 3 + 4 + ... = -1/12 -- Srinivasa Ramanujan
Re: First look: Advanced Polymorphism whitepaper
HaloO chromatic, you wrote: That was always my goal for roles in the first place. I'll be a little sad if Perl 6 requires an explicit notation to behave correctly here -- that is, if the default check is for subtyping, not polymorphic equivalence. What is polymorphic equivalence to you? I remember us discussion the issue of duck typing versus nominal typing. I'll try to dig that out. But here is a version from memory using John's pointlike role: %hx y new midpoint = T.new(1), T.new(2), new, midpoint; where new and midpoint refer to code objects with applicable signature. Then I think that we have %h.does(Point) === False; %h.like(Point) === True; with the second test being more elaborate and hence more expensive. Regards, TSa. -- The unavoidable price of reliability is simplicity -- C.A.R. Hoare 1 + 2 + 3 + 4 + ... = -1/12 -- Srinivasa Ramanujan
Re: First look: Advanced Polymorphism whitepaper
HaloO, Jon Lang wrote: What, if anything, is the significance of the fact that pointlike (in John's example; 'Point' in TSa's counterexample) is generic? Note that I didn't give a counterexample. I just used different syntax. Here values and types behave very similar. On the value level you can check 3 + 4 == 7. In a generic addition 3 + $x == 7 you can do two different things. First you can check the truths for different values of $x or you can *solve* for $x. The latter also happens in higher order type checks but of course with type variables. The type system signals an error if it can't find a suitable solution given the constraints. E.g. on the value level my Int $x; $x + $x == 7; is unsolvable. The same can happen on type level. Hope that helps, TSa. -- The unavoidable price of reliability is simplicity -- C.A.R. Hoare 1 + 2 + 3 + 4 + ... = -1/12 -- Srinivasa Ramanujan
Re: Polymorphism and Representations (Was: Re: First look: Advanced Polymorphism whitepaper)
HaloO,
Daniel Ruoso wrote:
.^does *might* traverse the information as well as simply return true if
the object says so.
Let's not regard the problem of meta level interoperation for now.
That is we have *one* meta level. The spec says that .^does asks
this meta system. Now the meta system does not invent the answer!
The programmer of FoxPoint has to declare that explicitly via
class FoxPoint does Point {...}
The point here is whom to delegate the association between FoxPoint and
Point...
I see only two systems: the meta and the type system. The latter is
still underspecced. Even more unspecced is their interrelation.
If we are to define an operator to declare that some arbitrary object
conforms to some API, I would think the following as saner...
sub foo(Point $p) {...};
FoxPoint $fp = ...;
$fp realises Point;
foo($fp);
Here the spec is quite clear that 'realises' is spelled 'does'.
This is the infix operator that composes a role into an object's
class at runtime.
This way, the dispatching mechanism is still the same (and still typed),
but the object now also answers true to .^does(Point).
But note that
FoxPoint $fp = ...;
$y = $fp;
$y === $fp; # obviously true
$fp does Point;
$y === $fp; # false because of different HOW?
Unfortunately S03 doesn't say if === checks for the same WHAT or the
same HOW as precondition to checking the WHICH. Generally WHAT is also
quite underspecced.
Which means that the typed code remains typed and the feature is
implemented as a trait that can be used to any object, thus leaving the
fragile type inference to the code calling the method and not to the
method that wants a stronger typing...
I don't understand what you want to say here.
Regards, TSa.
--
The unavoidable price of reliability is simplicity -- C.A.R. Hoare
1 + 2 + 3 + 4 + ... = -1/12 -- Srinivasa Ramanujan
The Inf type
John M. Dlugosz wrote: I wrote a complete treatment of Inf support. Please take a look at 24.26 Infinite on pages 116-119, and 3.11.3 Infinities on pages 26-27. I have a lot to say to that. Please give me time. Regards, TSa. -- The unavoidable price of reliability is simplicity -- C.A.R. Hoare 1 + 2 + 3 + 4 + ... = -1/12 -- Srinivasa Ramanujan
Re: Polymorphism and Representations (Was: Re: First look: Advanced Polymorphism whitepaper)
Ter, 2008-04-29 às 09:28 +0200, TSa escreveu:
The thing is the .^does traverses the meta information
to find the *named* concept Point. The FoxPoint in John's
example doesn't have that and thus nominally fails the
Point test. The idea is now to also have
.^does *might* traverse the information as well as simply return true if
the object says so.
The point here is whom to delegate the association between FoxPoint and
Point...
If we are to define an operator to declare that some arbitrary object
conforms to some API, I would think the following as saner...
sub foo(Point $p) {...};
FoxPoint $fp = ...;
$fp realises Point;
foo($fp);
This way, the dispatching mechanism is still the same (and still typed),
but the object now also answers true to .^does(Point).
Which means that the typed code remains typed and the feature is
implemented as a trait that can be used to any object, thus leaving the
fragile type inference to the code calling the method and not to the
method that wants a stronger typing...
daniel
Re: Polymorphism and Representations (Was: Re: First look: Advanced Polymorphism whitepaper)
Ter, 2008-04-29 às 11:54 +0200, TSa escreveu:
If we are to define an operator to declare that some arbitrary object
conforms to some API, I would think the following as saner...
sub foo(Point $p) {...};
FoxPoint $fp = ...;
$fp realises Point;
foo($fp);
Here the spec is quite clear that 'realises' is spelled 'does'.
This is the infix operator that composes a role into an object's
class at runtime.
Not really... 'does' is a composition operation, 'realises' would be
just a type annotation that doesn't change the actual composition.
This way, the dispatching mechanism is still the same (and still typed),
but the object now also answers true to .^does(Point).
But note that
FoxPoint $fp = ...;
$y = $fp;
$y === $fp; # obviously true
$fp does Point;
$y === $fp; # false because of different HOW?
Wrong. $fp is still the same object and $y would also answer true
to .^does(Point). it's an in-place change, not a copy. you would need to
do
$y = $fp.clone();
to keep the non-typed version.
Unfortunately S03 doesn't say if === checks for the same WHAT or the
same HOW as precondition to checking the WHICH.
It doesn't. By definition. === only checks WHICH.
Generally WHAT is also quite underspecced.
WHAT is implementation specific, it's underspecced for that reason.
Which means that the typed code remains typed and the feature is
implemented as a trait that can be used to any object, thus leaving the
fragile type inference to the code calling the method and not to the
method that wants a stronger typing...
I don't understand what you want to say here.
I mean, the code that is calling the method would be the one doing the
untyped-typed mapping, not the calling sub signature (which would make
the dispatch much slower).
daniel
Re: Polymorphism and Representations (Was: Re: First look: Advanced Polymorphism whitepaper)
HaloO,
Daniel Ruoso wrote:
Not really... 'does' is a composition operation, 'realises' would be
just a type annotation that doesn't change the actual composition.
OK, but that is not in the spec yet. To me that is like the
proposed 'like' operator but with the programmer taking full
responsibility. Like reinterpret_cast in C++.
This way, the dispatching mechanism is still the same (and still typed),
but the object now also answers true to .^does(Point).
But note that
FoxPoint $fp = ...;
$y = $fp;
$y === $fp; # obviously true
$fp does Point;
$y === $fp; # false because of different HOW?
Wrong. $fp is still the same object and $y would also answer true
to .^does(Point). it's an in-place change, not a copy. you would need to
do
$y = $fp.clone();
First of all assignment has copy semantics. That is after $y = $fp,
$y =:= $fp is false. I agree that
$before := $fp;
$fp does Point;
$fp =:= $before; # maintain referential identity
But either the HOW, the WHAT or both of $fp have to change
which implies that $y === $fp can't remain true after
$fp does Point. BTW, an interesting question is if a typed
binding could become invalid:
subset AntiPoint of Any where {not .^does(Point)}
my AntiPoint $ap := $fp; # fine for now
$fp does Point; # now $ap is bound to a Point which
# violates the AntiPoint constraint
It doesn't. By definition. === only checks WHICH.
Then we must read different versions of S03. Mine has the
sentence Two values are never equivalent unless they are
of exactly the same type.
Regards, TSa.
--
The unavoidable price of reliability is simplicity -- C.A.R. Hoare
1 + 2 + 3 + 4 + ... = -1/12 -- Srinivasa Ramanujan
Re: Polymorphism and Representations
Hmm, I'm not seeing the message from Daniel, just this reply.
I like the idea of having a class method primitive to provide some
functionality. But type matching is more complex, as you can list
multiple types juxtaposed.
sub foo (A B £ C ::T $param)
and the actual match means does A, does B, and like C must all pass.
Also, note that ^like Point does more than just structure checking: it
doesn't check against Point as it exists, but what Point would become
(virtual type redefinitions) if it were declared as a direct base class,
and also doesn't mean Point[defaultargument] but deduced generic
arguments to Point-as-a-base-class that would work.
--John
TSa Thomas.Sandlass-at-barco.com |Perl 6| wrote:
HaloO,
Daniel Ruoso wrote:
hrmm... I might just be overlooking something... but...
sub foo (Point $p) {...}
means...
$signature ~~ $capture
means...
Point $p := $capture[0]
means...
$capture[0] ~~ Point
means...
$capture[0].^does(Point)
The thing is the .^does traverses the meta information
to find the *named* concept Point. The FoxPoint in John's
example doesn't have that and thus nominally fails the
Point test. The idea is now to also have
sub foo (Point $p) {...}
to mean
$capture[0].^like(Point)
which does a *structural* analysis.
Regards, TSa.
Re: Polymorphism and Representations (Was: Re: First look: Advanced Polymorphism whitepaper)
HaloO,
Daniel Ruoso wrote:
So...
class A { has $.a; method inc { $.a++ } };
$a = A.new( a = 0);
$b = $a;
$b.inc();
$a.inc();
say $a.a; # 2
say $b.a; # 2
Will work as expected.
Depends a bit on one's expectations :)
So infix:= has shallow copy semantics. IIRC, there was once
an 'is deep' trait. Otherwise one has to implement
multi infix:= (Any $lhs, A $rhs)
{
$lhs.STORE($rhs.clone); # or .cow if that's not automatic
}
But either the HOW, the WHAT or both of $fp have to change
That is true
So, even though the WHICH stays the eqv check has to change:
$a = A.new( a = 0); # your class A
$b = A.new( a = 0);
$a === $b; # False, but
$a eqv $b; # True because of snapshot semantic
$b does Point;
$a eqv $b; # False because HOW or WHAT is different
BTW, is WHICH globally unique? Or is that also an
implementation detail?
The snapshot check is of course type aware:
class B { has $.a; method inc { $.a++ } };
$a = A.new( a = 0); # your class A
$b = B.new( a = 0); # same structural type
$a eqv $b; # False because of type mismatch
Funnily this implies we also need a version of eqv
that uses like or duck semantics. But this seems to
be foreseen. Could someone post the signature to use
for eqv() to make $a and $b to compare equal structurally
here? Is it eqv($a, $b, :(like A, like A))? Perhaps
that can be abbreviated to eqv($a, $b, :like)? Or even
infix:like with the rational that this always is a
test not a modifying call like infix:does. But I would
like to reserve infix:like for a type check without
subsequent canonical value comparison. That is continuing
from above
$b.inc;
$a like $b; # still true even though $a.a != $b.a
Or the structural type test is similar to .does
$a .like: $b;
BTW, an interesting question is if a typed
binding could become invalid:
subset AntiPoint of Any where {not .^does(Point)}
my AntiPoint $ap := $fp; # fine for now
$fp does Point; # now $ap is bound to a Point which
# violates the AntiPoint constraint
This is a composition error that generates an exception. It even
provides enough information for a compile-time error.
Where is it raised? In the '$fp does Point;' statement with
the error can't compose role Point because of AntiPoint binding
to $ap? How would that change if the line read
my AntiPoint $ap = $fp; # or with real assignment
# after the declaration
Would it say can't compose role Point because of AntiPoint
reference in $ap? How far does that reach? I mean does the
meta object system know about the constraints of all bindings
and stored references to an object?
Regards, TSa.
--
The unavoidable price of reliability is simplicity -- C.A.R. Hoare
1 + 2 + 3 + 4 + ... = -1/12 -- Srinivasa Ramanujan
Re: Polymorphism and Representations (Was: Re: First look: Advanced Polymorphism whitepaper)
TSa Thomas.Sandlass-at-barco.com |Perl 6| wrote:
HaloO,
Daniel Ruoso wrote:
Not really... 'does' is a composition operation, 'realises' would be
just a type annotation that doesn't change the actual composition.
OK, but that is not in the spec yet. To me that is like the
proposed 'like' operator but with the programmer taking full
responsibility. Like reinterpret_cast in C++.
I've not gotten that far yet, but I do envision a way to test for
conformance rather than mix-in to create conformance and change things
around. There might be a more primitive operation for doing than than
binding a capture to a signature.
I also envision that this can give the compiler information that it uses
to make a cached dispatch table, but this is not visible to the user.
It just means that declaring your types, even duck types will not only
give compile-time checking but speed up calling for that variable.
But either the HOW, the WHAT or both of $fp have to change
which implies that $y === $fp can't remain true after
$fp does Point. BTW, an interesting question is if a typed
binding could become invalid:
subset AntiPoint of Any where {not .^does(Point)}
my AntiPoint $ap := $fp; # fine for now
$fp does Point; # now $ap is bound to a Point which
# violates the AntiPoint constraint
It's not different than
my Int $y = 5;
subset X of Int where { $_ 5 }
my X $x := $y;
++$y;
The subset is part of the type of the item container. You alias it to
something which is a different type of container. How can such aliasing
ever be other than non-variant to be correct, unless the alias is read-only?
That's no different than defining a symbol with container type
MyTiedItem and then trying to alias it to a plain Scalar. Type mismatch
in the := operation.
--John
Re: Polymorphism and Representations (Was: Re: First look: Advanced Polymorphism whitepaper)
TSa Thomas.Sandlass-at-barco.com |Perl 6| wrote:
multi infix:= (Any $lhs, A $rhs)
{
$lhs.STORE($rhs.clone); # or .cow if that's not automatic
}
$lhs.VAR.STORE.
My readings have been that = just copies the ref. Unless it's a value
type or immutable which just means that it doesn't matter. I'll have
to read up on that some more soon.
--John
[svn:perl6-synopsis] r14539 - doc/trunk/design/syn
Author: larry
Date: Tue Apr 29 13:32:24 2008
New Revision: 14539
Modified:
doc/trunk/design/syn/S05.pod
Log:
foo: ... is now just alternate method call syntax, use foo: 'text' for
strings
Modified: doc/trunk/design/syn/S05.pod
==
--- doc/trunk/design/syn/S05.pod(original)
+++ doc/trunk/design/syn/S05.podTue Apr 29 13:32:24 2008
@@ -14,9 +14,9 @@
Maintainer: Patrick Michaud [EMAIL PROTECTED] and
Larry Wall [EMAIL PROTECTED]
Date: 24 Jun 2002
- Last Modified: 19 Mar 2008
+ Last Modified: 29 Apr 2008
Number: 5
- Version: 76
+ Version: 77
This document summarizes Apocalypse 5, which is about the new regex
syntax. We now try to call them Iregex rather than regular
@@ -1157,13 +1157,12 @@
To pass a regex with leading whitespace you must use the parenthesized form.
-If the first character is a colon, the rest of the text (following any
-whitespace) is passed as a string, so the previous may also be written as:
+If the first character is a colon followed by whitespace, the rest
+of the text is taken as a list of arguments to the method, just as
+in ordinary Perl syntax. So these mean the same thing:
-foo: bar
-
-To pass a string with leading whitespace, or to interpolate any values
-into the string, you must use the parenthesized form.
+foo('foo', $bar, 42)
+foo: 'foo', $bar, 42
No other characters are allowed after the initial identifier.
@@ -1182,6 +1181,15 @@
/ .ident ws / # only $/ws captured
/ .ident .ws / # nothing captured
+The assertion is otherwise parsed identically to an assertion beginning with
+an identifier, provided the next thing after the dot is an identifier.
Otherwise it
+is parsed as a dotty postfix of some type, such as an indirect method call:
+
+.$indirect($depth, $binding, $fate, @args)
+
+In this case the object passed as the invocant is the current match
+state, and the method is expected to return a new match state object.
+
The non-capturing behavior may be overridden with a C:keepall.
=item *
[svn:perl6-synopsis] r14540 - doc/trunk/design/syn
Author: larry Date: Tue Apr 29 13:42:15 2008 New Revision: 14540 Modified: doc/trunk/design/syn/S05.pod Log: clarifications to previous change Modified: doc/trunk/design/syn/S05.pod == --- doc/trunk/design/syn/S05.pod(original) +++ doc/trunk/design/syn/S05.podTue Apr 29 13:42:15 2008 @@ -1182,13 +1182,19 @@ / .ident .ws / # nothing captured The assertion is otherwise parsed identically to an assertion beginning with -an identifier, provided the next thing after the dot is an identifier. Otherwise it +an identifier, provided the next thing after the dot is an identifier. As with +the identifier form, any extra arguments pertaining to the matching engine +are automatically supplied to the argument list. + +If the dot is not followed by an identifier, it is parsed as a dotty postfix of some type, such as an indirect method call: .$indirect($depth, $binding, $fate, @args) In this case the object passed as the invocant is the current match state, and the method is expected to return a new match state object. +The extra pattern matching arguments (C$depth, C$binding, and +C$fate) must be supplied explicitly. The non-capturing behavior may be overridden with a C:keepall.
Re: Polymorphism and Representations (Was: Re: First look: Advanced Polymorphism whitepaper)
[ I'm using this message to reply, because I didn't receive your reply... I'm taking it from the list history... There really seems to be something wrong with this list... ] TSa wrote: BTW, is WHICH globally unique? Or is that also an implementation detail? This is not specced apparently to leave room for decision in the implementation. But there's an important question to be answered before that... what is the type returned by WHICH? I haven't implemented that in SMOP yet (because I have the constant identifiers that allow me to make simple pointer comparison), but I think in the low-level it will end-up being something like a native binary blob. Which means that every non-native type will, in the end, have to be reduced to native types in the WHICH call to provide a proper value for comparison. TSa wrote: So, even though the WHICH stays the eqv check has to change: $a = A.new( a = 0); # your class A $b = A.new( a = 0); $a === $b; # False, but $a eqv $b; # True because of snapshot semantic $b does Point; $a eqv $b; # False because HOW or WHAT is different But it's important to keep in mind that eqv behaviour might also be overriden by the object, that might give a canonical representation that matches the other object. An implementation of the 'realises' trait could make its canonical representation unchanged. As I said earlier, 'does' is an composition operator, it will change the class composition, therefore making it a different object. On the other hand, a 'realises' trait could change the object in order that it would still match with both 'eqv' and '===', while still '~~' to an additional type. This would be done simply by creating an anonymous class that isa the original class while overriding .^does, WHICH and eqv to shadow to the original class, and then re-blessing the object to this anonymous class. TSa wrote: But I would like to reserve infix:like for a type check without subsequent canonical value comparison. That is continuing from above $b.inc; $a like $b; # still true even though $a.a != $b.a It doesn't need to be part of the spec, it's a simple module that traverses .^methods to check if $a implements all methods described by $b. You might want to implement it already in other to reserve the name ;). daniel
Jonathan Worthington receives Perl 6 Microgrant
We're pleased to announce that we've selected Jonathan Worthington as a recipient of a Perl 6 microgrant. Jonathan is one of the top contributors to Rakudo Perl 6 and has been contributing to Parrot since 2003. The grant will be for travel and accommodation to the French Perl Workshop and the Nordic Perl Workshop. Jonathan will speak at both workshops on topics including the Rakudo Perl 6 implementation, Perl and Perl 6 as languages for academic use and the Perl 6 type system. Please join us in wishing him the best of luck with his project. We're really looking forward to seeing the details of his talks.If you're interested in submitting a Perl 6 microgrant proposal, you can find details here: http://www.nntp.perl.org/group/perl.perl5.porters/2007/03/msg122448.html Leon and Jesse PGP.sig Description: This is a digitally signed message part
treatment of isa and inheritance
In response to questions on my whitepaper, I made this companion to bring people up to speed on the issue. http://www.dlugosz.com/Perl6/web/isa-inheritance.html Think you know what “polymorphism” means? Well, the Object-Oriented textbooks have been keeping a dirty little secret from you. Polymorphism isn’t just the base/derived reuse capability you know from modern languages. That is just one limited way that these languages support polymorphism. If you’ve done any template metaprogramming or used the C++ STD much, you might be seeing another way to support it.
Re: Polymorphism and Representations (Was: Re: First look: Advanced Polymorphism whitepaper)
Ter, 2008-04-29 às 14:21 +0200, TSa escreveu:
Daniel Ruoso wrote:
Not really... 'does' is a composition operation, 'realises' would be
just a type annotation that doesn't change the actual composition.
OK, but that is not in the spec yet. To me that is like the
proposed 'like' operator but with the programmer taking full
responsibility. Like reinterpret_cast in C++.
It doesn't need to be. New traits can be implemented later.
First of all assignment has copy semantics. That is after $y = $fp,
$y =:= $fp is false. I agree that
It will copy the scalar, which means that later change in the value cell
won't propagate to the other variable. But both cells point to the same
value.
$a = $b;
$a === $b; # TRUE
$a =:= $b; # FALSE
$b = $c;
$a === $b; # FALSE
As opposed to
$a := $b;
$a === $b; # TRUE
$a =:= $b; # TRUE
$b = $c;
$a === $b; # TRUE
In the later, the scalar itself is copied, which means that both
variables *are* the same scalar, and changing the cell value in one is
the same as changing the cell value in the other.
So...
class A { has $.a; method inc { $.a++ } };
$a = A.new( a = 0);
$b = $a;
$b.inc();
$a.inc();
say $a.a; # 2
say $b.a; # 2
Will work as expected.
But either the HOW, the WHAT or both of $fp have to change
That is true
which implies that $y === $fp can't remain true after
$fp does Point
Not really... see below...
BTW, an interesting question is if a typed
binding could become invalid:
subset AntiPoint of Any where {not .^does(Point)}
my AntiPoint $ap := $fp; # fine for now
$fp does Point; # now $ap is bound to a Point which
# violates the AntiPoint constraint
This is a composition error that generates an exception. It even
provides enough information for a compile-time error.
It doesn't. By definition. === only checks WHICH.
Then we must read different versions of S03. Mine has the
sentence Two values are never equivalent unless they are
of exactly the same type.
*Value types*!!! Which is not the case here, we are talking about
*Object types*, also in S03:
for two mutable types (object types), checks whether they have the
same identity value. (For most such types the identity is simply the
reference itself.)
Which means that (continuing the code starting with class A)...
$a = A.new(a = 0);
$b = $a;
$a === $b; # TRUE
$b.inc;
$a === $b; # TRUE
daniel
