The False Cognate problem and what Roles are still missing

[Aristotle Pagaltzis]

Hi $Larry et al,

I brought this up as a question at YAPC::EU and found to my
surprise that no one seems to have thought of it yet. This is
the mail I said I’d write. (And apologies, Larry. :-) )

Consider the classic example of roles named Dog and Tree which
both have a `bark` method. Then there is a class that for some
inexplicable reason, assumes both roles. Maybe it is called
Mutant. This is standard fare so far: the class resolves the
conflict by renaming Dog’s `bark` to `yap` and all is well.

But now consider that Dog has a method `on_sound_heard` that
calls `bark`.

You clearly don’t want that to suddenly call Tree’s `bark`.

Unless, of course, you actually do.

It therefore seems necessary to me to specify dispatch such that
method calls in the Dog role invoke the original Dog role methods
where such methods exist. There also needs to be a way for a
class that assumes a role to explicitly declare that it wants
to override that decision. Thus, by default, when you say that
Mutant does both Dog and Tree, Dog’s methods do not silently
mutate their semantics. You can cause them to do so, but you
should have to ask for that.

I am, as I mentioned initially, surprised that no one seems to
have considered this issue, because I always thought this is what
avoiding the False Cognate problem of mixins, as chromatic likes
to call it, ultimately implies at the deepest level: that roles
provide scope for their innards that preserves their identity and
integrity (unless, of course, you explicitly stick your hands in),
kind of like the safety that hygienic macros provide.

Regards,
-- 
Aristotle Pagaltzis // <http://plasmasturm.org/>

Re: Question about .sort and .reduce

[Larry Wall]

On Fri, Jul 11, 2008 at 09:01:09AM -0500, Patrick R. Michaud wrote:
: I'm not entirely certain if any of the following 
: examples with adverbial blocks would also work.  I'm guessing
: they do, but could use confirmation.
: 
: sort @a, :{ $^a <=> $^b };
: sort @a :{ $^a <=> $^b };
: sort :{ $^a <=> $^b }, @a;
: @a.sort: :{ $^a <=> $^b };

I think they all work, but the second one is fragile and will break
if you replace @a with an expression containing an operator that the
adverb would attach itself to instead of to the sort, since adverbs
in infix position always pick the most recent operator (that isn't
hidden inside brackets or parens).

Larry

Re: Question about .sort and .reduce

[Larry Wall]

On Fri, Jul 11, 2008 at 03:27:26PM +0200, TSa wrote:
> HaloO,
>
> Patrick R. Michaud wrote:
>> S29 doesn't show a 'sort' method defined on block/closure
>> invocants... should there be?  
>
> I doubt that. And to my eyes it looks funny. Only real block
> methods should be useful and since the class is mostly known
> at parse time unapplicable methods should be a compile error.
>
>my &f = { $^a <=> $^b }.assuming($^a = 3);
>
>say f(3); # prints 0
>
> Would that be valid? I mean the usuage of automatic variables
> in the assuming method?

No, that could not work, because $^a = 3 would be in an rvalue context
and refer to the block around the entire statement as a different
parameter.  Setting a named parameter with .assuming must use named
argument notation:

my &f = { $^a <=> $^b }.assuming(:a(3));

Also, it may well be that f(3) will say Order::Same rather than 0.  :)

Larry

Re: Question about .sort and .reduce

[Patrick R. Michaud]

On Fri, Jul 11, 2008 at 03:27:26PM +0200, TSa wrote:
> >Note that we already have:
> >
> >my @s = sort { $^a <=> $^b }, @a;
> >my @s = @a.sort { $^a <=> $^b };
> 
> Is that the adverbial block syntax? If not how
> would it look?

The adverbial block syntax would be:

@a.sort:{ $^a <=> $^b };
sort(@a) :{ $^a <=> $^b };

I'm not entirely certain if any of the following 
examples with adverbial blocks would also work.  I'm guessing
they do, but could use confirmation.

sort @a, :{ $^a <=> $^b };
sort @a :{ $^a <=> $^b };
sort :{ $^a <=> $^b }, @a;
@a.sort: :{ $^a <=> $^b };

Pm

Re: Question about .sort and .reduce

[TSa]

HaloO,

Patrick R. Michaud wrote:

S29 doesn't show a 'sort' method defined on block/closure
invocants... should there be?  


I doubt that. And to my eyes it looks funny. Only real block
methods should be useful and since the class is mostly known
at parse time unapplicable methods should be a compile error.

   my &f = { $^a <=> $^b }.assuming($^a = 3);

   say f(3); # prints 0

Would that be valid? I mean the usuage of automatic variables
in the assuming method?



Note that we already have:

my @s = sort { $^a <=> $^b }, @a;
my @s = @a.sort { $^a <=> $^b };


Is that the adverbial block syntax? If not how
would it look?

  my @s = sort @a :{ $^a <=> $^b };

Or with a comma after @a?


Regards, TSa.
--

"The unavoidable price of reliability is simplicity" -- C.A.R. Hoare
"Simplicity does not precede complexity, but follows it." -- A.J. Perlis
1 + 2 + 3 + 4 + ... = -1/12  -- Srinivasa Ramanujan

Question about .sort and .reduce

[Patrick R. Michaud]

t/spec/S29-list/sort.t has the following test:

my @a = (2, 45, 6, 1, 3);
my @e = (1, 2, 3, 6, 45);
my @s = { $^a <=> $^b }.sort: @a;
is(@s, @e, '... with closure as direct invocant');

S29 doesn't show a 'sort' method defined on block/closure
invocants... should there be?  

Note that we already have:

my @s = sort { $^a <=> $^b }, @a;
my @s = @a.sort { $^a <=> $^b };

A similar question applies for .reduce in S29-list/reduce.t :

is(({ $^a * $^b }.reduce: 1,2,3,4,5), 120, "basic reduce works (3)");

Thanks!

Pm

spaces and transliteration

[Chris Fields]

I am working on the transliteration method operator (trans()) for  
Rakudo and wanted to get some input on how character ranges are to be  
used.


Should spaces be ignored in ranges like 'A .. Z'?  Currently the  
implementation I have ignores those spaces but counts any other spaces  
as important, so (using parrot perl6.pbc with my patch):


> say "Whfg nabgure Crey unpxre".trans(' a .. z' => '_n .. za .. m',  
'A .. Z' => 'N .. ZA .. M')

Just_another_Perl_hacker

chris

spaces and transliteration

[Chris Fields]

I am working on the transliteration method operator (trans()) for  
Rakudo and wanted to get some input on how character ranges are to be  
used.


Should spaces be ignored in ranges like 'A .. Z'?  Currently the  
implementation I have ignores those spaces but counts any other spaces  
as important, so (using parrot perl6.pbc with my patch):


> say "Whfg nabgure Crey unpxre".trans(' a .. z' => '_n .. za .. m',  
'A .. Z' => 'N .. ZA .. M')

Just_another_Perl_hacker

chris

Re: Should C and C work in C ?

[Patrick R. Michaud]

On Tue, Jul 01, 2008 at 05:36:26PM +0200, TSa wrote:
> This would save lots of overloads in Any in favor of a handful of
> standard coercions. These need proper anchorage in the dispatch
> system, of course. That to me means we need some definition of
> "conversion quality" and "conversion distance".

So far in Rakudo we haven't done any "overloads in Any" --
what has happened instead is that the methods in question have
simply moved into the Any class and out of whatever class they
were in previously.

Pm

Re: Should C and C work in C ?

[TSa]

HaloO,

Larry Wall wrote:

On Mon, Jun 30, 2008 at 07:25:11AM -0500, Patrick R. Michaud wrote:
: I'm suspecting that the answer is "yes, they are universal",
: but wanted to confirm it.

Confirmed.  (Though note that Str.reverse probably overrides
Any.reverse, unless we give string reversal a different name.)


Just a thought from my side: doesn't it make sense to unify the
concept of numeric conversion as discussed recently and the
universal methods in Any? The idea is that after a failed dispatch
of 'foo'.join(':') a coercion 'Item as List' is invoked and a one
element list dispatch ('foo',).join(':') is attempted and succeeds.
Note that a round-trip conversion 'Item as List' and 'List as Item'
is lossless and perhaps even identity preserving---that is WHICH
remains unaltered but WHAT switches from Item to List and back.

This would save lots of overloads in Any in favor of a handful of
standard coercions. These need proper anchorage in the dispatch
system, of course. That to me means we need some definition of
"conversion quality" and "conversion distance".


Regards, TSa.
--

"The unavoidable price of reliability is simplicity" -- C.A.R. Hoare
"Simplicity does not precede complexity, but follows it." -- A.J. Perlis
1 + 2 + 3 + 4 + ... = -1/12  -- Srinivasa Ramanujan

Re: Should C and C work in C ?

[Larry Wall]

On Mon, Jun 30, 2008 at 07:25:11AM -0500, Patrick R. Michaud wrote:
: So my question is really whether or not we consider grep and 
: reverse to be universal methods in this sense also, so that
: C< $x.grep(...) > and C< $x.reverse > will work even if $x 
: isn't a value that normally does list-type operations.  
: 
: I'm suspecting that the answer is "yes, they are universal",
: but wanted to confirm it.

Confirmed.  (Though note that Str.reverse probably overrides
Any.reverse, unless we give string reversal a different name.)

Larry

Re: Should C and C work in C ?

[Patrick R. Michaud]

On Mon, Jun 30, 2008 at 07:25:11AM -0500, Patrick R. Michaud wrote:
> Moritz is correct -- in order to get ('foo').join(':') to work as
> people will expect, it was decided to define "universal" methods
> in the Any class as part of the prelude [1].

I forgot to include the reference link:

1.  http://groups.google.com/group/perl.perl6.compiler/msg/acf1cfbb16b998cf

Pm

Re: Should C and C work in C ?

[Patrick R. Michaud]

On Mon, Jun 30, 2008 at 01:43:11PM +0200, Moritz Lenz wrote:
> Ovid wrote:
> > --- On Sun, 29/6/08, Patrick R. Michaud <[EMAIL PROTECTED]> wrote:
> > 
> >> Do C and C act like the
> >> C method, in that
> >> they work for C object and not just objects of
> >> type C?
> >> 
> >> In other words,, should  C< $x.grep(...) >  work even
> >> if $x isn't normally a list type?
> > 
> > If I understand you correctly, I think you're asking if grep and map can be 
> > applied to junctions?  
> 
> I think Patrick meant something else.
> 
> The other day we had the discussion what $x.join($sep) should be,
> specifically if it should work for non-List $x. $Larry said yes, it
> should work, and the way to achieve that is to use Any.join.
> Now Patrick wants to know which of the various list methods need to be
> in Any.

Moritz is correct -- in order to get ('foo').join(':') to work as
people will expect, it was decided to define "universal" methods
in the Any class as part of the prelude [1].

So my question is really whether or not we consider grep and 
reverse to be universal methods in this sense also, so that
C< $x.grep(...) > and C< $x.reverse > will work even if $x 
isn't a value that normally does list-type operations.  

I'm suspecting that the answer is "yes, they are universal",
but wanted to confirm it.

Thanks!

Pm

Re: Should C and C work in C ?

[Trey Harris]

In a message dated Mon, 30 Jun 2008, Ovid writes:
I just noticed you included 'reverse' in that list of methods.  I 
thought junctions were inherently unordered, thus making reverse 
kind of useless (which leads me even more to believe that I've 
misunderstood the question).


Yes--Junction is a sister of Any, not a subtype of Any.  That's how 
you get the autothreading--accept Any or a subtype thereof, and when 
you get a junction, you autothread.  Accept Junction or Object and you 
can inspect the junction directly.


At least, that's how *I* think it works... :)

--
Trey Harris  http://www.lopsa.org/
President, LOPSA   -- The League of Professional System Administrators
Opinions expressed above are not necessarily those of LOPSA.

