Re: First look: Advanced Polymorphism whitepaper

2008-05-02 Thread John M. Dlugosz
Jonathan Worthington jonathan-at-jnthn.net |Perl 6| wrote: $x.nosuchmethod; will give a compile-time error if nosuchmethod is not declared as part of CGI::Simple. Is this spec'd somewhere? I don't think we can statically know what methods CGI::Simple will have at compile time. What if I do a "

Re: treatment of "isa" and inheritance

2008-05-02 Thread 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 ar

Re: "All classes imply the existence of a role of the same name."

2008-05-02 Thread Andy_Bach
> What's the point of omnipotence if you can't swoop down from the rafters once in a while and save your hero from almost certain peril? To quote *Larry from "Time Bandits" - "er, something to do with free will." a --- Andy Bach Systems Mangler Internet: [EMAIL PROTECTED] Voic

Re: treatment of "isa" and inheritance

2008-05-02 Thread 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 termin

Re: "All classes imply the existence of a role of the same name."

2008-05-02 Thread chromatic
On Friday 02 May 2008 16:07:56 John M. Dlugosz wrote: > chromatic chromatic-at-wgz.org |Perl 6| wrote: > Why is there any difference in declaring classes and roles if a class > can be used as the target of either 'is' or 'does'? You can't instantiate a role. You can instantiate a class. When y

Re: First look: Advanced Polymorphism whitepaper

2008-05-02 Thread John M. Dlugosz
chromatic chromatic-at-wgz.org |Perl 6| wrote: Do we face a similar rug-yanking situation with delegatee classes being modified after delegate instantiation? I know there are some types of auto-handling, but are they all automatic? -- c In the sense that the more detailed formal documen

Re: "All classes imply the existence of a role of the same name."

2008-05-02 Thread John M. Dlugosz
Larry Wall larry-at-wall.org |Perl 6| wrote: On Fri, May 02, 2008 at 12:22:00PM -0700, chromatic wrote: : On Friday 02 May 2008 11:44:40 John M. Dlugosz wrote: : : > chromatic chromatic-at-wgz.org |Perl 6| wrote: : : > > All classes imply the existence of a role of the same name. : : > Please

Re: First look: Advanced Polymorphism whitepaper

2008-05-02 Thread John M. Dlugosz
TSa Thomas.Sandlass-at-barco.com |Perl 6| wrote: Would you be so kind to enlighten me what the type system is, if not a type calculation overlaid over a value calculation? Regards, TSa. The other day I put it for those not following the scholarly stuff: The questions of “can this substitute

Re: treatment of "isa" and inheritance

2008-05-02 Thread 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 tr

Re: First look: Advanced Polymorphism whitepaper

2008-05-02 Thread John M. Dlugosz
Larry Wall larry-at-wall.org |Perl 6| wrote: If a role is derived from a class, According to S12: "A role may not inherit from a class..." it must of necessity be a snapshot of the class, because roles are immutable, while classes are not. The only interesting question in my mind is whethe

Re: First look: Advanced Polymorphism whitepaper

2008-05-02 Thread Jonathan Worthington
John M. Dlugosz wrote: Andy_Bach-at-wiwb.uscourts.gov |Perl 6| wrote: in. Er, so would: my CGI::Simple $x .= new; my $y = CGI::Simple.new; mean that: $x $y is not true? Or would there be a way to tell them apart, on a class (?) level. The actual dynamic type at run time of the values i

Re: "All classes imply the existence of a role of the same name."

2008-05-02 Thread John M. Dlugosz
chromatic chromatic-at-wgz.org |Perl 6| wrote: http://www.perlfoundation.org/perl6/index.cgi?perl_6_people I could edit it into a Synopsis if you really want. -- c Or just explain the reasoning that's missing now. Why is there any difference in declaring classes and roles if a class can

Re: First look: Advanced Polymorphism whitepaper

2008-05-02 Thread Daniel Ruoso
Sex, 2008-05-02 às 21:22 +0200, TSa escreveu: > Or do you mean backwards in the sense that the priority is with the > object somehow? In fact, it simply means that it's up to that object's metaobject to answer that, and not to a supra-meta-model to be able to answer to all of the possible metamod

