2 questions on S12
Question 1:
What is meant by:
has $attribute # lexical alias for $!attribute.
Here is more concrete example. There is none in S12.
class C {
has $a;
method foo ()
{
my $y = $a; # is the correct?
}
In that scope, is $a really a shortcut for $self!a ?
If so, is that really a good idea?
If not, please clarify.
Question 2:
Here is summary of what is said in S12 concerning these declarators, used
inside a class:
my $.var class attribute, plus generates accessor, not inheritable. (The
variable itself or the accessor is not inheritable?)
my $!var class attribute, no accessor, not inheritable. How is this
different from a normal lexical variable? Role composition can show
differences?
our $.var class attribute, accessor, inheritable.
our $!var class attribute, no accessor, inheritable.
my $var lexically scoped variable
our $attribute class attributes.
What do you mean by "inheritable"? Does the form our $!var make sense or is
that an oxymoron? How is my $var with no metaclass involvement different in
functionality from my $.var ? Likewise for 'our' with and without a twigil. 6
ways to define class attributes -- TIMTOYTDI for sure.
I can take the issue to think through the details and write it up. But, what
central point is it trying to embody? Here is a first cut:
* my and our *always* work in the usual way for the declared symbol. Don't
worry about funny twigil names or the fact that it's inside a class.
* the . twigil makes an accessor in the class itself for that value.
*? so, the ! twigil doesn't seem to accomplish anything in this situation
Re: Context and return types question
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: Class names are virtual
TSa Thomas.Sandlass-at-barco.com |Perl 6| wrote: Second, I don't like the concept of a virtual method that returns a type. That horribly mixes type level and value level. From the They are mixed! Perl treats types as first-class objects. For functions, types don't need to be treated specially from other arguments as in C++. OUTER::C is lexical. But it sounds like the explanation you are giving is the same.
Re: Context and return types question
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: Class names are virtual
HaloO,
John M. Dlugosz wrote:
I hope you have a few minutes to look it over.
I started to think it through. There are two quick remarks.
In
module M
{
class C { ... }
class D
{
# lexical region where C refers to M::C
method m1 () { my C $x; my Int $y; ... }
class C { ... }
# lexical region where C refers to D::C
method m2 () { my C $x; ... }
}
}
I would make the use of C in m1 of D an error because otherwise
the scope D is split into two at the point where D::C is defined.
In other words D::C is not the innermost definition everywhere in
D. This is a serious source of subtle errors. If this is what you
want than write M::C in m1. Scopes should be one-dimensional along
the lines of inner versus outer. An additional dimension before
versus after should be used only for error checking. That is in m1
C is parsed provisionally as M::C and this fails when D::C is seen
later.
Second, I don't like the concept of a virtual method that returns
a type. That horribly mixes type level and value level. From the
namespace POV we have M::D::foo and P::E::foo bound to the same
implementation. In both cases C is OUTER::C. The "magic" should
happen when an invocation of foo is created. That is the moment when
the scope of OUTER::C can be bound by 'my C $b' through $x and $y
respectively.
Regards, TSa.
--
"The unavoidable price of reliability is simplicity"
-- C.A.R. Hoare
Re: method hiding (or not) in derived classes
HaloO, John M. Dlugosz wrote: TSa Thomas.Sandlass-at-barco.com |Perl 6| wrote: "Candidate set" would be a better term. It is a subset of all long names of a multi in a lexical scope. List, not set, because it is ordered. nextsame/nextwith/etc. are described as invoking the next candidate on the list. Therefore, there is a list. Hmm, the term candidate should be after the applicability check and before specificity check. The latter results in a partially ordered list of targets. If there's more than one most specific target, we have an ambiguity error. As a consequence there might not be a unique next method on the target list and a nextsame might fail. I agree that the synopsis conflate these details into the term "candidate list". But I hope you are more rigorous. What about ordinary methods (and ordinary parameters of multis)? Does the candidate list hold every method name that matches, or does it do simpler parameter matching based on number of arguments, required named arguments, etc.? There is hopefully a complete specification what constitutes applicability. There can hardly be differing simpler versions. In other words there is only one subtype relation that is used whenever a binding takes place. I have no idea what you said. OK, here's my vision of dispatch. First there's a syntactic distinction between MMD and class dispatch. $obj.meth(|$args); meth $obj: |$args; These pull out the candidate set from $obj. Everything else collects the candidate set from a namespace scan. Next, all candidates are checked to allow a binding of $obj and |$args. The ones that fail are dropped. If the candidate set is now empty we have a failure. The remaining set is now sorted into a list of sets by applying the subtype relation in the dispatch relevant parameter positions. If the first element of that list is a set with a single element we have a successful dispatch. Otherwise there's an ambiguity error. The .? avoids the no target error, .+ avoids the ambiguity error and .* never fails. I would leave the order in which sets of targets are called unspecified. If one needs more control the .WALK method can be used. If class dispatch fails because there's no applicable method then a MMD is attempted. I guess the answer to your question concerning hiding a method in a derived class depends on the set of candidates the $obj.HOW comes up with in the first step. If it delivers superclass methods and subclass methods fail the applicability test then the dispatch goes to a superclass method that can handle the dispatch. Would you favor a type error then? If that is the case, then a derived method might not hide a base class method if the parameter list is seriously incompatible. That is a natural and welcome consequence of type based dispatch. Classes are for implementation sharing, not for transitive typing. I'm talking about non-multi's here. Me too. As stated above the candidate set is up to the class that created the object. If this class can prevent the failover to MMD I don't know. Regards, TSa. -- "The unavoidable price of reliability is simplicity" -- C.A.R. Hoare
Re: progress report
On Apr 20, 8:38 pm, [EMAIL PROTECTED] wrote: > "John M. Dlugosz" and I have both replied to "whiteringmoon"'s query, so I > don't think anyone else need to. (If he's genuine, we don't want to > bombard him with multiple replies, and if not, let's not give out too much > spambait.) > > -- > > Email and shopping with the feelgood factor! > 55% of income to good causes.http://www.ippimail.com I honestly had not considered computer languages in my perameters of study. But because it is a common language used by a large number of people, and it's intent of meaning is constant it may be a perfect language. From what I understand about computer languages is this that they are based on a binary language consisting of zero and one and with thoes two numbers all the language that exists, the instructions that the computer will follow so that it can communicate with every other computer. Again thank you both for answering my questions. I'm going to read the information and add it the list of languages. WR
Re: method hiding (or not) in derived classes
On Sat, Apr 19, 2008 at 08:00:07AM -, John M. Dlugosz wrote: : Perl 6 has a concept of a "candidate list". The candidate list are those that could handle the call, typically inherited methods and multi variations. : : It seems that multi variations, at least with respect to the semicolon parameters, compare the actual type and drop out of the list if any don't match. When you drop those candidates that "can never match" is mostly a matter of optimization, I suspect. : What about ordinary methods (and ordinary parameters of multis)? Does the candidate list hold every method name that matches, or does it do simpler parameter matching based on number of arguments, required named arguments, etc.? For those parameters, it matters only whether they can be bound when the candidate is called. The parameters need not be considered at all when generating the candidate list (but see "optimization" above--though perhaps this view is oversimplified if we have to do tie determination, since ties are supposed to fail before the final call, and we'd have to weed out non-bindable sigs before declaring a tie). : If that is the case, then a derived method might not hide a base class method if the parameter list is seriously incompatible. More interestingly, left-to-right ordering of multiply-inherited base classes will be checked for applicability rather than arbitrarily taking the leftmost. "only" methods use only short name, and methods, like subs, default to "only". And as it is currently specced, the class is dispatched on the short name before any any of its multis, and long names are not considered until the class is dispatched to. The invariant is that single dispatch is always under the control of the invocant's object system, while multiple dispatch never is. In my mind the policy distinction is clarified by considered what happens if a foreign language defines some of the classes. Under single dispatch the language that defined the object gets the dispatch. Under multiple dispatch, all objects are treated as Perl objects with Perl types, and the type system gets to decide which candidate to call. It is important to be able to look at a call and determine which kind of call is being made; this is why we give single dispatch a syntax that is distinct from multiple dispatch. So if you use "multi method" declarations within a class, they appear only to be a single method from outside the class, because that is all the foreign language interface can support. You can only use multi methods within a class if the language supports the concept, and Perl 6 only supports it out the scope of the current class. Basically, multi methods are just treated as multi subs inside a class, except the invocant is predecided and doesn't make any difference to the dispatch within the class. Larry
Re: Context and return types question
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: method hiding (or not) in derived classes
TSa Thomas.Sandlass-at-barco.com |Perl 6| wrote: "Candidate set" would be a better term. It is a subset of all long names of a multi in a lexical scope. List, not set, because it is ordered. nextsame/nextwith/etc. are described as invoking the next candidate on the list. Therefore, there is a list. What about ordinary methods (and ordinary parameters of multis)? Does the candidate list hold every method name that matches, or does it do simpler parameter matching based on number of arguments, required named arguments, etc.? There is hopefully a complete specification what constitutes applicability. There can hardly be differing simpler versions. In other words there is only one subtype relation that is used whenever a binding takes place. I have no idea what you said. If that is the case, then a derived method might not hide a base class method if the parameter list is seriously incompatible. That is a natural and welcome consequence of type based dispatch. Classes are for implementation sharing, not for transitive typing. I'm talking about non-multi's here. More interestingly, left-to-right ordering of multiply-inherited base classes will be checked for applicability rather than arbitrarily taking the leftmost. Indeed, I would hope that order of inheritance doesn't matter. Sounds more role-like, now that you mention it. Regards, TSa.
Re: Context and return types question
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: use of ::?CLASS
TSa Thomas.Sandlass-at-barco.com |Perl 6| wrote: You are right and I didn't address this, sorry. Actually the only solution I see is dropping the ::? twigil altogether and specify that CLASS is lexically declared by the compiler. Otherwise we have to make a special case exception out of ::? variables. All twigiled variables. No longer special case: it only applies to non-qualified names with no twigil. But doit is not a type. I think you were talking something like that earlier and I didn't follow. It is an arrow type, like foo: Int --> Int and bar: Int --> Int. These are structurally identical. The fun thing is that the Perl 6 type system is supposed to be nominal. Thus foo and bar are different types. But contradictory to that you can use foo and bar wherever an Int --> Int is expected. I love this self contradiction of Perl ;) Well, and you can't neither use foo nor bar to denote the arrow type. doit =has= a signature. Yes, I expect functions will be typechecked when you try and assign one to a variable that declares a function type. But the function is a value of that type, just like 5 is a value of type Int, not itself a type. --John
Re: Are coroutines still there?
HaloO, Mark J. Reed wrote: ? Multiple-assignment second-class? I don't see how you get that out of Larry's message... Well, he explicitly says that loop is second-class because it uses multi-assignment. Actually he says it "tends to violate single-assignment". But I interpret that sort of intensionally as being worse than an outright violation. That is already the tendency of violation means second-class ;) Regards, TSa. -- "The unavoidable price of reliability is simplicity" -- C.A.R. Hoare
Re: Are coroutines still there?
? Multiple-assignment second-class? I don't see how you get that out of Larry's message... On 4/21/08, TSa <[EMAIL PROTECTED]> wrote: > HaloO, > > Larry Wall wrote: > > That is, coro and loop tend to violate single-assignment semantics, and > > single-assignment semantics are easier to map into functional semantics. > > > > So if we do allow coro in Perl 6, it'll probably be a second-class > > citizen like loop and goto and die (and anything else considered > > harmful but useful). But I don't see much use for it offhand. > > Does that imply that multiple assignment is second-class, too? > And that with a language that provides the concept of eternal > equality with ===, or checking of referential identity with =:=. > Big surprise that is. > > > Regards, TSa. > -- > > "The unavoidable price of reliability is simplicity" >-- C.A.R. Hoare > -- Sent from Gmail for mobile | mobile.google.com Mark J. Reed <[EMAIL PROTECTED]>
Re: method hiding (or not) in derived classes
HaloO, John M. Dlugosz wrote: Perl 6 has a concept of a "candidate list". The candidate list are those that could handle the call, typically inherited methods and multi variations. "Candidate set" would be a better term. It is a subset of all long names of a multi in a lexical scope. It seems that multi variations, at least with respect to the semicolon parameters, compare the actual type and drop out of the list if any don't match. I'm not sure what you are asking. But if a candidate is applicable it competes with the other candidates for specificity. That is what the semicolons are for. And even if a candidate is voted out it still can vote out others. What about ordinary methods (and ordinary parameters of multis)? Does the candidate list hold every method name that matches, or does it do simpler parameter matching based on number of arguments, required named arguments, etc.? There is hopefully a complete specification what constitutes applicability. There can hardly be differing simpler versions. In other words there is only one subtype relation that is used whenever a binding takes place. If that is the case, then a derived method might not hide a base class method if the parameter list is seriously incompatible. That is a natural and welcome consequence of type based dispatch. Classes are for implementation sharing, not for transitive typing. More interestingly, left-to-right ordering of multiply-inherited base classes will be checked for applicability rather than arbitrarily taking the leftmost. Indeed, I would hope that order of inheritance doesn't matter. Regards, TSa. -- "The unavoidable price of reliability is simplicity" -- C.A.R. Hoare
Re: Are coroutines still there?
HaloO, Larry Wall wrote: That is, coro and loop tend to violate single-assignment semantics, and single-assignment semantics are easier to map into functional semantics. So if we do allow coro in Perl 6, it'll probably be a second-class citizen like loop and goto and die (and anything else considered harmful but useful). But I don't see much use for it offhand. Does that imply that multiple assignment is second-class, too? And that with a language that provides the concept of eternal equality with ===, or checking of referential identity with =:=. Big surprise that is. Regards, TSa. -- "The unavoidable price of reliability is simplicity" -- C.A.R. Hoare
Re: progress report
"John M. Dlugosz" and I have both replied to "whiteringmoon"'s query, so I don't think anyone else need to. (If he's genuine, we don't want to bombard him with multiple replies, and if not, let's not give out too much spambait.) -- Email and shopping with the feelgood factor! 55% of income to good causes. http://www.ippimail.com
Re: Context and return types question
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
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
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: use of ::?CLASS
HaloO, John M. Dlugosz wrote: I do see that the use in a role is like a generic. But you would use the sigil every time, e.g. method doit (::?CLASS $self: ::?CLASS $other --> ::?CLASS) that is not three separate generics with conflicting names, but the same thing. With generics you can only use the sigil on the first use. You are right and I didn't address this, sorry. Actually the only solution I see is dropping the ::? twigil altogether and specify that CLASS is lexically declared by the compiler. Otherwise we have to make a special case exception out of ::? variables. That is all methods in a role are parametric on ::?CLASS just as all methods in a class are parametric on ::?SELF class B is A; instanciates a new type &doit:(B $self: $a, $b, $c). This nicely But doit is not a type. I think you were talking something like that earlier and I didn't follow. It is an arrow type, like foo: Int --> Int and bar: Int --> Int. These are structurally identical. The fun thing is that the Perl 6 type system is supposed to be nominal. Thus foo and bar are different types. But contradictory to that you can use foo and bar wherever an Int --> Int is expected. I love this self contradiction of Perl ;) Well, and you can't neither use foo nor bar to denote the arrow type. Note that I consider myself a knowledgeable bystander with the knowledgeable being debatable ;) Regards, TSa. -- "The unavoidable price of reliability is simplicity" -- C.A.R. Hoare