Re: Should C and C work in C ?

[Moritz Lenz]

Ovid wrote:
> --- On Sun, 29/6/08, Patrick R. Michaud <[EMAIL PROTECTED]> wrote:
> 
>> Do C and C act like the
>> C method, in that
>> they work for C object and not just objects of
>> type C?
>> 
>> In other words,, should  C< $x.grep(...) >  work even
>> if $x isn't normally a list type?
> 
> If I understand you correctly, I think you're asking if grep and map can be 
> applied to junctions?  

I think Patrick meant something else.

The other day we had the discussion what $x.join($sep) should be,
specifically if it should work for non-List $x. $Larry said yes, it
should work, and the way to achieve that is to use Any.join.
Now Patrick wants to know which of the various list methods need to be
in Any.

BTW Junctions aren't a subtype of Any, but of Object.

> If I've misunderstood, feel free to print this out and burn it :)

$rant_about_wasting_resources_and_climate_change ;-)

Moritz

-- 
Moritz Lenz
http://moritz.faui2k3.org/ |  http://perl-6.de/

Re: Should C and C work in C ?

[Ovid]

--- On Mon, 30/6/08, Ovid <[EMAIL PROTECTED]> wrote:
> --- On Sun, 29/6/08, Patrick R. Michaud
> <[EMAIL PROTECTED]> wrote:
> 
> > Do C and C act like the
> > C method, in that
> > they work for C object and not just objects
> of
> > type C?
> > 
> > In other words,, should  C< $x.grep(...) >  work
> even
> > if $x isn't normally a list type?
> 
> If I understand you correctly, I think you're asking if
> grep and map can be applied to junctions?  I would say yes. 