Re: First look: Advanced Polymorphism whitepaper

2008-05-02 Thread John M. Dlugosz
Andy_Bach-at-wiwb.uscourts.gov |Perl 6| wrote: in. Er, so would: my CGI::Simple $x .= new; my $y = CGI::Simple.new; mean that: $x $y is not true? Or would there be a way to tell them apart, on a class (?) level. The actual dynamic type at run time of the values in $x and $y are both

Re: First look: Advanced Polymorphism whitepaper

2008-05-02 Thread Daniel Ruoso
Sex, 2008-05-02 às 21:49 +0200, TSa escreveu: > Daniel Ruoso wrote: > > In fact, it simply means that it's up to that object's metaobject to > > answer that, and not to a supra-meta-model to be able to answer to all > > of the possible metamodel implementations. > Since all three forms are derived

Re: First look: Advanced Polymorphism whitepaper

2008-05-02 Thread Daniel Ruoso
Sex, 2008-05-02 às 18:55 +0200, TSa escreveu: > For me, too. But note that we should keep does the ultimate > type checker that first checks the declared presence of a role, > then falls back to a declared class inheritance and then falls > back to a declared emulation. What else should be in this

Re: First look: Advanced Polymorphism whitepaper

2008-05-02 Thread Daniel Ruoso
Sex, 2008-05-02 às 09:08 -0500, John M. Dlugosz escreveu: > A syntax is needed for this express concept: "accept B as a substitute > for A", without changing A. Which I'm advocating as class CGI::Simple realises CGI { ... } or CGI::Simple is also { realises CGI } or even... $c

Re: treatment of "isa" and inheritance

2008-05-02 Thread 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

Re: "All classes imply the existence of a role of the same name."

2008-05-02 Thread Austin Hastings
John M. Dlugosz wrote: chromatic chromatic-at-wgz.org |Perl 6| wrote: All classes imply the existence of a role of the same name. Please justify that. A class is an defined, referenceable entity with a "signature" composed of the bits visible to a particular caller. It is possible, by d

Re: "All classes imply the existence of a role of the same name."

2008-05-02 Thread chromatic
On Friday 02 May 2008 13:11:55 Larry Wall wrote: > On Fri, May 02, 2008 at 12:22:00PM -0700, chromatic wrote: > : I could edit it into a Synopsis if you really want. > Tweet! Foul on #17. Two shots! What's the point of omnipotence if you can't swoop down from the rafters once in a while and

Re: First look: Advanced Polymorphism whitepaper

2008-05-02 Thread chromatic
On Friday 02 May 2008 12:48:43 Larry Wall wrote: > On Fri, May 02, 2008 at 12:21:27PM -0700, chromatic wrote: > : I'm not sure which is best. Snapshotting at the time of first > : composition (or the first time someone says "Hey, I provide that other > : class's role!") seems right though. > Or

Re: "All classes imply the existence of a role of the same name."

2008-05-02 Thread Larry Wall
On Fri, May 02, 2008 at 12:22:00PM -0700, chromatic wrote: : On Friday 02 May 2008 11:44:40 John M. Dlugosz wrote: : : > chromatic chromatic-at-wgz.org |Perl 6| wrote: : : > > All classes imply the existence of a role of the same name. : : > Please justify that. : : http://www.perlfoundation.or

Re: First look: Advanced Polymorphism whitepaper

2008-05-02 Thread TSa
HaloO, Daniel Ruoso wrote: In fact, it simply means that it's up to that object's metaobject to answer that, and not to a supra-meta-model to be able to answer to all of the possible metamodel implementations. Since all three forms are derived from a programmer's declaration involving names th

Re: First look: Advanced Polymorphism whitepaper

2008-05-02 Thread Larry Wall
On Fri, May 02, 2008 at 12:21:27PM -0700, chromatic wrote: : On Friday 02 May 2008 11:55:54 Larry Wall wrote: : > The only interesting question in my mind is whether you can take : > another snapshot and override the previous one somehow, or whether : > such derived roles should version themselves

Re: First look: Advanced Polymorphism whitepaper

