Huffman encoding (was Re: treatment of isa and inheritance)
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
Re: treatment of isa and inheritance
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
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
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
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 [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 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: treatment of isa and inheritance
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
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 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
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
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
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: treatment of isa and inheritance
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 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 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
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 [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: treatment of isa and inheritance
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
Pragma for type matching alternative implementations (Was: Re: treatment of isa and inheritance)
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.
http://www.dlugosz.com/Perl6/web/isa-inheritance.html
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: treatment of isa and inheritance
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
Re: treatment of isa and inheritance
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
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
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: treatment of isa and inheritance
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
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
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
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
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
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
treatment of isa and inheritance
In response to questions on my whitepaper, I made this companion to bring people up to speed on the issue. http://www.dlugosz.com/Perl6/web/isa-inheritance.html Think you know what “polymorphism” means? Well, the Object-Oriented textbooks have been keeping a dirty little secret from you. Polymorphism isn’t just the base/derived reuse capability you know from modern languages. That is just one limited way that these languages support polymorphism. If you’ve done any template metaprogramming or used the C++ STD much, you might be seeing another way to support it.