I just noticed you included 'reverse' in that list of methods.  I thought 
junctions were inherently unordered, thus making reverse kind of useless (which 
leads me even more to believe that I've misunderstood the question).

Cheers,
Ovid
--
Buy the book - http://www.oreilly.com/catalog/perlhks/
Tech blog- http://use.perl.org/~Ovid/journal/
Twitter  - http://twitter.com/OvidPerl
Official Perl 6 Wiki - http://www.perlfoundation.org/perl6

Re: Should C and C work in C ?

[Ovid]

--- On Sun, 29/6/08, Patrick R. Michaud <[EMAIL PROTECTED]> wrote:

> Do C and C act like the
> C method, in that
> they work for C object and not just objects of
> type C?
> 
> In other words,, should  C< $x.grep(...) >  work even
> if $x isn't normally a list type?

If I understand you correctly, I think you're asking if grep and map can be 
applied to junctions?  I would say yes.  We don't want to mutate junctions in 
place as this would break their parallelism, but I've found that I sometimes 
need to pass junctions around and build new junctions based on the values of 
old junctions.  grep and map would make that trivial.

If I've misunderstood, feel free to print this out and burn it :)

Cheers,
Ovid
--
Buy the book - http://www.oreilly.com/catalog/perlhks/
Tech blog- http://use.perl.org/~Ovid/journal/
Twitter  - http://twitter.com/OvidPerl
Official Perl 6 Wiki - http://www.perlfoundation.org/perl6

Should C and C work in C ?

[Patrick R. Michaud]

Do C and C act like the C method, in that
they work for C object and not just objects of type C?

In other words,, should  C< $x.grep(...) >  work even if
$x isn't normally a list type?

Pm

Re: and in S05

[Larry Wall]

On Sat, Jun 21, 2008 at 01:59:28PM -0700, cognominal wrote:
: C and  being zero width assertions , I think they must
: always be called with
: a question mark. This is not the case line 394 and 1537.
: Perljam  suggested that a zero width assertion can be also a capturing
: one and that
: could explain the dropping of the question mark. I don't agree with
: that suggestion.

I see little reason to prohibit use of ?-less  to mean capture.
If someone is looking to eke out more performance, it will be fairly
obvious that the syntax tree has extraneous "before" nodes in it.
And since you can use  in a kind of "and" logic to view a
string in different ways, any of which are valid views, I think
a particular view should be able to return its matches even if
you later force it to succeed at zero width.

: Anyway the examples given line 394 and 1537 don't involve capture.

True, those are fossils.

Larry

and in S05

[cognominal]

C and  being zero width assertions , I think they must
always be called with
a question mark. This is not the case line 394 and 1537.
Perljam  suggested that a zero width assertion can be also a capturing
one and that
could explain the dropping of the question mark. I don't agree with
that suggestion.
Anyway the examples given line 394 and 1537 don't involve capture.

This was discussed in #perl6 starting 
http://irclog.perlgeek.de/perl6/2008-06-20#i_357271

Re: Google index and subsets (two topics for the price of one!)

[Thomas Sandlaß]

HaloO,

On Monday, 16. June 2008 10:11:49 Ovid wrote:
> For example, should the pre/postfix '++' be
> listed as having a side-effect?

I think so. But the scope where these side-effects take
place is important as well. In your second example below
the side-effect is restrained to the subs scope. That
should be considered harmless. The more global a
side-effect takes place, the more you get into spooky
action at a distance and unpredictable behavior.

>   sub side_effect{ return $_[0]++ }
>   sub no_side_effect { my $x = shift; return $x++ }
>
> In Perl 6, since arguments to subs would have to be specifically
> written as 'is rw', we might be able to minimize this issue, but I
> don't know if we can stop it.

I would think that it should be possible to enforce methods that
don´t modify the invocant mostly at compile time. The rest could
use a STORE instrumentation on MOP level that fails on any modification.
Then a where clause could temporarily install that for the evaluation
of its body. Also access to outer namespaces can easily be blocked
or restricted.


Regards, TSa.
-- 
"The unavoidable price of reliability is simplicity" -- C.A.R. Hoare
"Simplicity does not precede complexity, but follows it." -- A.J. Perlis
1 + 2 + 3 + 4 + ... = -1/12  -- Srinivasa Ramanujan

Re: Google index and subsets (two topics for the price of one!)

[Ovid]

--- TSa <[EMAIL PROTECTED]> wrote:

> Daniel Ruoso wrote:
> > In fact, I doubt that there's a way to completely avoid any
> possible
> > side effects on this closures. as the very first line of the
> closure
> > shows:
> >  
> >$_.inside_of(...)
> > 
> > This is a plain method call, there's no way to tell if this method
> > will change anything inside the object or not.
> 
> Well, we could use something to the effect of const methods in C++.
> That is we have a trait on a method that prevents changes of the
> object. And these could be the only ones allowed in where blocks.

The problem Daniel mentions is that in a dynamic language like Perl,
you just can't prevent side-effects.  Consider:

  eval $foo;

Does that have side effects or not?  There's no way to know and yet
there are plenty of examples one could potentially construct which
would have non-obvious side-effects.

I would love to be able to introspect the code to know whether or not
any operators or keywords with known side-effects are in a given block
of code, but even then that would depend on the context (of the code,
not Perl's "context").  For example, should the pre/postfix '++' be
listed as having a side-effect?

  sub side_effect{ return $_[0]++ }
  sub no_side_effect { my $x = shift; return $x++ }

In Perl 6, since arguments to subs would have to be specifically
written as 'is rw', we might be able to minimize this issue, but I
don't know if we can stop it.

Cheers,
Ovid

--
Buy the book  - http://www.oreilly.com/catalog/perlhks/
Personal blog - http://publius-ovidius.livejournal.com/
Tech blog - http://use.perl.org/~Ovid/journal/

Re: Google index and subsets (two topics for the price of one!)

[Ovid]

--- TSa <[EMAIL PROTECTED]> wrote:

> I must admit that I hardly follow that statement. Why are
> side-effects
> essential to achieve constraint programming and why do you think that
> the way to get at the constraint programming paradigm are the subset
> type definitions?

Because I can't think of any other way to do it :)

> E.g. to get constraint programming as I know it
> from Oz, Perl 6 would need a single assignment store first of all.
And
> then a heavy re-assignment of semantics to things like '$x = $y'
which
> would become a symmetric assertion instead of asymmetric, imperative
> assignment.

Now it's my turn to say that I can't follow that statement.

> Could you give some hints on these fascinating wins, please.

I explain in more detail at http://use.perl.org/~Ovid/journal/36667

You asked why I think that constraints would need to modify the
variable (would "invocant" be the right term here?).  In logic
programming, constraints merely help prune search tress to a reasonable
amount.  Nothing is mutated (as far as I'm aware).  In imperative or OO
code, I would think that a constraint *must* be mutating or else you
have little more than DBC (design by contract).

Am I missing something fundamental here?  Examples welcome.

Cheers,
Ovid

 I for
> my part would argue the where blocks to be a very constraint form of
> block that generally has type :(Object --> Bool) and doesn't alter
> the object of concern in any way. Note that the where blocks are
> executed from within the type-checker or the dispatcher where no
> assumptions of the call environment other then the object should
> be made.
> 
> 
> Regards, TSa.
> -- 
> 
> "The unavoidable price of reliability is simplicity" -- C.A.R. Hoare
> "Simplicity does not precede complexity, but follows it." -- A.J.
> Perlis
> 1 + 2 + 3 + 4 + ... = -1/12  -- Srinivasa Ramanujan
> 


--
Buy the book  - http://www.oreilly.com/catalog/perlhks/
Personal blog - http://publius-ovidius.livejournal.com/
Tech blog - http://use.perl.org/~Ovid/journal/

Re: Google index and subsets (two topics for the price of one!)

[TSa]

HaloO,

Daniel Ruoso wrote:

In fact, I doubt that there's a way to completely avoid any possible
side effects on this closures. as the very first line of the closure
shows:
 
   $_.inside_of(...)


This is a plain method call, there's no way to tell if this method will
change anything inside the object or not.


Well, we could use something to the effect of const methods in C++.
That is we have a trait on a method that prevents changes of the
object. And these could be the only ones allowed in where blocks.



It's important to remember that, in Perl 6, something is only guaranteed
to be fully executed before the next statement when using short-circuit
operators, everything else is subject to eventually be made lazy, with
the exception of the feed operators, that explicitly say to assume lazy
behaviour.


So, no C++ sequence points or the like at all in the definition of
Perl 6?


Regards, TSa.
--

"The unavoidable price of reliability is simplicity" -- C.A.R. Hoare
"Simplicity does not precede complexity, but follows it." -- A.J. Perlis
1 + 2 + 3 + 4 + ... = -1/12  -- Srinivasa Ramanujan

Re: Google index and subsets (two topics for the price of one!)

[TSa]

HaloO,

Ovid wrote:

In other words, I think we could get proper constraint programming if a
subset can mutate its variable.  Otherwise, all assignment would need
to be wrapped inside of an eval and the code would be more bug-prone.


I must admit that I hardly follow that statement. Why are side-effects
essential to achieve constraint programming and why do you think that
the way to get at the constraint programming paradigm are the subset
type definitions? E.g. to get constraint programming as I know it from
Oz, Perl 6 would need a single assignment store first of all. And then
a heavy re-assignment of semantics to things like '$x = $y' which would
become a symmetric assertion instead of asymmetric, imperative
assignment.



Will said mutating work?  If it does, all logic handling constraints
can be encapsulated in one spot.  On the other hand, this could lead to
mysterious action at a distance.  The losses are significant, but the
wins seem absolutely fascinating.


Could you give some hints on these fascinating wins, please. I for
my part would argue the where blocks to be a very constraint form of
block that generally has type :(Object --> Bool) and doesn't alter
the object of concern in any way. Note that the where blocks are
executed from within the type-checker or the dispatcher where no
assumptions of the call environment other then the object should
be made.


Regards, TSa.
--

"The unavoidable price of reliability is simplicity" -- C.A.R. Hoare
"Simplicity does not precede complexity, but follows it." -- A.J. Perlis
1 + 2 + 3 + 4 + ... = -1/12  -- Srinivasa Ramanujan

Re: Google index and subsets (two topics for the price of one!)

[Daniel Ruoso]

Seg, 2008-06-09 às 23:09 +0100, Ovid escreveu:
> Well, looking at the examples that you and Jonathan listed, I see I
> should refine my question.  For example:
>   subset Crosshair of Point where {
> $_.inside_of($target_area) 
> ||
> $target_area.has_moved
>   ?? $_.move_inside($target_area)
>   :: $target_area.move_outside($_)
>   };
> In other words, I think we could get proper constraint programming if a
> subset can mutate its variable.  Otherwise, all assignment would need
> to be wrapped inside of an eval and the code would be more bug-prone.
> Will said mutating work?  If it does, all logic handling constraints
> can be encapsulated in one spot.  On the other hand, this could lead to
> mysterious action at a distance.  The losses are significant, but the
> wins seem absolutely fascinating.

In fact, I doubt that there's a way to completely avoid any possible
side effects on this closures. as the very first line of the closure
shows:
 
   $_.inside_of(...)

This is a plain method call, there's no way to tell if this method will
change anything inside the object or not.

Obviously, in most cases this kind of constraint checking won't make any
change in the value. it's a dangerous feature, I agree, but it's a price
we pay for many other interesting features, and in fact, some neat
things can be implemented using this dangerous thing itself. Lazy
evaluation is certainly something that will benefit from that.

Imagine that inside_of depends on the result of some IO, the object can
use non-blocking IO, return immediatly and only do the actual reading if
that value is needed, and at that point, the information might even be
already available, so no blocking is ever needed. Or inside_of might
never be called and no IO is ever performed, and this simply defined by
if that value is bound to a variable of a given type (like in a
signature matching).

It's important to remember that, in Perl 6, something is only guaranteed
to be fully executed before the next statement when using short-circuit
operators, everything else is subject to eventually be made lazy, with
the exception of the feed operators, that explicitly say to assume lazy
behaviour.

lazyness is probably the most important perspective change from p5 to
p6, take a look at the code for the default P6 meta class I'm working in
SMOP (the introspection methods, in the end):
http://svn.pugscode.org/pugs/v6/smop/src-s1p/P6Meta.pm

daniel

Re: Google index and subsets (two topics for the price of one!)

[Daniel Ruoso]

Seg, 2008-06-09 às 23:36 +0100, Ovid escreveu:
> --- Jonathan Worthington <[EMAIL PROTECTED]> wrote:
> > By default, block parameters (including $_) are readonly,
> I hope that is a deep readonly?  In other words, if $_.position returns
> an array reference, can I mutate a value in that reference and the
> state of $_ is thereby changed?

Even having said that in the other mail in this thread, I'd like to
stress the fact that *it's not possible to avoid side-effects of a
method call*, if that method call have a side effect (even if a "inside
effect"). And again, some neat things will only be possible because of
that.

daniel

Re: Google index and subsets (two topics for the price of one!)

[Ovid]

--- Jonathan Worthington <[EMAIL PROTECTED]> wrote:

> Ovid wrote:
>
> By default, block parameters (including $_) are readonly,

I hope that is a deep readonly?  In other words, if $_.position returns
an array reference, can I mutate a value in that reference and the
state of $_ is thereby changed?

Cheers,
Ovid

--
Buy the book  - http://www.oreilly.com/catalog/perlhks/
Personal blog - http://publius-ovidius.livejournal.com/
Tech blog - http://use.perl.org/~Ovid/journal/

Re: Google index and subsets (two topics for the price of one!)

[Jonathan Worthington]

Ovid wrote:

Well, looking at the examples that you and Jonathan listed, I see I
should refine my question.  For example:

  subset Crosshair of Point where {
$_.inside_of($target_area) 
||

$target_area.has_moved
  ?? $_.move_inside($target_area)
  :: $target_area.move_outside($_)
  };

In other words, I think we could get proper constraint programming if a
subset can mutate its variable.  
By default, block parameters (including $_) are readonly, but you can 
use the <-> pointy block syntax, which declares its parameters "is rw", 
or just do so explicitly. Here's one of the ways, and I think this would 
work (or at least is the correct syntax):


 subset Crosshair of Point where <-> $_ {
   $_.inside_of($target_area) 
   ||

   $target_area.has_moved
 ?? $_.move_inside($target_area)
 :: $target_area.move_outside($_)
 };



On the other hand, this could lead to mysterious action at a distance.  The 
losses are significant, but the wins seem absolutely fascinating.
  
Well, you are explicitly declaring the rw nature of the constraint right 
there in the signature, so it's easy enough to know that it might change 
things without having to look through the code inside the block to 
check. So I think it's not quite so spooky, or at least the spookiness 
is declared up front. :-)


Jonathan

Re: Google index and subsets (two topics for the price of one!)

[Ovid]

--- Moritz Lenz <[EMAIL PROTECTED]> wrote:

> Ovid wrote:
> > Anyone have any idea why Google is not indexing the official Perl 6
> > documentation at perlcabal.org/syn?  I checked the robots.txt and
> it
> > looks fine:
> > 
> >   http://www.perlcabal.org/robots.txt
> > 
> > But the search box on http://www.perlcabal.org/syn/ returns
> nothing.
> 
> The whole domain seems to be missing from the index, not only the
> synopsis.
> 
> If nobody else has any idea, I could get a webmaster account and try
> to
> find out what's wrong.
> 
> > Specifically, I was looking for the documentation on how subsets
> work
> > as it looks like we can get declarative style constraint
> programming
> > for free:
> > 
> >   subset Crosshair of Point where { $_.inside_of($target_zone) };
> > 
> > Is that valid syntax?
> 
> Yes. See http://perlcabal.org/syn/S02.html#Polymorphic_types for
> similar
> examples.

Well, looking at the examples that you and Jonathan listed, I see I
should refine my question.  For example:

  subset Crosshair of Point where {
$_.inside_of($target_area) 
||
$target_area.has_moved
  ?? $_.move_inside($target_area)
  :: $target_area.move_outside($_)
  };

In other words, I think we could get proper constraint programming if a
subset can mutate its variable.  Otherwise, all assignment would need
to be wrapped inside of an eval and the code would be more bug-prone.

Will said mutating work?  If it does, all logic handling constraints
can be encapsulated in one spot.  On the other hand, this could lead to
mysterious action at a distance.  The losses are significant, but the
wins seem absolutely fascinating.

Cheers,
Ovid

--
Buy the book  - http://www.oreilly.com/catalog/perlhks/
Personal blog - http://publius-ovidius.livejournal.com/
Tech blog - http://use.perl.org/~Ovid/journal/

Re: Google index and subsets (two topics for the price of one!)

[Jonathan Worthington]

Ovid wrote:

Specifically, I was looking for the documentation on how subsets work
  

See S12:
http://dev.perl.org/perl6/doc/design/syn/S12.html#Types_and_Subtypes


as it looks like we can get declarative style constraint programming
for free:

  subset Crosshair of Point where { $_.inside_of($target_zone) };

Is that valid syntax?
  
Yes. I presented some slides on it, under the name "dependant types", at 
the NPW recently.

http://www.jnthn.net/papers/2008-npw-understanding-perl6-slides.pdf

Aside: you can play with them in Rakudo somewhat, if you want to get a 
feel for them a bit more. You can declare them just fine with the syntax 
you wrote above; you can also declare anonymous ones on subroutine 
parameters too (and refer to other parameters inside them) and they will 
be enforced, plus they will be enforced on variables. Lexically scoping 
them and the "my Str Foo where ..." forms likely don't work just yet, 
though, and they don't yet act as tie-breakers in MMD.


Hope this helps,

Jonathan

Re: Google index and subsets (two topics for the price of one!)

[Moritz Lenz]

Ovid wrote:
> Anyone have any idea why Google is not indexing the official Perl 6
> documentation at perlcabal.org/syn?  I checked the robots.txt and it
> looks fine:
> 
>   http://www.perlcabal.org/robots.txt
> 
> But the search box on http://www.perlcabal.org/syn/ returns nothing.

The whole domain seems to be missing from the index, not only the synopsis.

If nobody else has any idea, I could get a webmaster account and try to
find out what's wrong.

> Specifically, I was looking for the documentation on how subsets work
> as it looks like we can get declarative style constraint programming
> for free:
> 
>   subset Crosshair of Point where { $_.inside_of($target_zone) };
> 
> Is that valid syntax?

Yes. See http://perlcabal.org/syn/S02.html#Polymorphic_types for similar
examples.

Cheers,
Moritz

-- 
Moritz Lenz
http://moritz.faui2k3.org/ |  http://perl-6.de/

Google index and subsets (two topics for the price of one!)

[Ovid]

Anyone have any idea why Google is not indexing the official Perl 6
documentation at perlcabal.org/syn?  I checked the robots.txt and it
looks fine:

  http://www.perlcabal.org/robots.txt

But the search box on http://www.perlcabal.org/syn/ returns nothing.

Specifically, I was looking for the documentation on how subsets work
as it looks like we can get declarative style constraint programming
for free:

  subset Crosshair of Point where { $_.inside_of($target_zone) };

Is that valid syntax?

See http://en.wikipedia.org/wiki/Constraint_programming for more info
(I think we can do it in Perl 5 with tie, but tied variables are no
fun)

Cheers,
Ovid

--
Buy the book  - http://www.oreilly.com/catalog/perlhks/
Personal blog - http://publius-ovidius.livejournal.com/
Tech blog - http://use.perl.org/~Ovid/journal/

clarification on samecase() and samebase()

[Moritz Lenz]

Hi all,

Auzon has written a few tests for the samecase() and samebase() (S29),
which raised a question:

For both the :samecase and there :samebase regex modifier (S05) there is
a "dumb" and a "smart" version. S29 is silent about which it refers to.

Should both have a second, optional argument which specifies the
operation mode? Or are they both "dump", and the regex engine does the
mapping from smart to dump itself?

Anyway, S29 needs clarification.

BTW the naming seems inconsistent to me: same*case* preserves *case*,
but same*base* preserves *accents*

-- 
Moritz Lenz
http://moritz.faui2k3.org/ |  http://perl-6.de/



signature.asc
Description: OpenPGP digital signature

Huffman encoding (was Re: treatment of "isa" and inheritance)

[David Green]

On 2008-Apr-30, at 1:29 pm, Brandon S. Allbery KF8NH wrote:

On Apr 30, 2008, at 15:14 , Jon Lang wrote:

On a side note, I'd like to make a request of the Perl 6 community
with regard to coding style: could we please have adverbal names that
are, well, adverbs?  "is :strict Dog" brings to my mind the English


-ly suffixes everywhere conflicts with Huffman coding, which per  
@Larry is a primary design concern.  Consider the leading colon to  
be the Perl6 equivalent.


Logically, yes, a ":" on the front of a word is as good an indicator  
of an adverb as an "ly" on the end.  Psychologically, however, it  
isn't; for one thing, my mind doesn't pronounce punctuation the same  
way as letters.  Whatever the reason, I've been reading English for  
decades longer than I have P6 (and by the time I've spent that many  
decades getting familiar with P6, I'll be even more familiar with  
English... which is of course one of the reasons why Perl tries to  
look kinda sorta like English in the first place; it may as well try  
to look like half-decent English!).


But the more general point I wish to make is that extra characters  
don't necessarily conflict with the goal of Huffman encoding.  I  
assume the idea was that extra 'ly's everywhere take up space that  
isn't needed -- of course Huffman himself was concerned with  
minimising bits, but in terms of Perl what we're interested in is  
efficient understanding, not efficient storage.


Now "short code" is not a bad first approximation to "understandable  
code", since longer reading-time will contribute to longer  
understanding-time.  But that's only a very rough rule of thumb: if  
something is too short, it will take even more work to figure out what  
it's saying, and thus any time saved by shortness will be swamped by  
the much greater effort to figure out what the heck it means.


(In this particular example, it seems quite reasonable that the  
cognitive dissonance from seeing an adjective where one's English- 
trained brain is expecting an adverb will outweigh the negligible time  
it takes to scan a couple of extra letters.)


That's why Perl6 has abandoned all the punctuation-variables from P5  
in favour of their "use English" equivalents.  Real words are longer  
to read (and write) but easier to understand overall.


(Of course, more characters are less efficient to type, but except for  
throw-away one-liners, code gets written once and read multiple times,  
so Huffman meta-encoding dictates that we should optimise for  
reading.  And anyway, making code more efficient to write is the job  
of one's text-editor, not the language.  Maybe we should work on auto- 
completion files for popular editors that will expand things like  
":str" into ":strictly", etc.)



-David

"Perl 6 Donors, Sponsors, and Supporters" on Perl 6 Wiki (Thanks Ian Hague and Vienna.pm!)

[Conrad Schneiker]

With Ian Hague's great donation, plus recent support from the Vienna.pm, it
seemed like time to create a separate wiki page for such things:

 
http://www.perlfoundation.org/perl6/index.cgi?perl_6_donors_sponsors_and_sup
porters

I've also added a prominent link to this from near the top of the Perl 6
wiki front page, among other places.

Please help reward our sponsors and stimulate others by spreading this link
around whenever appropriate opportunities arise.

Best regards,
Conrad Schneiker

www.AthenaLab.com

Official Perl 6 Wiki — http://www.perlfoundation.org/perl6 
Official Parrot Wiki — http://www.perlfoundation.org/parrot 

Re: Private methods in classes and roles

[John M. Dlugosz]

Moritz Lenz moritz-at-casella.verplant.org |Perl 6| wrote:

S12 says (in the context of classes):


my method think (Brain $self: $thought)

(Such methods are completely invisible to ordinary method calls, and are
in fact called with a different syntax that uses ! in place of the .
character. See below.)

And later on, in the context of roles:

my method !foo ...
my method foo ...   # same, but &foo is aliased to &!foo

Am I right in assuming that the second example is valid only for roles?

I find this different syntax for classes and roles quite confusing. Is
it intended that way? I'd welcome a uniform syntax.

Cheers,
Moritz

  


I've asked about "my method foo" too, but had no response.  I would not 
think anything is unique to roles, rather, stuff defined in a role is 
remembered partly-digested and spilled into a class later.  You might 
want to look at what I've got thus far in my specdoc at 
<http://www.dlugosz.com/Perl6/>.  I plan on updating that section soon, 
but you get the idea of the formalism I'm bringing to it.


--John

Re: Private methods in classes and roles

[Moritz Lenz]

and a few more thoughts:

I wrote:
> S12 says (in the context of classes):
> 
> 
> my method think (Brain $self: $thought)
> 
> (Such methods are completely invisible to ordinary method calls, and are
> in fact called with a different syntax that uses ! in place of the .
> character. See below.)

for private subs S12 also says

Generally you'd just use a lexically scoped sub, though.

my sub foo ...

[Conjectural: To put a private sub into the class, say

our sub !foo ...

]

Which lead me to the thought that 'my method foo' is a bad idea because
the lexical scoping of the 'my' is orthogonal to the scope of the class.

class A {
my method foo { }
}

class A is also {
method bar {
   # no way to access self!foo here
}
}

So is

our method !foo {}

allowed in classes? and is it the recommended way to declare private
methods?


-- 
Moritz Lenz
http://moritz.faui2k3.org/ |  http://perl-6.de/

Private methods in classes and roles

[Moritz Lenz]

S12 says (in the context of classes):


my method think (Brain $self: $thought)

(Such methods are completely invisible to ordinary method calls, and are
in fact called with a different syntax that uses ! in place of the .
character. See below.)

And later on, in the context of roles:

my method !foo ...
my method foo ...   # same, but &foo is aliased to &!foo

Am I right in assuming that the second example is valid only for roles?

I find this different syntax for classes and roles quite confusing. Is
it intended that way? I'd welcome a uniform syntax.

Cheers,
Moritz

-- 
Moritz Lenz
http://moritz.faui2k3.org/ |  http://perl-6.de/

Re: treatment of "isa" and inheritance

[Jon Lang]

John M. Dlugosz wrote:
> Jon Lang dataweaver-at-gmail.com |Perl 6| wrote:
>
> > IIRC, the supertyping proposal involved being able to "anti-derive"
> > roles from existing roles or classes, working from subtypes to
> > supertypes (or from derived roles to base roles) instead of the other
> > way around.  The proposal got hung up on terminology issues,
> > specifically a discussion involving intensional sets vs. extensional
> > sets.  I find this unfortunate, as I see a lot of potential in the
> > idea if only it could be properly (read: unambiguously) presented.
> >
> > >From an "intensional set" perspective, a supertype would be a role
> > that includes the structure common to all of the classes and/or roles
> > for which it's supposed to act as a base role.  From an "extensional
> > set" perspective, the range of values that it covers should span the
> > range of values that any of its pre-established "subtypes" cover.  A
> > proposal was put forward to use set operations to create anonymous
> > supertypes, and then to provide them with names via aliasing; where it
> > got hung up was whether it should be based on a union of extensional
> > sets (i.e., combining the potential set of values) or on an
> > intersection of intensional sets (i.e., identifying the common
> > attributes and methods).
>
>  I agree that is unfortunate.
>  Perhaps, although you didn't show me that specific proposal (and reopen the
> arguments), you explained the ideas behind them enough that I see some of
> that description in the algorithm I used for the £ operator.

I just reviewed the threads in question; they're from December 2006.
Search the list archives for "supertyping" to find them.

The bottom line was that there were two competing visions of what
supertyping was supposed to do.  My own view was that supertyping
should be used as a way of extracting subsets of behavior out of a
preexisting role as new roles in such a way that the original role
would count as a subtype of the extracted roles, nominally as well as
structurally.  The other view involved using these extracted roles to
back-edit new behavior into existing roles.  Larry's final word on the
subject was to suggest a versioning mechanic whereas instead of
mutating a role to add new behavior, one would be able to create newer
versions of the role that included the new behavior while preserving
the older version for cases where the new behavior was inappropriate.

-- 
Jonathan "Dataweaver" Lang

Re: treatment of "isa" and inheritance

[John M. Dlugosz]

Jon Lang dataweaver-at-gmail.com |Perl 6| wrote:

IIRC, the supertyping proposal involved being able to "anti-derive"
roles from existing roles or classes, working from subtypes to
supertypes (or from derived roles to base roles) instead of the other
way around.  The proposal got hung up on terminology issues,
specifically a discussion involving intensional sets vs. extensional
sets.  I find this unfortunate, as I see a lot of potential in the
idea if only it could be properly (read: unambiguously) presented.

>From an "intensional set" perspective, a supertype would be a role
that includes the structure common to all of the classes and/or roles
for which it's supposed to act as a base role.  From an "extensional
set" perspective, the range of values that it covers should span the
range of values that any of its pre-established "subtypes" cover.  A
proposal was put forward to use set operations to create anonymous
supertypes, and then to provide them with names via aliasing; where it
got hung up was whether it should be based on a union of extensional
sets (i.e., combining the potential set of values) or on an
intersection of intensional sets (i.e., identifying the common
attributes and methods).

  


I agree that is unfortunate. 

Perhaps, although you didn't show me that specific proposal (and reopen 
the arguments), you explained the ideas behind them enough that I see 
some of that description in the algorithm I used for the £ operator.


The synopses claims that classes are set-like.  With generics we are 
moving in the direction of intentions based.  So there is the conflict. 

Re: treatment of "isa" and inheritance

[Daniel Ruoso]

Sex, 2008-05-02 às 15:32 +0200, TSa escreveu:
> Daniel Ruoso wrote:
> > I don't really see what this "is :strict" means in the runtime
> > environment. Perl 6 takes OO so deeply that even the type checking is
> > implemented as a cal to the object. There isn't really a way of asking
> > "are you trully really a Dog?", there's only "do you 'Dog'?".
> Sorry, where is this specced?

It's an implicit consequence of supporting different metamodels and
representations. The operator cannot assume to know how the object is
laid out, it must ask the object about it. Again, of course
optimizations can simplify that if everybody knows each other, but it
still should be able to take a Glib object as if it was an Array.

The only types the operators can assume to know are the native types.

>From S12:

   All public method calls are "virtual" in the C++ sense. More 
   surprisingly, any class name mentioned in a method is also
   considered virtual, that is, polymorphic on the actual type of the
   object.

   You may derive from any built-in type, but the derivation of a
   low-level type like int may only add behaviors, not change the
   representation. Use composition and/or delegation to change the
   representation.

Specially the "polymorphic on the actual type of the object". There's no
direct relation between the class "Dog" and the "actual type" of some
Dog object, which may imply on how this object is laid out, so the
operators can't really do anything except asking the object "do you
'Dog'"?

daniel

Re: treatment of "isa" and inheritance

[Jon Lang]

John M. Dlugosz wrote:
> TSa Thomas.Sandlass-at-barco.com |Perl 6| wrote:
> > Take e.g. my supertyping proposal. I guess it was regarded as
> > a curiosity rather than an innovative feature.
>
>  Which idea was that?  Maybe I already took the wind into account when I
> rounded up the ideas in need of documentation/elaboration in the first
> place.

IIRC, the supertyping proposal involved being able to "anti-derive"
roles from existing roles or classes, working from subtypes to
supertypes (or from derived roles to base roles) instead of the other
way around.  The proposal got hung up on terminology issues,
specifically a discussion involving intensional sets vs. extensional
sets.  I find this unfortunate, as I see a lot of potential in the
idea if only it could be properly (read: unambiguously) presented.

>From an "intensional set" perspective, a supertype would be a role
that includes the structure common to all of the classes and/or roles
for which it's supposed to act as a base role.  From an "extensional
set" perspective, the range of values that it covers should span the
range of values that any of its pre-established "subtypes" cover.  A
proposal was put forward to use set operations to create anonymous
supertypes, and then to provide them with names via aliasing; where it
got hung up was whether it should be based on a union of extensional
sets (i.e., combining the potential set of values) or on an
intersection of intensional sets (i.e., identifying the common
attributes and methods).

-- 
Jonathan "Dataweaver" Lang

Re: Polymorphism and Representations

[TSa]

HaloO,

John M. Dlugosz wrote:
C++ worked on that issue for years in committee.  CLOS has decades of 
hindsight.  Proposing ranking rules is a challenge for another day, but 
those are my source material thus far.


Hmm, C++ dispatch rules are rather trivial. From the static type of the
pointer an index into the vtable is choosen. Or do you mean static
overloading of functions?


You can always get your multis so tangled up that you don't know which 
one is being called, no matter what the rules.  Perhaps we need more 
fine control with intent based properties, to say "read-write is more 
important to distinguish the functionality of the cases" vs "working 
with fractions is more important".


Please not. Dispatch should be on the dynamic types of the values,
nothing else. It was a lengthy discussion to get rid of Manhattan
dispatch. A simple approach would be to allow trait annotations
only on the proto or make differing traits an error in subsequent
multi declarations.


Regards, TSa.
--

"The unavoidable price of reliability is simplicity" -- C.A.R. Hoare
"Simplicity does not precede complexity, but follows it." -- A.J. Perlis
1 + 2 + 3 + 4 + ... = -1/12  -- Srinivasa Ramanujan

Re: Polymorphism and Representations

[John M. Dlugosz]

TSa Thomas.Sandlass-at-barco.com |Perl 6| wrote:

Where do you get the information from that the second is more
specific than the former? Consider

   constant Num $c = 3; # Num here is funny
   my   Num $n = 3;
   my   Int $i = 3;
   my   Any $a = 3;

And now $i is more specific than $n? Would a call to foo with $i
dispatch to the ro case? Is $a more specific than $n? Note that undef
is the only "value" that meets the impossible constraint. So calling
the rw foo with $i might store an undef. Not to mention the autocoercion
of Num to Int upon assignment. Do you expect the dispatch take that into
account as well? Consider



C++ worked on that issue for years in committee.  CLOS has decades of 
hindsight.  Proposing ranking rules is a challenge for another day, but 
those are my source material thus far.


You can always get your multis so tangled up that you don't know which 
one is being called, no matter what the rules.  Perhaps we need more 
fine control with intent based properties, to say "read-write is more 
important to distinguish the functionality of the cases" vs "working 
with fractions is more important".


--John

Re: Polymorphism and Representations

[TSa]

HaloO,

John M. Dlugosz wrote:
You want a way to declare the function to accept both lvalue and 
non-lvalue items, and determine at run-time whether it can write back to 
it.


Yes, but as a general feature. Any assignment checks the constraint
of the lvalue. A non-writeable lvalue is simply having an impossible
constraint. That amounts to "everything does lvalue upto a constraint".
So effectively everything becomes an lvalue.


The MMD matching solution does not require return type matching.  The 
information "does this conform" is part of the parameter types.


  multi sub foo (Num $x is ro) { ... }
  multi sub foo (Num $x is rw) { ... }

The second is not a candidate if you pass a literal, a constant, 
whatever.


OK, this is the easy case insofar as the Num in the signature
does syntactic double duty in first constraining the type of the
input towards *more* specific types and then constraining the container
towards *less* specific types.

 The second is considered a better match when it is a 
candidate by virtue of the ordering rules.


Where do you get the information from that the second is more
specific than the former? Consider

   constant Num $c = 3; # Num here is funny
   my   Num $n = 3;
   my   Int $i = 3;
   my   Any $a = 3;

And now $i is more specific than $n? Would a call to foo with $i
dispatch to the ro case? Is $a more specific than $n? Note that undef
is the only "value" that meets the impossible constraint. So calling
the rw foo with $i might store an undef. Not to mention the autocoercion
of Num to Int upon assignment. Do you expect the dispatch take that into
account as well? Consider

  multi foo (Int $x) {...}

Is this more specific than the second when called with $n? How
do 'is ref' and 'is copy' fit in your sort order? My reading is
that the parameter traits are *not* dispatch relevant. Therefore
your two multis are an error because of indistinguishable signature.


Regards, TSa.
--

"The unavoidable price of reliability is simplicity" -- C.A.R. Hoare
"Simplicity does not precede complexity, but follows it." -- A.J. Perlis
1 + 2 + 3 + 4 + ... = -1/12  -- Srinivasa Ramanujan

Re: Polymorphism and Representations

[John M. Dlugosz]

TSa Thomas.Sandlass-at-barco.com |Perl 6| wrote:


Ohh, conceptually we should split the 'r' and 'w' in 'rw'.
The r part is for the value going in. The w part is conceptually
part of the *return* type of the function. The convenience for the
caller lies in the fact that she doesn't have to extract the values
of interest from the returned Capture. The syntactic problem I'm
trying to point out is that the return type and parameter type in
a rw signature entry share the same slot.


You want a way to declare the function to accept both lvalue and 
non-lvalue items, and determine at run-time whether it can write back to it.


The MMD matching solution does not require return type matching.  The 
information "does this conform" is part of the parameter types.


  multi sub foo (Num $x is ro) { ... }
  multi sub foo (Num $x is rw) { ... }

The second is not a candidate if you pass a literal, a constant, 
whatever.  The second is considered a better match when it is a 
candidate by virtue of the ordering rules.


--John

Re: treatment of "isa" and inheritance

[John M. Dlugosz]

TSa Thomas.Sandlass-at-barco.com |Perl 6| wrote:

HaloO,

John M. Dlugosz wrote:

Hmm, I always had the impression of strong headwind.


How so?


Take e.g. my supertyping proposal. I guess it was regarded as
a curiosity rather than an innovative feature.


Regards, TSa.
Which idea was that?  Maybe I already took the wind into account when I 
rounded up the ideas in need of documentation/elaboration in the first 
place.

Re: treatment of "isa" and inheritance

[Daniel Ruoso]

Qua, 2008-04-30 às 12:53 -0400, Brandon S. Allbery KF8NH escreveu:
> It occurs to me that this shouldn't be new keywords, but adverbs, i.e.  
> ``is :strict Dog''.

I don't really see what this "is :strict" means in the runtime
environment. Perl 6 takes OO so deeply that even the type checking is
implemented as a cal to the object. There isn't really a way of asking
"are you trully really a Dog?", there's only "do you 'Dog'?".

P.S.: Of course optimizations may be more static, but it should be also
able to pessimize when dealing with an unknown object implementation.

daniel

Re: treatment of "isa" and inheritance

[TSa]

HaloO,

Daniel Ruoso wrote:

I don't really see what this "is :strict" means in the runtime
environment. Perl 6 takes OO so deeply that even the type checking is
implemented as a cal to the object. There isn't really a way of asking
"are you trully really a Dog?", there's only "do you 'Dog'?".


Sorry, where is this specced? If anything than Perl 6 is operator
oriented. That means it is *not* the object that decides for itself
but the does operator. The split between the method form and the infix
form is just there to distinguish the question form "does it?" from
the command form "make that it does!". Also the "call to the object"
has the wrong connotations. You should think about it as a "call on the
object" or "call with the object" because the important concept is the
call not the object.

Classical OO has serious design flaws. E.g. a ball cannot kick itself.
That is the ball in a game is a proper object that has nothing to
decide about its kicking. It is the players who kick the ball. You
can think of them as objects if you like, but in grammatical terms
the players are subjects! Or think of adding numbers. It's hardly
the case that a number object either adds itself to another or the
other to itself or whatever. It is of course the addition operation
that deals with the numbers.

Also the idea of methods being subordinate to objects is fundamentally
flawed, as well. Getting at methods through an object is a very good
implementation strategy for single dispatch that's all. For MMD that
simply breaks down and the method is up front.

Now the other important feature of classical OO is privileged access
to internal or hidden data---encapsulation for short. But there are
different implementation strategies to achieve this goal, e.g.
closures.


Regards, TSa.
--

"The unavoidable price of reliability is simplicity" -- C.A.R. Hoare
"Simplicity does not precede complexity, but follows it." -- A.J. Perlis
1 + 2 + 3 + 4 + ... = -1/12  -- Srinivasa Ramanujan

Re: treatment of "isa" and inheritance

[Dr.Ruud]

TSa schreef:
> Brandon S. Allbery:

>> It occurs to me that this shouldn't be new keywords, but adverbs,
>> i.e. ``is :strict Dog''.
> 
> Great idea!

And it leaves room for ':stricter' and ':strictest'. 
;) 