2008-05-02 Thread TSa
HaloO, Daniel Ruoso wrote: You're taking it backwards, it's not the type checker that is aware of that, but each object's metamodel. The metamodel protocol is just the "do you 'Dog'?" thing. Backwards in the sequence of checks? That is we check emulation first, then class inheritance and then

Re: "All classes imply the existence of a role of the same name."

2008-05-02 Thread chromatic
On Friday 02 May 2008 11:44:40 John M. Dlugosz wrote: > chromatic chromatic-at-wgz.org |Perl 6| wrote: > > All classes imply the existence of a role of the same name. > Please justify that. http://www.perlfoundation.org/perl6/index.cgi?perl_6_people I could edit it into a Synopsis if you reall

Re: First look: Advanced Polymorphism whitepaper

2008-05-02 Thread chromatic
On Friday 02 May 2008 11:55:54 Larry Wall wrote: > On Fri, May 02, 2008 at 11:15:34AM -0700, chromatic wrote: > : All classes imply the existence of a role of the same name. > If a role is derived from a class, it must of necessity be a snapshot > of the class, because roles are immutable, while

Re: First look: Advanced Polymorphism whitepaper

2008-05-02 Thread TSa
HaloO, Larry Wall wrote: I don't think most people want to think of functions as types--it just clutters up the type namespace. Which contradicts their first-class status. They can already say: sub mysubuser ( &f where &mysub.sig ) {...} or some such to do explicit smartmatching agai

Re: First look: Advanced Polymorphism whitepaper

2008-05-02 Thread Larry Wall
On Fri, May 02, 2008 at 11:15:34AM -0700, chromatic wrote: : On Friday 02 May 2008 07:08:21 John M. Dlugosz wrote: : : > TSa Thomas.Sandlass-at-barco.com |Perl 6| wrote: : : > > Then, since classes are open, the programmer can easily say : > > : > > CGI does CGI::Simple; : > : > That would be :

Re: First look: Advanced Polymorphism whitepaper

2008-05-02 Thread John M. Dlugosz
mark.a.biggar-at-comcast.net |Perl 6| wrote: For me, too. But note that we should keep does the ultimate type checker that first checks the declared presence of a role, then falls back to a declared class inheritance and then falls back to a declared emulation. What else should be in this check

Re: "All classes imply the existence of a role of the same name."

