Re: class interface of roles
HaloO, Jonathan Lang wrote: What do you mean by uncomposed class? The self always refers to the object as instance of the composed class. Methods are therefore resolving to the outcome of the composition process. But super in a role refers to methods from the class definition even when the final method comes from method combination in the composition process. I think the word super is already to overloaded to be used for this purpose. Setting that aside for now... Better ideas? Is there a super keyword already? Or do you mean overloaded in general OO and type speak? Do you mean that super.blah() appearing in a method defined in a role A should require that all classes which do A need to provide a blah implementation? (or produce a composition time error if they don't) Yes, this is exactly what I mean with superclass interface of roles. I hope not; that's exactly what declaring an unimplemented method in a role is supposed to do. My idea is that the type system calculates a type bound for the class from the definition of the role. That includes attributes and their accessor methods. It's a matter of taste how explicit this interface is declared or how much of it is infered. (And declaring an implemented method does the same thing, with the addition that it also suggests an implementation that the class is free to use or ignore as it sees fit.) We have a priority conflict here. The question is if the class or the role is seeing the other's methods for method combination. A Role should be able to say to do this Role you need to implement these methods and have a compile/composition time error if not. Agreed. I agree as well. But on a wider scope then just method provision. (There does need to be a way to call, in a Role A, both the blah defined in A and whatever the blah the final class may use. Yes, this is the subject of the current debate. I'm opting for a method combination semantics that allows the role to call the class method. $self.blah() is the later, $self.A::blah() or similar is likely to be the former.) No, there doesn't. Given that Cclass Foo does A and Crole A does B, There needs to be a way to call, in class Foo, both the blah defined in Foo, the blah defined in A (so that Foo can reimplement A's version as a different method or as part of its own), and the blah defined in B; From the class all composed parts are available through namespace qualified names. But a role is a classless and instanceless entity. The self refers to the objects created from the composed class. The role is not relevant in method dispatch. That is a method is never dispatched to a role. But the role should be able to participate in the method definition of the composed class. and there needs to be a way to call, in role A, both the blah defined in Foo and the blah defined B; but role A does not need a way to explicitly call a method defined in A. I'm not sure if I get this right. But as I said above a role can not be dispatched to. Which method do you think should take precedence the role's or the class's? That is who is the defining entity in the method combination process? I would hope it is the role if a as of now unknown syntax has declared it. Perhaps it should be even the default. The rational for my claim is that a role is composed several times and then every class doing the role automatically gets the correct version. Otherwise all classes are burdened with caring for the role's part in the method. It should assume that if Foo overrides A's implementation of blah, Foo knows what it's doing; by the principle of least surprise, Foo should never end up overriding A's implementation of blah only to find that the original implementation is still being used by another of the methods acquired from A. Could you make an example because I don't understand what you mean with original implementation and how that would be used by role methods. Method dispatch is on the class never on the role. As far as dispatch is concerned the role is flattend out. But the question is how the class's method is composed in the first place. Regards, --
Re: class interface of roles
HaloO,
Jonathan Lang wrote:
So if I'm reading this right, a class that does both A and B should be
lower in the partial ordering than a class that does just one or the
other. And if A does B, then you'll never have a class that does just
A without also doing B, which trims out a few possible nodes and paths
from the lattice for practical purposes:
Any={}
| \
| \
|\
| \
| \
B={y} C={z}
/ \ |
/ \ |
/ \|
/ \ |
/ \ |
/ \ |
A|B={x,y} B|C={y,z}
\ /
\ /
\ /
\ /
\ /
A|B|C={x,y,z}
Correct. The lattice is a structural analysis of the roles.
I note that while the lattice is related to whatever role hierarchies
may or may not exist, it is not the same as them. In particular,
roles that have no hierarchal relationship to each other _will_ exist
in the same lattice. In fact, all roles will exist in the same
lattice, on the first row under Any. Right?
Yes, if they are disjoined structurally. Otherwise intersection roles
appear as nodes under Any.
Or does the fact that
A does B mean that A would be placed where A|B is, and A|C would
end up in the same node as A|B|C?
To get at the node labeled A|B above you either need a definition
role A does B { has $.x }
or an outright full definition
role A { has $.x; has $.y }
So, yes the node should be called A and A|C coincides with A|B|C.
I'm not sure if this ordering of roles can be called duck typing
because it would put roles that have the same content into the
same lattice node. The well known bark method of Dog and Tree
comes to mind. But the arrow types of the methods will be different.
One has type :(Dog -- Dog) the other :(Tree -- Tree) and a joined
node will have type :(DogTree -- Dog|Tree). This might just give
enough information to resolve the issues surrounding the DogTree
class.
By most specific, you'd mean closest to the top?
No, closer to the bottom. The join operator | of the lattice produces
subtypes with a larger interface that is more specific. It's like
the more derived class in a class hierarchy.
Regards, TSa.
--
Runtime role issues
Hi all, I posted this to Perl6 users, but I was Warnocked, it was the wrong list, or both. Here's another stab at it. In doing a bit of work with traits (roles) in Perl 5 (http://perlmonks.org/?node_id=577477), I've realized some edge cases which could be problematic. First, when a role is applied to a class at runtime, a instance of that class in another scope may specifically *not* want that role. Is there a way of restricting a role to a particular lexical scope short of applying that role to instances instead of classes? Second, how can I remove roles from classes? I've create some code which adds an is_selected method to some classes but when I'm done, I'd like top easily remove that role. How do I do that? Seems closely related to my first question, but it's still a distinct issue, I think. Third, http://dev.perl.org/perl6/doc/design/syn/S12.html says: You can also mixin a precomposed set of roles: $fido does Sentry | Tricks | TailChasing | Scratch; Should that be the following? $fido does Sentry Tricks TailChasing Scratch; Cheers, Ovid -- Buy the book -- http://www.oreilly.com/catalog/perlhks/ Perl and CGI -- http://users.easystreet.com/ovid/cgi_course/
Re: Runtime role issues
HaloO, Ovid wrote: Third, http://dev.perl.org/perl6/doc/design/syn/S12.html says: You can also mixin a precomposed set of roles: $fido does Sentry | Tricks | TailChasing | Scratch; Should that be the following? $fido does Sentry Tricks TailChasing Scratch; If you follow my idea of a type lattice build from roles with | as join and as meet operator these two mean something completely different. The first is the join or union of the roles while the second is their meet or intersection. The first creates a subtype of the roles the second a supertype. But the typishness of roles is debated. Regards, TSa. --
Re: Runtime role issues
HaloO, Ovid wrote: First, when a role is applied to a class at runtime, a instance of that class in another scope may specifically *not* want that role. Is there a way of restricting a role to a particular lexical scope short of applying that role to instances instead of classes? I think you'll need an intermediate class that you use to apply your role. Classes are open and that implies the possibility to merge further roles into them. But this applies for all users of the class. How this works when there are already instances I don't know. Second, how can I remove roles from classes? Is that a wise thing to do? Roles are not assigned and removed as a regular operation. What is your use case? Regards, TSa. --
[perl #40511] [PATCH] Removal of deprecated fetchmethod opcode
# New Ticket Created by Paul Cochrane # Please include the string: [perl #40511] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org/rt3/Ticket/Display.html?id=40511 Hi, This patch removes the deprecated fetchmethod opcode from various ops files, and most of the documentation concerning the opcode. I've specifically not removed the corresponding paragraph in DEPRECATED.pod since I've already put in a patch affecting that file; I can patch it later if desired. I've also not patched PBC_COMPAT noting the pbc compatibility change as I think someone should review the patch first to make sure I've not stuffed something up (and a committer username is required in the file anyway). Hope this helps! Regards, Paul files affected: src/ops/ops.num src/ops/object.ops docs/pdds/clip/pdd15_objects.pod editor/pir-mode.el Index: src/ops/ops.num === --- src/ops/ops.num (revision 14877) +++ src/ops/ops.num (working copy) @@ -646,598 +646,596 @@ tailcallmethod_p_s 616 tailcallmethod_p_sc 617 tailcallmethod_p_p 618 -DELETED_fetchmethod_p_p_s 619 -DELETED_fetchmethod_p_p_sc 620 -addmethod_p_s_p 621 -addmethod_p_sc_p622 -can_i_p_s 623 -can_i_p_sc 624 -does_i_p_s 625 -does_i_p_sc 626 -isa_i_p_s 627 -isa_i_p_sc 628 -isa_i_p_p 629 -isa_i_p_pc 630 -newclass_p_s631 -newclass_p_sc 632 -newclass_p_p633 -newclass_p_pc 634 -subclass_p_p635 -subclass_p_p_s 636 -subclass_p_p_sc 637 -subclass_p_p_p 638 -subclass_p_p_pc 639 -subclass_p_pc 640 -subclass_p_s641 -subclass_p_sc 642 -subclass_p_pc_s 643 -subclass_p_pc_sc644 -subclass_p_s_s 645 -subclass_p_sc_s 646 -subclass_p_s_sc 647 -subclass_p_sc_sc648 -subclass_p_pc_p 649 -subclass_p_pc_pc650 -subclass_p_s_p 651 -subclass_p_sc_p 652 -subclass_p_s_pc 653 -subclass_p_sc_pc654 -getclass_p_s655 -getclass_p_sc 656 -getclass_p_p657 -getclass_p_pc 658 -singleton_p 659 -class_p_p 660 -classname_s_p 661 -addparent_p_p 662 -removeparent_p_p663 -addattribute_p_s664 -addattribute_p_sc 665 -removeattribute_p_s 666 -removeattribute_p_sc667 -removeattribute_p_i 668 -removeattribute_p_ic669 -getattribute_p_p_i 670 -getattribute_p_p_ic 671 -getattribute_p_p_s 672 -getattribute_p_p_sc 673 -setattribute_p_i_p 674 -setattribute_p_ic_p 675 -setattribute_p_s_p 676 -setattribute_p_sc_p 677 -classoffset_i_p_s 678 -classoffset_i_p_sc 679 -pic_infix___ic_p_p 680 -pic_inline_sub___ic_p_p 681 -pic_get_params___pc 682 -pic_set_returns___pc683 -pic_callr___pc 684 -new_p_i 685 -new_p_ic686 -new_p_i_p 687 -new_p_ic_p 688 -new_p_i_pc 689 -new_p_ic_pc 690 -new_p_sc691 -new_p_sc_p 692 -new_p_sc_pc 693 -new_p_pc694 -new_p_pc_p 695 -new_p_pc_pc 696 -typeof_s_p 697 -typeof_i_p 698 -typeof_i_p_k699 -typeof_i_p_kc 700 -typeof_i_p_ki 701 -typeof_i_p_kic 702 -typeof_s_i 703 -typeof_s_ic 704 -find_type_i_s 705 -find_type_i_sc 706 -find_type_i_p 707 -find_type_i_pc 708 -valid_type_i_i 709 -valid_type_i_ic 710 -get_repr_s_p711 -find_method_p_p_s 712 -find_method_p_p_sc 713 -defined_i_p 714 -defined_i_p_ki 715 -defined_i_p_kic 716 -defined_i_p_k 717 -defined_i_p_kc 718 -exists_i_p_ki 719 -exists_i_p_kic 720 -exists_i_p_k721
[perl #40503] [PATCH] Removal of .imc filename change paragraph
# New Ticket Created by Paul Cochrane # Please include the string: [perl #40503] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org/rt3/Ticket/Display.html?id=40503 Hi, This patch removes the paragraph in DEPRECATED.pod mentioning that the .imc file extension is deprecated since there are no longer any .imc files in Parrot (having all been turned into .pir). I *think* this is the right thing to do, but I'm not 100% sure, and I hope I'm not overstepping any bounds or anything. Regards, Paul Index: DEPRECATED.pod === --- DEPRECATED.pod (revision 14877) +++ DEPRECATED.pod (working copy) @@ -10,17 +10,6 @@ =back -=head1 .imc file extension - -http://xrl.us/jc4u - - IMC vs. PIR - Two names enter - One name leaves - - /me giggles - -- Chip Salzenberg - =head1 Deprecated APIs =over 4
Fwd: [perl #40508] [PATCH] Removal of C++ comments in pmc files
What's a C++ comment? If you mean //...\n comments, those are legal in ANSI-99 C (and the syntax goes back to BCPL). If the coding standard specifies multiline-style comments only, fine, but please don't use misleading terminology. -- Forwarded message -- From: via RT Paul Cochrane [EMAIL PROTECTED] Date: Wed, 11 Oct 2006 01:32:55 -0700 Subject: [perl #40508] [PATCH] Removal of C++ comments in pmc files To: [EMAIL PROTECTED] # New Ticket Created by Paul Cochrane # Please include the string: [perl #40508] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org/rt3/Ticket/Display.html?id=40508 Hi, This patch changes C++ comments found in pmc files to C comments. Regards, Paul files affected: languages/APL/src/pmc/aplvector.pmc languages/pugs/pmc/pugscapture.pmc -- Mark J. Reed [EMAIL PROTECTED] Index: languages/APL/src/pmc/aplvector.pmc === --- languages/APL/src/pmc/aplvector.pmc (revision 14877) +++ languages/APL/src/pmc/aplvector.pmc (working copy) @@ -124,11 +124,15 @@ * we use our own type here. Perhaps a better way to * specify it? */ -//array_t = pmc_type(INTERP, -//string_from_const_cstring(INTERP, APLVector, 0) -//); +/* +array_t = pmc_type(INTERP, +string_from_const_cstring(INTERP, APLVector, 0) +); +*/ shape = pmc_new(INTERP,VTABLE_type(INTERP,SELF)); -//#array_t); +/* +#array_t); +*/ VTABLE_set_integer_native(INTERP, shape, 1); VTABLE_set_integer_keyed_int(INTERP,shape,0, VTABLE_get_integer(INTERP, SELF) Index: languages/pugs/pmc/pugscapture.pmc === --- languages/pugs/pmc/pugscapture.pmc (revision 14877) +++ languages/pugs/pmc/pugscapture.pmc (working copy) @@ -35,7 +35,9 @@ } siva; static PMC* intret; -// STRING * parrot_hash_get_idx(Interp *interpreter, Hash *hash, PMC * key); +/* +STRING * parrot_hash_get_idx(Interp *interpreter, Hash *hash, PMC * key); +*/ static PMC* undef_pmc; /*
Re: Fwd: [perl #40508] [PATCH] Removal of C++ comments in pmc files
[EMAIL PROTECTED] wrote: What's a C++ comment? If you mean //...\n comments, those are legal in ANSI-99 C Parrot is using ANSI-98 C, I believe. And //\N+\n comments are not legal in that. Jonathan
Re: [perl #40503] [PATCH] Removal of .imc filename change paragraph
On 10/11/06, via RT Paul Cochrane [EMAIL PROTECTED] wrote: # URL: http://rt.perl.org/rt3/Ticket/Display.html?id=40503 This patch removes the paragraph in DEPRECATED.pod mentioning that the .imc file extension is deprecated since there are no longer any .imc files in Parrot (having all been turned into .pir). I *think* this is the right thing to do, but I'm not 100% sure, and I hope I'm not overstepping any bounds or anything. i'm not 100% sure this is the right thing to do, either. the most recent version of perl 6 and parrot essentials still makes reference to '.imc' files. with this paragraph in deprecated.pod, there's something to grep for that might help readers make the transition to '.pir'. ~jerry
Re: [perl #40503] [PATCH] Removal of .imc filename change paragraph
i'm not 100% sure this is the right thing to do, either. the most recent version of perl 6 and parrot essentials still makes reference to '.imc' files. with this paragraph in deprecated.pod, there's something to grep for that might help readers make the transition to '.pir'. True. Thought it wouldn't hurt to ask. I won't be offended if the patch is rejected. :-) Paul
Re: Fwd: [perl #40508] [PATCH] Removal of C++ comments in pmc files
On 10/11/06, Jonathan Worthington [EMAIL PROTECTED] wrote: [EMAIL PROTECTED] wrote: What's a C++ comment? If you mean //...\n comments, those are legal in ANSI-99 C Parrot is using ANSI-98 C, I believe. And //\N+\n comments are not legal in that. jonathan ment C89 of course. some compilers on major platforms do not conform to C99, so until they do (or until chip decides to change the coding standards) that's the standard we're using. ~jerry
Re: [perl #40503] [PATCH] Removal of .imc filename change paragraph
On 10/11/06, Paul Cochrane [EMAIL PROTECTED] wrote: i'm not 100% sure this is the right thing to do, either. the most recent version of perl 6 and parrot essentials still makes reference to '.imc' files. with this paragraph in deprecated.pod, there's something to grep for that might help readers make the transition to '.pir'. True. Thought it wouldn't hurt to ask. I won't be offended if the patch is rejected. :-) i've assigned the ticket to chip. i'm sure he'll make a decision and take action. ~jerry
P5's s[pat][repl] syntax is dead
@larry[0] wrote:
Log:
P5's s[pat][repl] syntax is dead, now use s[pat] = repl
Wow, I really missed this one! That's a pretty big thing to get my head
around. Are embedded closures in the string handled correctly so that:
s:g[\W] = qq{\\{$/}};
Will do what I seem to be expecting it will?
How will that be defined in the Perl6-based parser? Will macros be able
to act as an LVALUE and modify their RVALUE in this way, or is this just
some unholy magic in the parser?
+ s[pattern] = doit()
+ s[pattern] = eval doit()
[...]
+There is no syntactic sugar here, so in order to get deferred
+evaluation of the replacement you must put it into a closure. The
+syntactic sugar is provided only by the quotelike forms.
[...]
+This is not a normal assigment, since the right side is evaluated each
+time the substitution matches (much like the pseudo-assignment to declarators
+can happen at strange times). It is therefore treated as a thunk, that is,
+as if it has implicit curlies around it. In fact, it makes no sense at
+all to say
+
+s[pattern] = { doit }
Please clarify quotelike forms, since to my untrained eye, the above
appeared to be contradictory at first (I read quotelike forms as s///
not s{...}).
Very interesting.
Re: Runtime role issues
First, when a role is applied to a class at runtime, a instance of that class in another scope may specifically *not* want that role. Is there a way of restricting a role to a particular lexical scope short of applying that role to instances instead of classes? Seems like you could use an empty intermediate role to accomplish the same thing while leaving the shared class alone. Shared Class A Mixin Role B Class C isa A does B Class D isa A Shared Class A is unmodified. Otherwise, I think that any runtime modification of a class should affect all instances and future instances of that class. On closer inspection, is it even possible to add a Role to a Class at runtime? I thought that Class and Role composition outside of compile time resulted in a new pseudo Class for the subsequent instances of that composition - in which case the original Class would remain unmodified. Paul
Re: P5's s[pat][repl] syntax is dead
On Wed, Oct 11, 2006 at 10:32:13AM -0400, Aaron Sherman wrote:
: @larry[0] wrote:
:
: Log:
: P5's s[pat][repl] syntax is dead, now use s[pat] = repl
:
: Wow, I really missed this one! That's a pretty big thing to get my head
: around. Are embedded closures in the string handled correctly so that:
:
: s:g[\W] = qq{\\{$/}};
:
: Will do what I seem to be expecting it will?
Yes, the right side is implicitly closurized and evaluated repeatedly
by the left side.
: How will that be defined in the Perl6-based parser? Will macros be able
: to act as an LVALUE and modify their RVALUE in this way, or is this just
: some unholy magic in the parser?
This is just a macro with a fancy is parsed rule, I think. It eats the =
in complete disregard for precedence. Nothing much to generalize, I think.
: + s[pattern] = doit()
: + s[pattern] = eval doit()
: [...]
: +There is no syntactic sugar here, so in order to get deferred
: +evaluation of the replacement you must put it into a closure. The
: +syntactic sugar is provided only by the quotelike forms.
: [...]
: +This is not a normal assigment, since the right side is evaluated each
: +time the substitution matches (much like the pseudo-assignment to
: declarators
: +can happen at strange times). It is therefore treated as a thunk, that
: is,
: +as if it has implicit curlies around it. In fact, it makes no sense at
: +all to say
: +
: +s[pattern] = { doit }
:
: Please clarify quotelike forms, since to my untrained eye, the above
: appeared to be contradictory at first (I read quotelike forms as s///
: not s{...}).
s{...} is also a quotelike form. Basically I mean anything where
you get to choose your own quote characters, whether or not they are
brackets.
: Very interesting.
Yeah, we whacked on possible syntaxes a goodly long time on IRC the
other night. Trying to balance out history and visuals and semantics
and failure modes was all quite interesting, but in the absence of
more Unicode keys on the keyboard I'm liking this notation pretty
well, particularly since we've already used pseudo assignment in
other places to thunkize the right side.
Larry
Re: [perl #40483] [PATCH] removal of cuddled else's in C source
Jerry, 1) the patch leaves trailing spaces after the closing brackets (this isn't a coding standard (yet) but is a pet peeve of mine. if it were this alone, i'd modify the patch myself and apply. I can add a test for this to t/codingstd/cuddled_else.t if you want. 2) many of the source files you modified didn't show up in the output from the test. compare the list of files you modified to the list of failed files (here's my run from r14895): snip can you repeat this result? Yes, I got exacly the same output from r14895. Actually, this patch was already applied by Bernhard in r14870, which explains why the effected files list looks different. The cuddled else patch I most recently sent in ([perl #40507]) applied only to pmc files and is (indirectly) a result of the patch of t/codingstd/cuddled_else.t in r14985. Regards, Paul
[perl #40507] [PATCH] Removal of cuddled else in pmc files
thanks, applied as r14897. ~jerry
signature subtyping and role merging
HaloO,
with my idea of deriving a type lattice from all role definitions
the problem of subtyping signatures arises. Please help me to think
this through. Consider
role Foo
{
sub blahh(Int, Int) {...}
}
role Bar
{
sub blahh(Str) {...}
}
role Baz does Foo does Bar # Foo|Bar lub
{
# sub blahh(IntStr,Int?) {...}
}
The role Baz has to be the lub (least upper bound) of Foo and Bar.
That is the join of two nodes in the lattice. This means first of
all the sub blahh has to be present. And its signature has to be
in a subtype relation : to :(Int,Int) and :(Str). Note that
Int : IntStr and Int|Str : Int. The normal contravariant subtyping
rules for functions gives
+- : ---+
||
:(IntStr,Int?) : :(Int,Int)
| |
+--- : ---+
and
+- : ---+
||
:(IntStr,Int?) : :(Str)
I hope you see the contravariance :)
The question mark shall indicate an optional parameter that
allows the subtype to be applicable in both call sites that
have one or two arguments.
The choice of glb for the first parameter makes the sub in Baz
require the implementor to use the supertype of Int and Str
which in turn allows the substitution of Int and Str arguments
which are subtypes---that is types with a larger interface.
Going the other way in the type lattice the meet FooBar of the
two roles Foo and Bar is needed. But here the trick with the
optional parameter doesn't work and it is impossible to reconcile
the two signatures. This could simply mean to drop sub blahh from
the interface. But is there a better way? Perhaps introducing a
multi?
Apart from the arity problem the lub Int|Str works for the first
parameter:
+- : ---+
||
:(Int|Str,Int) : :(Int,Int)
| |
+--- : ---+
+ : ---+
| |
:(Int|Str) : :(Str)
Regards, TSa.
--
[perl #40513] [CAGE] add flex/bison files to c coding standard tests
# New Ticket Created by Jerry Gay # Please include the string: [perl #40513] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org/rt3/Ticket/Display.html?id=40513 *.l and *.y are c files, and must meet the coding standards for this filetype. ~jerry
Re: class interface of roles
TSa wrote: Jonathan Lang wrote: What do you mean by uncomposed class? The self always refers to the object as instance of the composed class. Methods are therefore resolving to the outcome of the composition process. But super in a role refers to methods from the class definition even when the final method comes from method combination in the composition process. Still not following. Can you give an example? I hope not; that's exactly what declaring an unimplemented method in a role is supposed to do. My idea is that the type system calculates a type bound for the class from the definition of the role. That includes attributes and their accessor methods. It's a matter of taste how explicit this interface is declared or how much of it is inferred. Note that it's entirely possible for attributes to not make it into the final class, if the accessor methods get redefined in such a way as to remove reference to the attributes. This is part of the notion that roles supply an outline of what the class should do, but only the class actually supplies the definitive details of how to do it. As I see it: is and does declarations in a role impose requirements on the final class: it must derive from another class (is), or it must compose another role (does). method and has are each one part requirement and one part suggestion: for method, the class is required to include a method that matches the given name (which, of course, includes the method's signature), and a particular closure is suggested that the class can accept or override. For has, the class is required to provide accessor methods corresponding to the attribute's read/write capabilities (a rw method if it's a rw attribute; a regular method if it's a regular attribute; and no method if it's a private attribute); like any other method, a closure is suggested that the class may accept or override. In addition, the role suggests that a given attribute be added to the class' state information. This suggestion is implicitly accepted if any of the methods that are used by the final class refer to the attribute; it is implicitly rejected if none of them do. The same rule applies to private methods. Thus, the only things that I'd recommend using to calculate a type-boundary would be the superclasses (provided by is) and the method names (provided by method and has). (And declaring an implemented method does the same thing, with the addition that it also suggests an implementation that the class is free to use or ignore as it sees fit.) We have a priority conflict here. The question is if the class or the role is seeing the other's methods for method combination. I believe that I address this later on; if not, please clarify. (There does need to be a way to call, in a Role A, both the blah defined in A and whatever the blah the final class may use. Yes, this is the subject of the current debate. I'm opting for a method combination semantics that allows the role to call the class method. Agreed. $self.blah() is the later, $self.A::blah() or similar is likely to be the former.) No, there doesn't. Given that Cclass Foo does A and Crole A does B, There needs to be a way to call, in class Foo, both the blah defined in Foo, the blah defined in A (so that Foo can reimplement A's version as a different method or as part of its own), and the blah defined in B; From the class all composed parts are available through namespace qualified names. But a role is a classless and instanceless entity. The self refers to the objects created from the composed class. The role is not relevant in method dispatch. That is a method is never dispatched to a role. But the role should be able to participate in the method definition of the composed class. Also agreed. In particular, I'm referring to _how_ a role should participate in the method definition of the composed class; I am not referring to method dispatch, which is limited to the class hierarchy. and there needs to be a way to call, in role A, both the blah defined in Foo and the blah defined B; but role A does not need a way to explicitly call a method defined in A. I'm not sure if I get this right. But as I said above a role can not be dispatched to. Which method do you think should take precedence the role's or the class's? That is who is the defining entity in the method combination process? I agree with the idea behind the current definition of this: if the class provides its own definition for a method, that should take precedence over the role's definition. If it doesn't, then it adopts the role's definition as its own. I would hope it is the role if a as of now unknown syntax has declared it. Perhaps it should be even the default. The rational for my claim is that a role is composed several times and then every class doing the role automatically gets the correct version. Otherwise all classes are burdened with caring for the role's part in the method. Huh?
Re: signature subtyping and role merging
On 10/11/06, TSa [EMAIL PROTECTED] wrote:
HaloO,
with my idea of deriving a type lattice from all role definitions
the problem of subtyping signatures arises. Please help me to think
this through. Consider
role Foo
{
sub blahh(Int, Int) {...}
}
role Bar
{
sub blahh(Str) {...}
}
role Baz does Foo does Bar # Foo|Bar lub
{
# sub blahh(IntStr,Int?) {...}
}
Please, no attempts to merge signatures. Instead, use multiple
dispatch (though technically this doesn't kick in until the role is
composed into a class). Thus:
role Foo
{
multi blahh(Int, Int) {...}
}
role Bar
{
multi blahh(Str) {...}
}
role Baz does Foo does Bar # Foo|Bar lub
{
# multi blahh(Int, Int) {...}
# multi blahh(Str) {...}
}
Remember that the name and the signature are used together to identify
the routine for dispatch and composition purposes.
Also, sub is an odd choice to use while illustrating role composition;
while subs _are_ allowed in roles AFAIK, they're generally not put
there. Methods and submethods are by far more common.
--
Jonathan Dataweaver Lang
Re: signature subtyping and role merging
This is the dog does bark vs tree does bark problem. You can assume that
the two methods blahh have naything semantically to do with each other at
all. Unless ther is a specif annotation from the programmer creating the Role
union that they are the same you must assume that they are different.
Therefore your proposed signiture merge is nonsense in the general case. Even
if the signature are the same the only case where you are justified in assuming
that are the same method is if both composed Roles inherited the method from
a common ancestor and even then you must solve the diamond inheritence problem.
--
Mark Biggar
[EMAIL PROTECTED]
[EMAIL PROTECTED]
[EMAIL PROTECTED]
-- Original message --
From: TSa [EMAIL PROTECTED]
HaloO,
with my idea of deriving a type lattice from all role definitions
the problem of subtyping signatures arises. Please help me to think
this through. Consider
role Foo
{
sub blahh(Int, Int) {...}
}
role Bar
{
sub blahh(Str) {...}
}
role Baz does Foo does Bar # Foo|Bar lub
{
# sub blahh(IntStr,Int?) {...}
}
The role Baz has to be the lub (least upper bound) of Foo and Bar.
That is the join of two nodes in the lattice. This means first of
all the sub blahh has to be present. And its signature has to be
in a subtype relation : to :(Int,Int) and :(Str). Note that
Int : IntStr and Int|Str : Int. The normal contravariant subtyping
rules for functions gives
+- : ---+
||
:(IntStr,Int?) : :(Int,Int)
| |
+--- : ---+
and
+- : ---+
||
:(IntStr,Int?) : :(Str)
I hope you see the contravariance :)
The question mark shall indicate an optional parameter that
allows the subtype to be applicable in both call sites that
have one or two arguments.
The choice of glb for the first parameter makes the sub in Baz
require the implementor to use the supertype of Int and Str
which in turn allows the substitution of Int and Str arguments
which are subtypes---that is types with a larger interface.
Going the other way in the type lattice the meet FooBar of the
two roles Foo and Bar is needed. But here the trick with the
optional parameter doesn't work and it is impossible to reconcile
the two signatures. This could simply mean to drop sub blahh from
the interface. But is there a better way? Perhaps introducing a
multi?
Apart from the arity problem the lub Int|Str works for the first
parameter:
+- : ---+
||
:(Int|Str,Int) : :(Int,Int)
| |
+--- : ---+
+ : ---+
| |
:(Int|Str) : :(Str)
Regards, TSa.
--
Re: Runtime role issues
--- TSa [EMAIL PROTECTED] wrote: First, when a role is applied to a class at runtime, a instance of that class in another scope may specifically *not* want that role. Is there a way of restricting a role to a particular lexical scope short of applying that role to instances instead of classes? I think you'll need an intermediate class that you use to apply your role. Classes are open and that implies the possibility to merge further roles into them. But this applies for all users of the class. How this works when there are already instances I don't know. Ah, that makes sense. Second, how can I remove roles from classes? Is that a wise thing to do? Roles are not assigned and removed as a regular operation. What is your use case? I don't think I have a clear use case here because the examples that come to mind all involve adding and then quickly removing the extra behaviors when I'm done with them. That's going to be fraught with bugs. The intermediate class solves the problem but it instantly suggests that we have a new design pattern we have to remember. Basically, if I can't lexically scope the additional behavior a role offers, I potentially need to remove the role or use the intermediate class pattern. I suppose one could look at this as separation of concerns. If I have an MVC framework, instances of objects in the M, V, or C portions might want to exhibit different behaviors, depending upon what I'm doing with them, but I don't necessarily want those behaviors to bleed over to the other layers of my application. Whether or not this is a clean way of looking at the problem, I don't know. Cheers, Ovid -- Buy the book -- http://www.oreilly.com/catalog/perlhks/ Perl and CGI -- http://users.easystreet.com/ovid/cgi_course/
Re: [perl #40483] [PATCH] removal of cuddled else's in C source
On 10/11/06, Bernhard Schmalhofer via RT [EMAIL PROTECTED] wrote: On Mi. 11. Okt. 2006, 08:10:45, [EMAIL PROTECTED] wrote: Yes, I got exacly the same output from r14895. Actually, this patch was already applied by Bernhard in r14870, which explains why the effected files list looks different. Sorry for creating confusion. I forgot to close this ticket after applying the patch in r14870. ah, no problem. thanks for applying. now that you (and paul) mention it, i think i remember ++ing you earlier for it :) ~jerry
Re: [perl #40505] [PATCH] Addition of pmc files to codingstd tests
On Wednesday 11 October 2006 01:19, Paul Cochrane wrote: This is because I was too fast with the Send button, and forgot to attach the patch. Apologies for the doubled-up email. Nit: you can reply to a previous RT mail and attach the patch there. That saves a duplicate bug report that someone has to read, consider, and finally close as a duplicate. -- c
Re: Synposis 26 - Documentation [alpha draft]
Jonathan Lang wrote: The only thing that I'd like to see changed would be to allow a more flexible syntax for formatting codes - in particular, I'd rather use something analogous to the 'embedded comments' described in S02, replacing the leading # with an appropriate capital letter (as defined by Unicode) and insisting on a word break just prior to it. It was a deliberate decision to restrict the delimiters to angles. Unlike embedded comments, formatting codes are predominantly embedded in text, not code, so it's important to keep them easy-to-locate (i.e. with a consistent delimiter) and not to allow too many syntaxes (which increases the chance of unintended codes in normal text). A leading word break is not really practical either, since documenters will need to use codes in the middle of words: PractIise (and then practIice) saying GarEccedilon! I'd also prefer a more Wiki-like dialect at some point (e.g., '__underlined text__', '_italicized text_' and '*bold*' instead of 'Uunderlined text', 'Iitalicized text' and 'Bbold'); but that can wait. That's Kwid. Which Ingy has proposed as a standard Perldoc dialect. You'll be able to flip into kwid mode (for Perldoc parsers that support it) using: =begin kwid =end kwid Damian
Re: [perl #40513] [CAGE] add flex/bison files to c coding standard tests
Jerry Gay (via RT) wrote: *.l and *.y are c files, and must meet the coding standards for this filetype. ~jerry By this filetype I assume you mean the C standard. Although these files contain C code and that code should be written to the C standard, they are not C files. Each should have its own standard and part of that standard is: Where C code appears, it should be written to the C standard as describe in (reference to C standard documentation). This means that standards must be written for flex and bison. Neither is part of C and cannot be part of its standard. But because C is part of their files, the C standard must be part of their standards. To put it in C terms: the flex and bison standards must include the C standard, not the other way around. -- __END__ Just my 0.0002 million dollars worth, Shawn For the things we have to learn before we can do them, we learn by doing them. Aristotle Where you find the greatest fear, you find the greatest courage. BRIAN: You're all individuals! CROWD: We're all individuals! LONE VOICE IN THE BACK: I'm not!
[svn:parrot-pdd] r14903 - in trunk: . docs/pdds/clip
Author: allison
Date: Wed Oct 11 13:37:08 2006
New Revision: 14903
Modified:
trunk/docs/pdds/clip/pdd25_threads.pod
Changes in other areas also in this revision:
Modified:
trunk/ (props changed)
Log:
[EMAIL PROTECTED]: allison | 2006-10-11 13:18:42 -0700
Partial update of Threads PDD with collected wisdom from prior discussion.
Modified: trunk/docs/pdds/clip/pdd25_threads.pod
==
--- trunk/docs/pdds/clip/pdd25_threads.pod (original)
+++ trunk/docs/pdds/clip/pdd25_threads.pod Wed Oct 11 13:37:08 2006
@@ -20,7 +20,748 @@
=head1 DESCRIPTION
-Description of the subject.
+=head1 DEFINITIONS
+
+So we can all talk about things the same way, the following
+definitons apply. Some of these are drawn from the POSIX thread spec,
+and as such we should have a translation section at the end.
+
+=over 4
+
+=item THREAD
+
+An OS level thread. If that makes no sense, neither will any of the
+rest of this, in which case I recommend picking up Programming with
+POSIX Threads by Dave Butenhof, and coming back when you have.
+
+=item MUTEX
+
+This is a low level, under the hood, not exposed to users, thing that
+can be locked. They're non-recursive, non-read/write, exclusive
+things. When a thread gets a mutex, any other attempt to get that
+mutex will block until the owning thread releases the mutex. The
+platform-native lock construct will be used for this.
+
+{{ - Nigel Sandever: Will this be macroised to hide the platform native
+implementation from the main body of the code?
+- Dan: Yes. }}
+
+=item LOCK
+
+This is an exposed-to-HLL-code thing that can be locked. Only PMCs can
+be locked, and the lock may or may not be recursive or read/write.
+
+=item CONDITION VARIABLE
+
+The sleep until something pings me construct. Useful for queue
+construction. Not conceptually associated with a MUTEX. (POSIX
+threads require this, so we're going to hide it there behind macros
+and/or functions)
+
+{{ - Nigel Sandever: Could you elaborate on the nature of what would constitute
+a ping?
+- Dan: POSIX has a function cond_signal (and cond_broadcast, which is
+similar). What happens is a thread grabs the condition variable and
+goes to sleep, and sleeps until another thread does a cond_signal,
+which then wakes it up. If there are multiple threads sleeping on the
+condition variable, only one is woken. (cond_broadcast wakes them all
+up) }}
+
+=item RENDEZVOUS POINT
+
+A HLL version of a condition variable.
+
+=item INTERPRETER
+
+Those bits of the Parrot_Interp structure that are absolutely required
+to be thread-specific. This includes the current register sets and
+stack pointers, as well as security context information. Basically if
+a continuation captures it, it's the interpreter.
+
+=item INTERPRETER ENVIRONMENT
+
+Those bits of the Parrot_Interp structure that aren't required to be
+thread-specific (though I'm not sure there are any) IPLUS anything
+pointed to that doesn't have to be thread-specific.
+
+The environment includes the global namespaces, pads, stack chunks,
+memory allocation regions, arenas, and whatnots. Just because the
+pointer to the current pad is thread-specific doesn't mean the pad
+Iitself has to be. It can be shared.
+
+=item INDEPENDENT THREAD
+
+A thread that has no contact IAT ALL with the internal data of any
+other thread in the current process. Independent threads need no
+synchronization for anything other than what few global things we
+have. And the fewer the better, though alas we can't have none at all.
+
+Note that independent threads may still communicate back and forth by
+passing either atomic things (ints, floats, and pointers) or static
+buffers that can become the property of the destination thread.
+
+=item SHARED THREAD
+
+A thread that's part of a group of threads sharing a common
+interpreter environment.
+
+{{ - Leo: I presume that this group of threads is one thread pool or
+interpreter pool. Could you expand the definition to cover pool.
+- Dan: Ah, damn, I needed to fix that up before sending it out. Should've been
+SHARED INTERPRETER. A shared interpreter is one that's in an interpreter
+pool.
+
+An interpreter pool is a set of interpreters that share common
+resources. They're essentially threads in the OS sense, and they have
+shared access to pretty much everything. The memory pools, arenas,
+and global namespace are shared--pretty much everything except what's
+in the interpreter structure itself. }}
+
+=back
+
+=head1 REQUIREMENTS
+
+=head2 Supported Models
+
+=over 4
+
+=item POSIX threads
+
+The threading scheme must be sufficient to support a POSIX
+share-everything style of threading, such as is used in perl 5's
+pthread model, as well as the thread models for Ruby and Python.
+
+=item Process-type threads
+
+The scheme must also support the perl 5 iThreads threading
+model. In this model no data is shared implicitly, and all sharing
+must be done on purpose and
Re: Null PMC access while parsing javascript
I have rewritten the grammar. There are some problems though.
- I don't know how to express thinks like: an identifier is
[a..zA..Z_$]*, but not a keyword. Something like: rule identifier
{!keyword[a..zA..Z_$]*} seems not to allow identifiers that have
keywords as prefix.
- I couldn't make comments work.
- I don't know how to handle unicode,
- How to accomplish semicolon insertion?
- With some programs it doesn't stop. I don't know if it gets in an
infinite loop or it is too slow, I didn't have time to look at it.
Comments are welcome.
--
Mehmet
jsparser.tar.gz
Description: GNU Zip compressed data
Re: [svn:parrot-pdd] r14903 - in trunk: . docs/pdds/clip
Am Mittwoch, 11. Oktober 2006 22:37 schrieb [EMAIL PROTECTED]: Log: [EMAIL PROTECTED]: allison | 2006-10-11 13:18:42 -0700 Partial update of Threads PDD with collected wisdom from prior discussion. I know the pdd is partial, but don't forget STM, which is a) implemented and b) solves a lot of described PMC sharing troubles e.g. hierachical locking needs. leo
Cage Cleaner Wrangler?
Hi all, Who's looking after the Cage Cleaners these days? I've noticed a few people applying the patches, but it would be nice to have someone making sure we don't miss anything. -- c
Re: Null PMC access while parsing javascript
On Wed, Oct 11, 2006 at 10:56:39PM +0200, Mehmet Yavuz Selim Soyturk wrote:
I have rewritten the grammar. There are some problems though.
- I don't know how to express thinks like: an identifier is
[a..zA..Z_$]*, but not a keyword. Something like: rule identifier
{!keyword[a..zA..Z_$]*} seems not to allow identifiers that have
keywords as prefix.
For now, try adding a \b at the ends of the keyword rule:
token keyword { \b [ if | else | for | while | ... ] \b }
Then keyword will match only the exact keyword.
However, the \b metacharacter is disappearing soon, to be replaced
by ?wb and !wb. In its place will be and , making
the above:
token keyword { [ if | else | for | while | ... ] }
I'll get and added into PGE today/tomorrow.
- I couldn't make comments work.
- I don't know how to handle unicode,
- How to accomplish semicolon insertion?
I'll have to look at the grammar a bit and see what I can come up
with here.
Pm
Re: Cage Cleaner Wrangler?
On Oct 11, 2006, at 4:32 PM, chromatic wrote: Who's looking after the Cage Cleaners these days? I've noticed a few people applying the patches, but it would be nice to have someone making sure we don't miss anything. I should be, but I've clearly been very lax. Would someone like to wear my cap? -- Andy Lester = [EMAIL PROTECTED] = www.petdance.com = AIM:petdance
Re: Cage Cleaner Wrangler?
i'd volunteer but what skills/duties are involved? hal chicago On Oct 11, 2006, at 4:34 PM, Andy Lester wrote: On Oct 11, 2006, at 4:32 PM, chromatic wrote: Who's looking after the Cage Cleaners these days? I've noticed a few people applying the patches, but it would be nice to have someone making sure we don't miss anything. I should be, but I've clearly been very lax. Would someone like to wear my cap? -- Andy Lester = [EMAIL PROTECTED] = www.petdance.com = AIM:petdance
Re: Runtime Role Issues
On Tue, Oct 10, 2006 at 01:31:59PM -0700, Ovid wrote: Hi all, In doing a bit of work with traits (roles) in Perl 5 (http://perlmonks.org/?node_id=577477), I've realized some edge cases which could be problematic. First, when a role is applied to a class at runtime, a instance of that class in another scope may specifically *not* want that role. I always thought when a role is applied to a class at runtime you get a new (anonymous) subclass. The original class isn't affected. Tim. Is there a way of restricting a role to a particular lexical scope short of merely applying that role to instances instead of classes? Second, how can I remove roles from classes? I've create some code which adds an is_selected method to some classes but when I'm done, I'd like top easily remove that role. How do I do that? Seems closely related to my first question, but it's still a distinct issue, I think. Third, http://dev.perl.org/perl6/doc/design/syn/S12.html says: You can also mixin a precomposed set of roles: $fido does Sentry | Tricks | TailChasing | Scratch; Should that be the following? $fido does Sentry Tricks TailChasing Scratch; Cheers, Ovid -- Buy the book -- http://www.oreilly.com/catalog/perlhks/ Perl and CGI -- http://users.easystreet.com/ovid/cgi_course/
Re: Runtime Role Issues
在 Oct 12, 2006 5:43 AM 時，Tim Bunce 寫到： On Tue, Oct 10, 2006 at 01:31:59PM -0700, Ovid wrote: Hi all, In doing a bit of work with traits (roles) in Perl 5 (http://perlmonks.org/?node_id=577477), I've realized some edge cases which could be problematic. First, when a role is applied to a class at runtime, a instance of that class in another scope may specifically *not* want that role. I always thought when a role is applied to a class at runtime you get a new (anonymous) subclass. The original class isn't affected. Right, that's what usually happens with: my Dog $fido .= new; $fido does Catlike; Here $fido's class become a new (memoized, anonymous) class that still has Dog as its name, but is no longer equivalent to the vanilla ^Dog class object. To forcefully add a role to a class at a distance during runtime, use a class object call (see Moose::Meta::Class for more about these APIs): ^Dog.add_role(^Catlike); Thanks, Audrey
s[pattern] = { doit } illegal, why?
While I agree with most of the changes made to the s[]... notation,
there's one oddity that I just spotted:
S05 says:
This is not a normal assigment, since the right side is
evaluated each time the substitution matches (much like the
pseudo-assignment to declarators can happen at strange times).
It is therefore treated as a thunk, that is, as if it has
implicit curlies around it. In fact, it makes no sense at all
to say
s[pattern] = { doit }
because that would try to substitute a closure into the string.
So I can't say something like
s[(\d+)!] = { my $num = 1; $num *= $_ for 0..$0; return $num; }
or
s:s:g[(\w+): (\d+) dB] =
@() - $name, $num {
$num = exp($num/10, 10);
say $name has excessive wattage: $num Watts if $num 100;
$name: $num Watts;
}
or
s:s:g[, (\w+): (.+) ,] = @() - $key, $val { $key = $val }
? That seems like a pretty significant limitation. Could closures be
an exception to the implicit curlies rule? That is: if you supply
your own closure on the right, the substitution algorithm accepts it
as is; if you supply anything else, it gets wrapped in a closure as
described.
--
Jonathan Dataweaver Lang
Re: s[pattern] = { doit } illegal, why?
On Wed, Oct 11, 2006 at 05:55:45PM -0700, Jonathan Lang wrote:
: While I agree with most of the changes made to the s[]... notation,
: there's one oddity that I just spotted:
:
: S05 says:
: This is not a normal assigment, since the right side is
: evaluated each time the substitution matches (much like the
: pseudo-assignment to declarators can happen at strange times).
: It is therefore treated as a thunk, that is, as if it has
: implicit curlies around it. In fact, it makes no sense at all
: to say
:
: s[pattern] = { doit }
:
: because that would try to substitute a closure into the string.
:
: So I can't say something like
:
:s[(\d+)!] = { my $num = 1; $num *= $_ for 0..$0; return $num; }
s[(\d+)!] = { my $num = 1; $num *= $_ for 0..$0; return $num; }
s[(\d+)!] = { my $num = 1; $num *= $_ for 0..$0; return $num; }.()
s[(\d+)!] = do { my $num = 1; $num *= $_ for 0..$0; return $num; }
: or
:
:s:s:g[(\w+): (\d+) dB] =
: @() - $name, $num {
:$num = exp($num/10, 10);
:say $name has excessive wattage: $num Watts if $num 100;
:
:$name: $num Watts;
: }
s:s:g[(\w+): (\d+) dB] = do
given @() - [$name, $num] {
$num = exp($num/10, 10);
say $name has excessive wattage: $num Watts if $num 100;
$name: $num Watts;
}
: or
:
:s:s:g[, (\w+): (.+) ,] = @() - $key, $val { $key = $val }
s:s:g[, (\w+): (.+) ,] = - $key, $val { $key = $val }.(@())
s:s:g[, (\w+): (.+) ,] = do for @().each - $key, $val { $key = $val }
: ? That seems like a pretty significant limitation. Could closures be
: an exception to the implicit curlies rule? That is: if you supply
: your own closure on the right, the substitution algorithm accepts it
: as is; if you supply anything else, it gets wrapped in a closure as
: described.
Could do that too (and there's even precedent with attribute defaults),
but outlawing it (at least for now) keeps people from cargo culting
P5's s{foo}{bar} into P6's s{foo}={bar}.
Larry
Re: s[pattern] = { doit } illegal, why?
On Wed, Oct 11, 2006 at 06:29:00PM -0700, Larry Wall wrote:
: s:s:g[, (\w+): (.+) ,] = - $key, $val { $key = $val }.(@())
Hmm, that won't work, since @() is a single argument. It'd have to be one of:
s:s:g[, (\w+): (.+) ,] = - [$key, $val] { $key = $val }.(@())
s:s:g[, (\w+): (.+) ,] = - $key, $val { $key = $val }.(|@())
Larry
Re: s[pattern] = { doit } illegal, why?
In short, nearly every case where I'm looking to use a raw closure
can be handled almost as easily by prefacing it with Cdo (if the
block doesn't take parameters) or Cdo given (if it does). A bit
more wordy than I'd like, but acceptable; it still reads well.
Although I'd recommend pointing this option out in S05, right after
you say that s[pat] = { doit() } won't work.
On 10/11/06, Larry Wall [EMAIL PROTECTED] wrote:
s:s:g[, (\w+): (.+) ,] = do for @().each - $key, $val { $key = $val }
Minor point: Since the right side gets called for each left-side
match, isn't the C.each redundant? For that matter, isn't the
Cfor overkill as well? C@() will only ever have two elements per
call, after all...
: Could closures be
: an exception to the implicit curlies rule? That is: if you supply
: your own closure on the right, the substitution algorithm accepts it
: as is; if you supply anything else, it gets wrapped in a closure as
: described.
Could do that too (and there's even precedent with attribute defaults),
but outlawing it (at least for now) keeps people from cargo culting
P5's s{foo}{bar} into P6's s{foo}={bar}.
This would be the ye olde code doesn't do a text substitution
anymore issue, right? And there _is_ still the possibility of
permitting it in some later subversion of Perl 6, once people have
gotten Perl 5 out of their systems...
--
Jonathan Dataweaver Lang
Re: Synposis 26 - Documentation [alpha draft]
Dave Whipp wrote: I'm not a great fan of this concept of reservation when there is no mechanism for its enforcement (and this is perl...). What makes you assume there will be no mechanism for enforcement? The standard Pod parser (of which I have a 95% complete Perl 5 implementation) will complain bitterly--as in cyanide--when unknown pure-upper or pure-lower block names are used. The whole point of reserving these namespaces is not to prevent users from misusing them, but to ensure that when we eventually get around to using a particular block name, and those same users start screaming about it, we can mournfully point to the passage in the original spec and silently shake our heads. ;-) Damian