-- 
Affijn, Ruud

"Gewoon is een tijger."

Re: Polymorphism and Representations

[TSa]

HaloO,

John M. Dlugosz wrote:
But, I'm thinking along the lines of Pascal and C++.  You can't pass a 
non-lvalue "by reference", period.  (5)++ is just plain wrong.


Hmm, I would like the error to show up *within* the body of ++. Your
idea is to statically derive the error from the 'is rw' trait in the
signature.



The matching rules for MMD should be at least as good as C++
overloading, to have a version of the function that is for
non-lvalues and one that is for lvalues.


Ohh, conceptually we should split the 'r' and 'w' in 'rw'.
The r part is for the value going in. The w part is conceptually
part of the *return* type of the function. The convenience for the
caller lies in the fact that she doesn't have to extract the values
of interest from the returned Capture. The syntactic problem I'm
trying to point out is that the return type and parameter type in
a rw signature entry share the same slot.

Note that return type tie breaking is only conjectured. I doubt
its usefulness anyway. E.g. asking a Go Professional where to play
next is easy insofar as you could just play the move. But the answer
to asking why could easily be beyond your understanding. Now is it
advisable to ask a lesser expert for a move and and a rational
that matches your constraints?


>  Also, Perl 6 synopses mentions both 'rw' and 'ref'