2008-05-02 Thread John M. Dlugosz
chromatic chromatic-at-wgz.org |Perl 6| wrote: On Friday 02 May 2008 07:08:21 John M. Dlugosz wrote: TSa Thomas.Sandlass-at-barco.com |Perl 6| wrote: Then, since classes are open, the programmer can easily say CGI does CGI::Simple; That would be class CGI is also { d

Re: First look: Advanced Polymorphism whitepaper

2008-05-02 Thread chromatic
On Friday 02 May 2008 07:08:21 John M. Dlugosz wrote: > TSa Thomas.Sandlass-at-barco.com |Perl 6| wrote: > > Then, since classes are open, the programmer can easily say > > > > CGI does CGI::Simple; > > That would be > > class CGI is also { does CGI::Simple } > > and means that CGI::Simple is

Re: First look: Advanced Polymorphism whitepaper

2008-05-02 Thread mark . a . biggar
-- Original message -- From: TSa <[EMAIL PROTECTED]> > HaloO, > > John M. Dlugosz wrote: > >> Maybe we already have this--see "emulates" in S11. > > Works for me. > > For me, too. But note that we should keep does the ultimate > type checker that first checks the

Re: First look: Advanced Polymorphism whitepaper

2008-05-02 Thread Larry Wall
On Fri, May 02, 2008 at 11:34:33AM +0200, TSa wrote: > My idea is that foo:( Foo &f ) should mean the same as > foo:( Foo $x ), that is the variables have to contain a > value that does Foo. No, I think &f should be treated more like @f and %f as a composite object with a normal return type for th

Re: Polymorphism and Representations

2008-05-02 Thread 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

Re: First look: Advanced Polymorphism whitepaper

2008-05-02 Thread TSa
HaloO, John M. Dlugosz wrote: Maybe we already have this--see "emulates" in S11. Works for me. For me, too. But note that we should keep does the ultimate type checker that first checks the declared presence of a role, then falls back to a declared class inheritance and then falls back to a d

Re: First look: Advanced Polymorphism whitepaper

2008-05-02 Thread TSa
HaloO, I wrote: I'm actually not sure that you can have 'CGI does CGI::Simple', since CGI::Simple is not a role... An intermediate, anonymous class is a mere implementation detail ;) Sorry I meant an anonymous role created from the definition of CGI::simple. Assuming compatibility of CGI wit

Re: Polymorphism and Representations

2008-05-02 Thread 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

Re: First look: Advanced Polymorphism whitepaper

2008-05-02 Thread John M. Dlugosz
Larry Wall larry-at-wall.org |Perl 6| wrote: On Fri, May 02, 2008 at 08:30:25AM -0500, John M. Dlugosz wrote: I agree. If typing is turned on, you want errors if you pass the wrong type. You have to explicitly declare that Bar is an acceptable substitute for Foo. Maybe we already ha

Re: First look: Advanced Polymorphism whitepaper

2008-05-02 Thread John M. Dlugosz
Daniel Ruoso daniel-at-ruoso.com |Perl 6| wrote: Sex, 2008-05-02 às 09:08 -0500, John M. Dlugosz escreveu: A syntax is needed for this express concept: "accept B as a substitute for A", without changing A. Which I'm advocating as class CGI::Simple realises CGI { ... } or

Re: OK, ::?CLASS not virtual

2008-05-02 Thread TSa
HaloO, John M. Dlugosz wrote: Larry Wall larry-at-wall.org |Perl 6| wrote: I don't like using ::?CLASS for something that is not a compile-time constant. ... we don't use ::?SELF anymore, but "self", because that can vary in meaning dynamically OK, for some meaning of "constant". After al

Re: First look: Advanced Polymorphism whitepaper

2008-05-02 Thread Larry Wall
On Fri, May 02, 2008 at 08:47:28AM -0500, John M. Dlugosz wrote: > In Perl 6, within a signature > >sub foo ( &f:(Int-->Int) ) >sub foo ( Continuous &f ) > > The latter says that &f is of type Continuous, not that the return type is > Continuous. That is what you want, right? The latte

Re: Polymorphism and Representations

2008-05-02 Thread 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 havin

Re: First look: Advanced Polymorphism whitepaper

2008-05-02 Thread Larry Wall
On Fri, May 02, 2008 at 08:30:25AM -0500, John M. Dlugosz wrote: > I agree. If typing is turned on, you want errors if you pass the wrong > type. You have to explicitly declare that Bar is an acceptable substitute > for Foo. Maybe we already have this--see "emulates" in S11. Larry

Re: First look: Advanced Polymorphism whitepaper

2008-05-02 Thread John M. Dlugosz
TSa Thomas.Sandlass-at-barco.com |Perl 6| wrote: Then, since classes are open, the programmer can easily say CGI does CGI::Simple; That would be class CGI is also { does CGI::Simple } and means that CGI::Simple is a role, meant to serve as an interface specification. It's not, it is a

Re: Polymorphism and Representations

2008-05-02 Thread 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

Re: First look: Advanced Polymorphism whitepaper

2008-05-02 Thread John M. Dlugosz
Ovid publiustemp-perl6language2-at-yahoo.com |Perl 6| wrote: Implemented as: method read ( --> Boolean ) { ... } (How do I specify no args and a Boolean return type?) Take your pick: our Bool method read () { ... } method read (-->Bool) { ... } method read () of Bool { ... }

Re: treatment of "isa" and inheritance

2008-05-02 Thread 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? Mayb

Re: First look: Advanced Polymorphism whitepaper

2008-05-02 Thread John M. Dlugosz
TSa Thomas.Sandlass-at-barco.com |Perl 6| wrote: sub graph ( &func where {.does: Continuous}, Num $from, Num $to ) {...} sub square ( Num $x --> Num ) does Continuous { return $x * $x } graph( &square, -10.0, 10.0 ); # type correct The odd thing to me is that graph cannot be defined a

Re: First look: Advanced Polymorphism whitepaper

2008-05-02 Thread TSa
HaloO, Daniel Ruoso wrote: Not really... 'does' will try to compose the CGI::Simple methods to the CGI class (although I think your example was supposed to be CGI::Simple does CGI, but anyway). Hardly. Ovid said that CGI has more functionality than CGI::Simple. So the hope for CGI.does(CGI::Si

Re: treatment of "isa" and inheritance

2008-05-02 Thread 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

Re: First look: Advanced Polymorphism whitepaper

2008-05-02 Thread Daniel Ruoso
Sex, 2008-05-02 às 14:38 +0200, TSa escreveu: > Ovid wrote: > > However, the CGI/CGI::Simple example I posted earlier doesn't fulfill > > this. CGI::Simple offers a subset of CGI.pm's functionality and it's > > guaranteed to be identical > Then, since classes are open, the programmer can easily s

Re: treatment of "isa" and inheritance

2008-05-02 Thread 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'?". S

Re: First look: Advanced Polymorphism whitepaper

2008-05-02 Thread John M. Dlugosz
chromatic chromatic-at-wgz.org |Perl 6| wrote: If I tell the type system that Foo and Bar are equivalent, then they're equivalent even if they have different internal structures and no other relationship in an inheritance sense. I agree. If typing is turned on, you want errors if you pa

Re: First look: Advanced Polymorphism whitepaper

2008-05-02 Thread John M. Dlugosz
Ovid publiustemp-perl6language2-at-yahoo.com |Perl 6| wrote: However, the CGI/CGI::Simple example I posted earlier doesn't fulfill this. CGI::Simple offers a subset of CGI.pm's functionality and it's guaranteed to be identical (it doesn't have HTML generation functionality and the procedural/OO

Re: treatment of "isa" and inheritance

2008-05-02 Thread 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: First look: Advanced Polymorphism whitepaper

2008-05-02 Thread TSa
HaloO, Ovid wrote: However, the CGI/CGI::Simple example I posted earlier doesn't fulfill this. CGI::Simple offers a subset of CGI.pm's functionality and it's guaranteed to be identical Then, since classes are open, the programmer can easily say CGI does CGI::Simple; and let go CGI instanc

Re: Polymorphism and Representations

2008-05-02 Thread 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

Re: treatment of "isa" and inheritance

2008-05-02 Thread 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 eve

Re: First look: Advanced Polymorphism whitepaper

2008-05-02 Thread Ovid
--- "John M. Dlugosz" <[EMAIL PROTECTED]> wrote: > chromatic chromatic-at-wgz.org |Perl 6| wrote: > > This is why roles-as-types is so important: type inferencers can't > infer > > allomorphism because allomorphism relies on explicitly-marked > semantic > > meanings. > > > > What is your nom

Re: First look: Advanced Polymorphism whitepaper

2008-05-02 Thread Ovid
--- chromatic <[EMAIL PROTECTED]> wrote: > Given: > > my $result = $thingie.bark; > > ... where $thingie may be a Dog or $thingie may be a Tree, is "bark" > a noun or a verb? > > Sure, it's a lousy example, but remember the immutable law of OO > didactics: > all examples must be terrible

Re: treatment of "isa" and inheritance

2008-05-02 Thread 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 elsewh

Re: treatment of "isa" and inheritance

2008-05-02 Thread 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

Re: treatment of "isa" and inheritance

2008-05-02 Thread 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 possi

Re: treatment of "isa" and inheritance

2008-05-02 Thread 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

Re: First look: Advanced Polymorphism whitepaper

2008-05-02 Thread TSa
HaloO, chromatic wrote: What are marked semantic meanings? Types. That is, in the context of "Dog", "bark" means "emit a sound". In the context of "Tree", "bark" means "the outer skin". Note that the only things that carry meaning in your other example my $result = $thingie.bark; are

Re: First look: Advanced Polymorphism whitepaper

2008-05-02 Thread chromatic
On Thursday 01 May 2008 06:35:12 John M. Dlugosz wrote: > chromatic chromatic-at-wgz.org |Perl 6| wrote: > > This is why roles-as-types is so important: type inferencers can't infer > > allomorphism because allomorphism relies on explicitly-marked semantic > > meanings. > What is your nomenclatu