separately.


Indeed, that is puzzling me a lot. IIRC, it states that rw
is more forgiving when the argument is no lvalue. What else
could that be than a relaxed invariance?

I think there will be a choice of copy/return or ref 
binding for 'rw', which allows for differing types; and bind directly 
with 'ref' which allows for custom container ties to work live rather 
than just get an update at the end.


As far as rw is concerned this very much sounds as what I say above,
except that the programmer has no way to interfere. That is to play
it nice for th caller.


 We need a clear summary of 
expectations; that is, what do we want to be able to accomplish.  Then 
refactor that into a set of real features that span the target feature set.


I think that invariance of rw or ref parameters is a too tight
constraint.


Regards, TSa.
--

"The unavoidable price of reliability is simplicity"  -- C.A.R. Hoare
1 + 2 + 3 + 4 + ... = -1/12  -- Srinivasa Ramanujan

Re: treatment of "isa" and inheritance

[Ovid]

--- "Brandon S. Allbery KF8NH" <[EMAIL PROTECTED]> wrote:

> > On a side note, I'd like to make a request of the Perl 6 community
> > with regard to coding style: could we please have adverbal names
> that
> > are, well, adverbs?  "is :strict Dog" brings to my mind the English
> 
> -ly suffixes everywhere conflicts with Huffman coding, which per  
> @Larry is a primary design concern.  Consider the leading colon to be
> the Perl6 equivalent.

This may be the case, but it would be nice to limit the ambiguity.  If
we're going to be stealing a number of linguistic ideas (with the side
effect of transforming our entire language from a pidgin to a creole),
then we might as well consider that a couple of extra letters to
introduce clarity may not be all that bad.

Cheers,
Ovid

--
Buy the book  - http://www.oreilly.com/catalog/perlhks/
Perl and CGI  - http://users.easystreet.com/ovid/cgi_course/
Personal blog - http://publius-ovidius.livejournal.com/
Tech blog - http://use.perl.org/~Ovid/journal/

Re: treatment of "isa" and inheritance

[TSa]

HaloO,

Brandon S. Allbery KF8NH wrote:
I was guessing, I still haven't had a chance to mindmeld with all the 
synopses.  The point remains that this is not a new keyword but an 
adverb modifying the existing keyword.


I fully agree. As an add on 'strict' is a very well established
concept elsewhere in the language.


Regards, TSa.
--

"The unavoidable price of reliability is simplicity"  -- C.A.R. Hoare
1 + 2 + 3 + 4 + ... = -1/12  -- Srinivasa Ramanujan

Re: treatment of "isa" and inheritance

[Brandon S. Allbery KF8NH]

On 2008 May 2, at 5:50, TSa wrote:


Brandon S. Allbery KF8NH wrote:
It occurs to me that this shouldn't be new keywords, but adverbs,  
i.e. ``is :strict Dog''.


Great idea! But aren't named args required to be after required ones?


I was guessing, I still haven't had a chance to mindmeld with all the  
synopses.  The point remains that this is not a new keyword but an  
adverb modifying the existing keyword.


--
brandon s. allbery [linux,solaris,freebsd,perl]  [EMAIL PROTECTED]
system administrator  [openafs,heimdal,too many hats]  [EMAIL PROTECTED]
electrical and computer engineering, carnegie mellon university   
KF8NH

Re: treatment of "isa" and inheritance

[TSa]

HaloO,

Brandon S. Allbery KF8NH wrote:
It occurs to me that this shouldn't be new keywords, but adverbs, i.e. 
``is :strict Dog''.


Great idea! But aren't named args required to be after required ones?
That is we have "is Dog :strict"? I would actually like to relax the
syntax if that were possible because e.g. '3 == log:base(2) 8' looks
more natural than '3 == log 8 :base(2)'. Or '3.001 ==:eps(0.1) 3.01'.


Regards, TSa.
--

"The unavoidable price of reliability is simplicity"  -- C.A.R. Hoare
1 + 2 + 3 + 4 + ... = -1/12  -- Srinivasa Ramanujan

Re: treatment of "isa" and inheritance

[TSa]

HaloO,

John M. Dlugosz wrote:

Hmm, I always had the impression of strong headwind.


How so?


Take e.g. my supertyping proposal. I guess it was regarded as
a curiosity rather than an innovative feature.


Regards, TSa.
--

"The unavoidable price of reliability is simplicity"  -- C.A.R. Hoare
1 + 2 + 3 + 4 + ... = -1/12  -- Srinivasa Ramanujan

Re: treatment of "isa" and inheritance

[John M. Dlugosz]

Larry Wall larry-at-wall.org |Perl 6| wrote:

On a more fundamental level, I wonder what the social ramifications
are.  First, to what extent is this something that will interfere
with people who don't want to learn higher-order typing in order
to get their job done, but will be forced to because one of their
cohorts is using it, or the boss mandates it?  And will Perl get
a Haskellian only-a-genius-can-use-it reputation because of that?
Second, is anybody actually going to implement it?  We're pretty short
of volunteers as it is, and I don't think I'm smart enough to do it,
and I'm very, very slow to put anything into Perl that I don't know
how to implement.
  


I've posted on PerlMonks to get a broader opinion from those besides who 
directly told me what was needed/semiplanned already.


My own interest is in incrementally adding types to "maintain" existing 
code that grows, so I'm keeping that clearly in mind.  That's also why I 
proposed "isa", to let people stay in their comfort zone and know they 
are checked against accidentally needing the fancy stuff to proceed.



Maybe it will be as exotic as those who write the DB ties.  But it's 
under the hood and there for others to use the benefits from.


In other discussions (with Prof Simmons) I've looked at how run-time 
checking blends into optional strong typing, as part of this design.


I also want to document the algorithm in some detail, to make sure that 
different implementations conform.  So implementors will be told exactly 
how to do it.  It's really no worse than generics already planned in the 
synopses, really!  I can get very close to F-bounds constraints just by 
using existing features and syntactic sugar.


--John

Re: treatment of "isa" and inheritance

[Brandon S. Allbery KF8NH]

On Apr 30, 2008, at 15:14 , Jon Lang wrote:

only is "is :strictly Dog" more legible, but it leaves room for the
possible future inclusion of adjective-based syntax such as "big Dog"


It occurs to me that we already have this:  we call them "types".

--
brandon s. allbery [solaris,freebsd,perl,pugs,haskell] [EMAIL PROTECTED]
system administrator [openafs,heimdal,too many hats] [EMAIL PROTECTED]
electrical and computer engineering, carnegie mellon universityKF8NH

Re: treatment of "isa" and inheritance

[Brandon S. Allbery KF8NH]

On Apr 30, 2008, at 15:14 , Jon Lang wrote:


Brandon S. Allbery KF8NH wrote:
 It occurs to me that this shouldn't be new keywords, but adverbs,  
i.e. ``is

:strict Dog''.


On a side note, I'd like to make a request of the Perl 6 community
with regard to coding style: could we please have adverbal names that
are, well, adverbs?  "is :strict Dog" brings to my mind the English


-ly suffixes everywhere conflicts with Huffman coding, which per  
@Larry is a primary design concern.  Consider the leading colon to be  
the Perl6 equivalent.


--
brandon s. allbery [solaris,freebsd,perl,pugs,haskell] [EMAIL PROTECTED]
system administrator [openafs,heimdal,too many hats] [EMAIL PROTECTED]
electrical and computer engineering, carnegie mellon universityKF8NH

Re: treatment of "isa" and inheritance

[James Fuller]

On Wed, Apr 30, 2008 at 9:14 PM, Jon Lang <[EMAIL PROTECTED]> wrote:
> Brandon S. Allbery KF8NH wrote:
>
> > TSa wrote:
>  > > I totally agree! Using 'isa' pulls in the type checker. Do we have the
>  > > same option for 'does' e.g. 'doesa'? Or is type checking always implied
>  > > in role composition? Note that the class can override a role's methods
>  > > at will.
>  >
>  >  It occurs to me that this shouldn't be new keywords, but adverbs, i.e. 
> ``is
>  > :strict Dog''.
>
>  Agreed.  I'm definitely in the category of people who find the
>  difference between "is" and "isa" to be, as Larry put it, eye-glazing.
>   I can follow it, but that's only because I've been getting a crash
>  course in type theory.

+1

>  Brandon's alternative has the potential to be less confusing given the
>  right choice of adverb, and has the added bonus that the same adverb
>  could apply equally well to both 'is' and 'does'.
>
>  On a side note, I'd like to make a request of the Perl 6 community
>  with regard to coding style: could we please have adverbal names that
>  are, well, adverbs?  "is :strict Dog" brings to my mind the English
>  "Fido is a strict dog", rather than "Fido is strictly a dog".  Not
>  only is "is :strictly Dog" more legible, but it leaves room for the

+1

>  possible future inclusion of adjective-based syntax such as "big Dog"
>  (which might mean the same thing as "Dog but is big" or "Dog where
>  .size > Average").  To misquote Einstein, things should be as simple
>  as is reasonable, but not simpler.

and can I add another quote, from someone who's last name is appropriate ;)

'Simplicity does not precede complexity, but follows it.' (Alan Perlis)

cheers, Jim Fuller

Re: treatment of "isa" and inheritance

[Jon Lang]

Brandon S. Allbery KF8NH wrote:
> TSa wrote:
> > I totally agree! Using 'isa' pulls in the type checker. Do we have the
> > same option for 'does' e.g. 'doesa'? Or is type checking always implied
> > in role composition? Note that the class can override a role's methods
> > at will.
>
>  It occurs to me that this shouldn't be new keywords, but adverbs, i.e. ``is
> :strict Dog''.

Agreed.  I'm definitely in the category of people who find the
difference between "is" and "isa" to be, as Larry put it, eye-glazing.
 I can follow it, but that's only because I've been getting a crash
course in type theory.

Brandon's alternative has the potential to be less confusing given the
right choice of adverb, and has the added bonus that the same adverb
could apply equally well to both 'is' and 'does'.

On a side note, I'd like to make a request of the Perl 6 community
with regard to coding style: could we please have adverbal names that
are, well, adverbs?  "is :strict Dog" brings to my mind the English
"Fido is a strict dog", rather than "Fido is strictly a dog".  Not
only is "is :strictly Dog" more legible, but it leaves room for the
possible future inclusion of adjective-based syntax such as "big Dog"
(which might mean the same thing as "Dog but is big" or "Dog where
.size > Average").  To misquote Einstein, things should be as simple
as is reasonable, but not simpler.

-- 
Jonathan "Dataweaver" Lang

Re: treatment of "isa" and inheritance

[Brandon S. Allbery KF8NH]

On Apr 30, 2008, at 8:43 AM, TSa wrote:


John M. Dlugosz wrote:
"isa" as a synonym for "is" that turns on warnings is documented at  
the end of my paper under "Concepts discussed in this paper that  
are not on the Synopses".


I totally agree! Using 'isa' pulls in the type checker. Do we have the
same option for 'does' e.g. 'doesa'? Or is type checking always  
implied

in role composition? Note that the class can override a role's methods
at will.


It occurs to me that this shouldn't be new keywords, but adverbs, i.e.  
``is :strict Dog''.

Re: Polymorphism and Representations

[John M. Dlugosz]

TSa Thomas.Sandlass-at-barco.com |Perl 6| wrote:


Finally combine that with the wish to allow literals of class A. Let's
assume the grammar is patched to parse integer literals as As. Then
with the above 7.inc gives an error because 7 is not mutable. So as
I outlined before I want to care for the callers constraint. Perl 6
lacks a syntax for that.



I'll digest that more later.  For these issues, I have my thoughts 
stacked a few plates down and don't want to lose my productivity right now.


But, I'm thinking along the lines of Pascal and C++.  You can't pass a 
non-lvalue "by reference", period.  (5)++ is just plain wrong.  The 
matching rules for MMD should be at least as good as C++ overloading, to 
have a version of the function that is for non-lvalues and one that is 
for lvalues.  Also, Perl 6 synopses mentions both 'rw' and 'ref' 
separately.   I think there will be a choice of copy/return or ref 
binding for 'rw', which allows for differing types; and bind directly 
with 'ref' which allows for custom container ties to work live rather 
than just get an update at the end.  We need a clear summary of 
expectations; that is, what do we want to be able to accomplish.  Then 
refactor that into a set of real features that span the target feature set.


--John

Re: treatment of "isa" and inheritance

[Larry Wall]

On Wed, Apr 30, 2008 at 07:29:58AM -0500, John M. Dlugosz wrote:
> I am listening.  I'm synthesizing and documenting.  I'm also disappointed 
> with the lack of feedback from Larry, considering the amount of effort and 
> time I'm putting into it.  But I'm sure he'll squawk if I say something 
> really off, rather than flesh out the existing skeleton.

Well, I mentioned before that I have very little bandwidth at the
moment, due to health and employment issues, plus needing to prepare
for a number of upcoming talks.  (Not to mention stealing time to hack
on the STD grammar and longest-token matcher.)  My only choice is to
operate in the bear-of-very-little-brain mode to see if any of this
will be remotely understandable to normal people.  I can tell you my
uncomfy spots, but I haven't the energy to defend them at the moment.

First some nitpicky things.

I don't like using ::?CLASS for something that is not a compile-time
constant.  The ? twigil is supposed to mean that, and that's why
we don't use ::?SELF anymore, but "self", because that can vary in
meaning dynamically.  So I'd rather have a keyword or a pseudo-package,
if it's needed.  Or a different twigil for generically instantiated
items, if it comes into common use, and gets applied to a variety
of names, neither of which is certain.  But ::CLASS would be an
improvement over ::?CLASS, if we reserve that pseudo-package.  Are
there other things that fall into the same twigilish category?  Or
can they all be found via ::CLASS?

I don't like the indentation style that makes the closing quote look
like part of the contents of a block.  You can do whatever you like
in your own papers, of course, but we've spent many years teaching
people in the Perl community to outdent their final curly so that
it means something, rather than hiding it on the end like it's an
embarrassing non-pythonism.  So you'll get better acceptance of any
standards document if you follow that community standard.

The £ seems rather gratuitous from a language design point of view.
Every such symbol in a paper increases the number of people whose eyes
glaze over when they try to read it.  I understand it's a placeholder,
but the current syntax can already express such a "like" constraint via:

$dog where .like(Goat)

We could also have syntactic relief for such a concept by making "like"
work like "where" syntactically:

$dog like Goat

On a more fundamental level, I wonder what the social ramifications
are.  First, to what extent is this something that will interfere
with people who don't want to learn higher-order typing in order
to get their job done, but will be forced to because one of their
cohorts is using it, or the boss mandates it?  And will Perl get
a Haskellian only-a-genius-can-use-it reputation because of that?
Second, is anybody actually going to implement it?  We're pretty short
of volunteers as it is, and I don't think I'm smart enough to do it,
and I'm very, very slow to put anything into Perl that I don't know
how to implement.

Basically, I'm not a types person, historically speaking, so I'm
naturally a bit skeptical.  But over the last few years I've seen some
of both the power and peril of strictly-typed FP.  I'm interested in
making sure Perl 6 is close enough to supporting any paradigm that
it can be warped into full support of that paradigm in any lexical
scope, but I'm leary of any paradigm that starts sucking in all the
other lexical scopes into its sphere of influence whether they like
it or not.  Compile-time typing tends to have that effect, and I'm
wondering how we avoid that problem.

> "isa" as a synonym for "is" that turns on warnings is documented at the end 
> of my paper under "Concepts discussed in this paper that are not on the 
> Synopses".

>From a language design point of view, having both "is" and "isa"
is a dreadfully powerful stink.  Either something need to be unified,
or something needs to be better distinguished.

> Nobody's objected to it. In this group, I'm preaching to the 
> choir anyway.  Everyone knows higher-order typing is the idea, and I'm just 
> trying to work out the ramifications and details that are in-tune with the 
> orthodox documentation and discussions here.

That's fine, but please don't mistake the general silence for anything
other than people's eyes glazing over.  If a fancy concept can't be
made easily understandable to the general public (or can't at least
be hidden from the general public beneath some cargo-cultable syntax),
it's not going into baseline Perl 6.  I can be pretty clever at times,
but right now I'm standing up for Joe Blow, who doesn't give a rip
about orthodoxy.  What's in it for him?

All that being said, I do like the fact that this whole effort is
exploring semantic niches that need to be fleshed out.  I wish I had
time to think through the Perlish answers to some of these good
questions.  I hope other people will continue to participate in
thrashing some of these things out.

Larry

Re: treatment of "isa" and inheritance

[John M. Dlugosz]

Ovid publiustemp-perl6language2-at-yahoo.com |Perl 6| wrote:

So, isn't "isa" and the "£" merely things which can be added by
programmers by changing the grammar?  That was one of the design goals
of the language.

  
The capability needs to exist as part of the overall type system, with 
primitive hooks provided in the metaobjects.  The understanding of 
subtype and F-bounds both need to be built into the "is this type OK?" 
binding logic and the very implementation of binding.  The syntax to 
access these features -- to mark which type uses which matching rules -- 
is far more arbitrary and cosmetic.


The "isa" as a synonym for "is" would be a no-brainer macro.  But 
marking the metaobject with the intention and updating all the calls to 
the metaobject that build the class based on the items in the class's 
main block, to do the subtype covariance/contravariance checking, is 
more than just updating the grammar.  I also have one other trick 
planned -- perhaps using "isa" can suppress virtual type redefinitions, 
if used with suitable modifiers.  That way you can turn off the 
"feature" that is making your parameters covariant without you 
explicitly overriding them.


--John

Re: treatment of "isa" and inheritance

[John M. Dlugosz]

TSa Thomas.Sandlass-at-barco.com |Perl 6| wrote:

HaloO,

John M. Dlugosz wrote:
"isa" as a synonym for "is" that turns on warnings is documented at 
the end of my paper under "Concepts discussed in this paper that are 
not on the Synopses".


I totally agree! Using 'isa' pulls in the type checker. Do we have the
same option for 'does' e.g. 'doesa'? Or is type checking always implied
in role composition? Note that the class can override a role's methods
at will.

'doesa'?  I suppose, but I had not thought about it.  The issues are the 
same:  The final type made with composed roles does not have to follow 
subtyping rules with respect to treating the role as an "interface" 
abstract type.






 Nobody's objected to it.  In this group, I'm preaching to the choir 
anyway.  Everyone knows higher-order typing is the idea, and I'm just 
trying to work out the ramifications and details that are in-tune 
with the orthodox documentation and discussions here.


Hmm, I always had the impression of strong headwind.



How so?

Re: treatment of "isa" and inheritance

[Daniel Ruoso]

Qua, 2008-04-30 às 15:55 +0200, TSa escreveu:
> But the type system is part of the language core.
> As such 'isa' and 'like' or assignment and binding semantics
> need a definition.

Actually, this is one of the hardest parts of implementing Perl 6,
because even 'isa', 'like', assignment and binding are dependent on the
representation of the given objects, so even such basic operations are
polymorphic.

This makes the bootstrap of the type system harder, but not impossible.
What happens is that, as it is polymorphic, I can provide known
low-level implementation of higher-level types that will interoperate
transparently with them. By doing that I can bootstrap by special-casing
the low-level implementations and getting out of the water that way.

This also allows some other interesting features, like the fact that I
may have a constant identifier that interoperates with Str while I still
can compare to of them simply by comparing their pointer addresses, or
by providing a shadow object that points to the inner data structure of
other object in order to expose the expected API.

In fact, that is the exact point that makes it possible for Perl 6 to
have a *fully* boostrapped type system. What defines native types in
Perl 6 is not that they have a incompatible lowlevel structure (because
they don't, unless optimized), but that they are the only types that the
interpreter may expect to know how they look like. Everything else
should be opaque to the interpreter (but eventually the optimizer may
have a catalog to inspect the internals directly).

Take a look at 

http://www.perlfoundation.org/perl6/index.cgi?smop_p6opaque_implementation

and at

http://www.perlfoundation.org/perl6/index.cgi?smop_oo_api

To see how that's being implemented in SMOP.

daniel

Pragma for type matching alternative implementations (Was: Re: treatment of "isa" and inheritance)

[Daniel Ruoso]

Ter, 2008-04-29 às 21:03 -0500, John M. Dlugosz escreveu:
> In response to questions on my whitepaper, I made this companion
> to bring people up to speed on the issue.
> 

Very interesting reading... :)

It actually made me think that it would be possible to implement it as a
pragma.

   class A { has $.a };
   class B { has $.b };
   sub foo { A $a } { ... }
   {
   foo(B.new()); # FAIL
   use typematch 'like';
   foo(B.new()); # OK
   use typematch 'does';
   foo(B.new()); # FAIL 
   }

This could be achieved simply by scope-redefining
infix:<~~>(Object,Object) to use another implementation.

(Note that I'm trying at all costs to avoid adding that as a signature
trait, because that would complicate the dispatching ;)

daniel

Re: Polymorphism and Representations (Was: Re: First look: Advanced Polymorphism whitepaper)

[TSa]

HaloO,

John M. Dlugosz wrote:

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.


I guess I also forgot the is rw to get a binding to the caller's
container not the local one of the sub. Otherwise you could write
into the caller's container without rw in the sig.

The issue I want to address is how easy it is to implement
immutable semantics. The ref copying is sort of an annoyance
there.

   class A
   {
   has $.a = 0;
   submethod BUILD ($.a) {}
   method inc ($self is rw:) # get at the container of
   { # of the caller
   $self = self.^new(self.a + 1);
   # return self.^new(self.a + 1) without the rw
   # sadly doesn't work for $x.inc syntax
   }
   }

   my A $a .= new(7);
   my A $b = $a;

   $a === $b; # true
   $a eqv $b; # true

   $a.inc; # shall behave like ++ for Int

   $a === $b; # false
   $a eqv $b; # false

The spec also says that one has to use .=method to call an in-place
mutator. That is $x.inc in Daniel's example should actually mean
$x = $x.inc along the lines that $x++ also means $x = $x + 1.

Finally combine that with the wish to allow literals of class A. Let's
assume the grammar is patched to parse integer literals as As. Then
with the above 7.inc gives an error because 7 is not mutable. So as
I outlined before I want to care for the callers constraint. Perl 6
lacks a syntax for that.


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.


Keep us informed, please.


Regards, TSa.
--

"The unavoidable price of reliability is simplicity"  -- C.A.R. Hoare
1 + 2 + 3 + 4 + ... = -1/12  -- Srinivasa Ramanujan

Re: treatment of "isa" and inheritance

[TSa]

HaloO,

Ovid wrote:

So, isn't "isa" and the "£" merely things which can be added by
programmers by changing the grammar?  That was one of the design goals
of the language.


With a changeable grammar this applies to everything except the
changeability itself. But the type system is part of the language
core. As such 'isa' and 'like' or assignment and binding semantics
need a definition.

Regards, TSa.
--

"The unavoidable price of reliability is simplicity"  -- C.A.R. Hoare
1 + 2 + 3 + 4 + ... = -1/12  -- Srinivasa Ramanujan

Re: treatment of "isa" and inheritance

[Ovid]

--- "John M. Dlugosz" <[EMAIL PROTECTED]> wrote:

> "isa" as a synonym for "is" that turns on warnings is documented at
> the end of my paper under "Concepts discussed in this paper that are 
> not on 
> the Synopses".  Nobody's objected to it.  In this group, I'm
> preaching to the choir anyway.

So, isn't "isa" and the "£" merely things which can be added by
programmers by changing the grammar?  That was one of the design goals
of the language.

Cheers,
Ovid

--
Buy the book  - http://www.oreilly.com/catalog/perlhks/
Perl and CGI  - http://users.easystreet.com/ovid/cgi_course/
Personal blog - http://publius-ovidius.livejournal.com/
Tech blog - http://use.perl.org/~Ovid/journal/

Re: Polymorphism and Representations (Was: Re: First look: Advanced Polymorphism whitepaper)

[TSa]

HaloO,

Daniel Ruoso wrote:

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


I see all your messages arrive twice.



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?


Isn't that up to the implementation as well? E.g. on a 32bit platform
use an unsigned 32bit integer. The only things that should not happen
is that you let it leak onto the value level or that WHICHes of
differently typed objects are compared.

With leaking to the value level I mean allowing $x.WHICH == 42 even
if it is known that WHICH is implemented with a number.



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.


Ups, no object can override eqv or any other binary method. These
live outside of HOW space. You can insert your dispatch targets
but that's about it.



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.


I don't understand your motivation, but I think it is the obsession with
object identity. You say that the object changes class, i.e. its HOW or
WHAT changes while perhaps keeping its WHICH. But eqv, === and ~~ are
defined outside of the class or object system. There is an inheritance
order on HOW space and a subtyping order on WHAT space. Class based
dispatch goes along the former, type based dispatch along the latter.
The object that changes class should not be eqv or === to itself before
the transition or nominal typing becomes absurd.


Regards, TSa.
--

"The unavoidable price of reliability is simplicity"  -- C.A.R. Hoare
1 + 2 + 3 + 4 + ... = -1/12  -- Srinivasa Ramanujan

Re: treatment of "isa" and inheritance

[TSa]

HaloO,

John M. Dlugosz wrote:
"isa" as a synonym for "is" that turns on warnings is documented at the 
end of my paper under "Concepts discussed in this paper that are not on 
the Synopses".


I totally agree! Using 'isa' pulls in the type checker. Do we have the
same option for 'does' e.g. 'doesa'? Or is type checking always implied
in role composition? Note that the class can override a role's methods
at will.


 Nobody's objected to it.  In this group, I'm preaching 
to the choir anyway.  Everyone knows higher-order typing is the idea, 
and I'm just trying to work out the ramifications and details that are 
in-tune with the orthodox documentation and discussions here.


Hmm, I always had the impression of strong headwind.


Regards, TSa.
--

"The unavoidable price of reliability is simplicity"  -- C.A.R. Hoare
1 + 2 + 3 + 4 + ... = -1/12  -- Srinivasa Ramanujan

Re: treatment of "isa" and inheritance

[John M. Dlugosz]

TSa Thomas.Sandlass-at-barco.com |Perl 6| wrote:

HaloO John,

interesting to note that you are now nailing down things that
I'm advocating for quite a while. Are you sure that Perlkind
is following? E.g. $Larry hasn't written 'isa' into S12 yet.

Regards, TSa.
I am listening.  I'm synthesizing and documenting.  I'm also 
disappointed with the lack of feedback from Larry, considering the 
amount of effort and time I'm putting into it.  But I'm sure he'll 
squawk if I say something really off, rather than flesh out the existing 
skeleton.


"isa" as a synonym for "is" that turns on warnings is documented at the 
end of my paper under "Concepts discussed in this paper that are not on 
the Synopses".  Nobody's objected to it.  In this group, I'm preaching 
to the choir anyway.  Everyone knows higher-order typing is the idea, 
and I'm just trying to work out the ramifications and details that are 
in-tune with the orthodox documentation and discussions here.


--John

Re: treatment of "isa" and inheritance

[John M. Dlugosz]

TSa Thomas.Sandlass-at-barco.com |Perl 6| wrote:

HaloO,

just to deepen your understanding of co- and contravariance
you should digest <http://www.pps.jussieu.fr/~gc/papers/toplas95.pdf>
The important point to get from it is that dispatch-relevant
parameters are also covariant.


Regards, TSa.

Thanks for the link.

I did mention that the invocant was an exception, since it is already 
known to be the correct type.

Re: treatment of "isa" and inheritance

[TSa]

HaloO John,

interesting to note that you are now nailing down things that
I'm advocating for quite a while. Are you sure that Perlkind
is following? E.g. $Larry hasn't written 'isa' into S12 yet.

Regards, TSa.
--

"The unavoidable price of reliability is simplicity"  -- C.A.R. Hoare
1 + 2 + 3 + 4 + ... = -1/12  -- Srinivasa Ramanujan

Re: treatment of "isa" and inheritance

[TSa]

HaloO,

just to deepen your understanding of co- and contravariance
you should digest <http://www.pps.jussieu.fr/~gc/papers/toplas95.pdf>
The important point to get from it is that dispatch-relevant
parameters are also covariant.


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)

[Daniel Ruoso]

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

treatment of "isa" and inheritance

[John M. Dlugosz]

In response to questions on my whitepaper, I made this companion
to bring people up to speed on the issue.



"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)

[Daniel Ruoso]

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

Re: Polymorphism and Representations (Was: Re: First look: Advanced Polymorphism whitepaper)

[John M. Dlugosz]

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

Re: Polymorphism and Representations (Was: Re: First look: Advanced Polymorphism whitepaper)

[John M. Dlugosz]

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]

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: with the rational that this always is a
test not a modifying call like infix:. But I would
like to reserve infix: 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]

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

[John M. Dlugosz]

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)

[Daniel Ruoso]

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)

[Daniel Ruoso]

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)

[TSa]

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

Re: Polymorphism and Representations (Was: Re: First look: Advanced Polymorphism whitepaper)

[TSa]

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

Polymorphism and Representations (Was: Re: First look: Advanced Polymorphism whitepaper)

[Daniel Ruoso]

Seg, 2008-04-28 às 10:15 -0700, Jon Lang escreveu:
> Ah; that clears things up considerably.  If I understand you
> correctly, John is using '£' to mean "use Duck Typing here".  _That_,
> I can definitely see uses for.

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)

which is implementation specific, but as for what it's worth, might be
abasolutely anything that says true to that call, even if it's just a
reference to a pointer in a low-level binding of some library...

The point I'm trying to make is that Perl 6 already accepts anything
that "does" Point, even if it "isn't" a Point, that happens basically
because Perl 6 have polymorphic representation.

That actually means that you *never* can count on knowing how the
object is implemented (except for native types, of course). So there's
actually no need for the "like" idiom, because there's no "true isa" in
Perl 6.

In Perl 6 one object "isa" something as long as it says true to "isa"
something. The only exceptions are the native types, see
http://www.perlfoundation.org/perl6/index.cgi?smop_native_types for a
little longer reasoning on that.

daniel

Re: Context and return types question

[John M. Dlugosz]

Brandon S. Allbery KF8NH allbery-at-ece.cmu.edu |Perl 6| wrote:



 my ($x, :$named) = foo;   # or something like that


That looks to me like a form of positional extraction.  (Of course, my 
hit rate on p6 stuff has been remarkably low of late...)





It's not just positional, but allows for named arguments too.  It is 
exactly like calling a function: named arguments match to parameters 
with those names, then any left over are positional.

Re: Context and return types question

[Brandon S. Allbery KF8NH]

On Apr 21, 2008, at 9:39 , John M. Dlugosz wrote:


TSa Thomas.Sandlass-at-barco.com |Perl 6| wrote:
I think the type is just :( $: :named$ ) if you want to extract  
the invocant with a $ prefix. Otherwise it would be :( $, :named 
$ ) and you

extract the item positionally with prefix @ or .[].

I don't want to have to "extract" it.  I want to be able to say

     $x = foo

and get the single value return from foo, and only dress it up if I  
want the optional secondary returns


 my ($x, :$named) = foo;   # or something like that


That looks to me like a form of positional extraction.  (Of course,  
my hit rate on p6 stuff has been remarkably low of late...)


--
brandon s. allbery [solaris,freebsd,perl,pugs,haskell] [EMAIL PROTECTED]
system administrator [openafs,heimdal,too many hats] [EMAIL PROTECTED]
electrical and computer engineering, carnegie mellon universityKF8NH

Re: Context and return types question

[TSa]

HaloO,

John M. Dlugosz wrote:

I don't want to have to "extract" it.  I want to be able to say

 $x = foo


I guess that does not collapse the capture that foo returns. So
it goes into $x unaltered. If you later use $x as an invocant
of a method this extracts the invocant slot from the capture.
And $x works as expected.


and get the single value return from foo, and only dress it up if I want 
the optional secondary returns


 my ($x, :$named) = foo;   # or something like that


Should work.



Sorry, you lost me again.


Single-assignment is a feature from constraint programming e.g. in Oz.
There you have a single-assignment store. I interpreted Larry's comment
on my coro question as making single-assignment semantics first-class
and everything else second-class.

A capture can contain an array that later on can change its content:

  @a = 1,2,3;
  @b = 4,5,6;
  @c = 7,8,9;
  $cap = \(@a,@b);

  $cap[0]   = @c; # error
  $cap[0][] = @c; # ok, @a now 7,8,9

Writing into a container is contra-variant. Reading is co-variant.
So a capture has to be invariant. Assume A <: B <: C and regard

my A $a;
my C $c;

my B $ba := $a; # ok for reading from $a
my B $bc := $c; # ok for writing into $c

Both bindings are type errors. If captures were recursively immutable
you could allow bindings ala $ba. Well, or we interpret $a and $b as
typed views of whatever value they lead to. This insures that there
will never be assignment or binding type errors.


Regards, TSa.
--

"The unavoidable price of reliability is simplicity"
  -- C.A.R. Hoare

Re: Context and return types question

[John M. Dlugosz]

TSa Thomas.Sandlass-at-barco.com |Perl 6| wrote:


I guess with strong you mean as lossless as possible?

I think the type is just :( $: :named$ ) if you want to extract the 
invocant with a $ prefix. Otherwise it would be :( $, :named$ ) and you
extract the item positionally with prefix @ or .[]. 

I don't want to have to "extract" it.  I want to be able to say

     $x = foo

and get the single value return from foo, and only dress it up if I want 
the optional secondary returns


 my ($x, :$named) = foo;   # or something like that





Note that Captures
are immutable and therefore nicely covariant. Except of course that
containers are captured as containers and can be mutated. But Larry
revealed that single assignment semantics are aspired and mutability
is a historic artifact or so.


Regards, TSa.


Sorry, you lost me again.

Re: Context and return types question

[TSa]

HaloO,

John M. Dlugosz wrote:
Great.  So the flip side is, what do I return from a function so that it 
gives a single value if called simply, but provides optional named 
returns that are there if you catch them?  As a capture with one 
positional and one named argument?


Yeah, just that.



And how do you declare =that= return type ("of" type) to be strongly typed?


I guess with strong you mean as lossless as possible?

I think the type is just :( $: :named$ ) if you want to extract the 
invocant with a $ prefix. Otherwise it would be :( $, :named$ ) and you

extract the item positionally with prefix @ or .[]. Note that Captures
are immutable and therefore nicely covariant. Except of course that
containers are captured as containers and can be mutated. But Larry
revealed that single assignment semantics are aspired and mutability
is a historic artifact or so.


Regards, TSa.
--

"The unavoidable price of reliability is simplicity"
  -- C.A.R. Hoare

Re: Context and return types question

[TSa]

HaloO,

Larry Wall wrote:

In general, we're trying to get away from want-based context dependency
and instead attempting to encourage lazy semantic constructs such
as Captures that can behave with a wide dynamic range when actually
bound later.


Shouldn't we then change the heading of the respective section
from "Advanced Subroutine Features" to "Deprecated Subroutine
Features"?



For instance, Arrays now behave such that, if you use one in numeric
context, you get the number of elements, so unlike in Perl 5, you need
not decide at return time whether the array is in item or list context.
You just return the array, and it will act much like it does in Perl 5
if you use it in a numeric or boolean context.  Since the default
return type is Capture, it doesn't matter if you declare the "of"
type as Array or not, since the Capture doesn't force either item or
list context on the Array either.  It should behave much the same in
either case, except that if you declare the "of" type as Array, you
give the compiler/optimizer/type inferencer more information to work
with at compile time.


Note that this implies Seq <: Num <: Item <: Seq which is a cycle!
Dealing with cycles is not within the reach of type system because
these need <: to be transitive.


Regards, TSa.
--

"The unavoidable price of reliability is simplicity"
  -- C.A.R. Hoare

Re: Context and return types question

[TSa]

HaloO,

John M. Dlugosz wrote:

How about sub foo (--> Seq^Item) {...}?

Interesting idea, but that doesn't tell the compiler that the return is 
keyed to the context.  The compiler should know what return type to 
expect, if only I could explain it.


Sorry, the type has nothing to do with how the function comes up with
its return value. In that respect you must regard the context as part
of the input of the function that of course influences its output.


I don't see how Seq^Item as a type is any different than Seq|Item.  It 
can only hold one at a time anyway.


A type is a type. There is nothing that varies or holds a value or some
such. Seq|Item means to me that there are three cases: Seq only, Item
only and both. Seq^Item excludes the latter. That is Seq^Item is the
disjoint union of Seq and Item. Larry's reply essentially means
Item <: Seq that is Seq subsumes Item. But that has problems of its
own---see my reply there.


Regards, TSa.
--

"The unavoidable price of reliability is simplicity"
  -- C.A.R. Hoare

Re: Context and return types question

[John M. Dlugosz]

Great.  So the flip side is, what do I return from a function so that it 
gives a single value if called simply, but provides optional named 
returns that are there if you catch them?  As a capture with one 
positional and one named argument?


And how do you declare =that= return type ("of" type) to be strongly typed?

--John

Larry Wall larry-at-wall.org |Perl 6| wrote:

On Fri, Apr 18, 2008 at 05:34:25AM -0500, John M. Dlugosz wrote:
  
If a function returns different things if called in list context or item 
context, how do you define the "of" type (outer return type) to make the 
function strongly typed?



You can't.  An "of" type forces the function into a single context
(unless we allow polymorphic return types as TSa mentions).

In general, we're trying to get away from want-based context dependency
and instead attempting to encourage lazy semantic constructs such
as Captures that can behave with a wide dynamic range when actually
bound later.

For instance, Arrays now behave such that, if you use one in numeric
context, you get the number of elements, so unlike in Perl 5, you need
not decide at return time whether the array is in item or list context.
You just return the array, and it will act much like it does in Perl 5
if you use it in a numeric or boolean context.  Since the default
return type is Capture, it doesn't matter if you declare the "of"
type as Array or not, since the Capture doesn't force either item or
list context on the Array either.  It should behave much the same in
either case, except that if you declare the "of" type as Array, you
give the compiler/optimizer/type inferencer more information to work
with at compile time.

Larry

  

Re: Context and return types question

[John M. Dlugosz]

If a function returns different things if called in list context or
item context, how do you define the "of" type (outer return type) to
make the function strongly typed?


How about sub foo (--> Seq^Item) {...}?



Interesting idea, but that doesn't tell the compiler that the return is 
keyed to the context.  The compiler should know what return type to 
expect, if only I could explain it.


I don't see how Seq^Item as a type is any different than Seq|Item.  It 
can only hold one at a time anyway.