Re: S5: substitutions
On 10/9/06, Jonathan Lang [EMAIL PROTECTED] wrote:
Smylers wrote:
To be consistent your proposal should also suggest that these become
equivalent:
* { function() }
* qq[ {function() }]
* qq{ function() }
* eval function()
How so? AFAIK, string literal syntax requires you to prepend a sigil
on the front of any embedded closure that you want to interpolate a
value from; otherwise, it isn't a closure - it's just a pair of
curly-brace characters. My proposal isn't curly braces _always_ act
like closures, no matter what; it's the second part of a s[]
construct doesn't have to be a literal; it can be anything that can be
evaluated as needed by the algorithm to provide substitute text.
According to S02 bare curlies do interpolate in double-quoted strings:
S02 =item *
S02
S02 A bare closure also interpolates in double-quotish context. It may
S02 not be followed by any dereferencers, since you can always put them
S02 inside the closure. The expression inside is evaluated in scalar
S02 (string) context. You can force list context on the expression using
S02 the Clist operator if necessary.
--
Markus Laire
Re: S5: substitutions
Markus Laire wrote: According to S02 bare curlies do interpolate in double-quoted strings: Yeah; that was subsequently pointed out to me. Oops. -- Jonathan Dataweaver Lang
Re: Nitpick my Perl6 - parametric roles
HaloO, Darren Duncan wrote: Within a system that already has an underlying set-like type, the Junction in this case, a test for uniqueness is (pardon any spelling): all(@items).elements.size === @items.size The all() will strip any duplicates, so if the number of elements in all(@items) is the same as @items, then @items has no duplicates. OK, but you are not using the 'set with additional behavior' of junctions. How would that be spelled with a pure set? set(@items).elements.size === @items.size perhaps? This would nicely blend with the junction forms. Would it even be the case that Set is a super role of the junctions? Regards, --
[svn:perl6-synopsis] r13014 - doc/trunk/design/syn
Author: larry Date: Tue Oct 10 11:57:24 2006 New Revision: 13014 Modified: doc/trunk/design/syn/S03.pod Log: For hypers, break out dimensional dwimmery from ordinary shape processing. Dwimming hyperinfixes now point the small end at the runt. Unaries never dwim. :) Modified: doc/trunk/design/syn/S03.pod == --- doc/trunk/design/syn/S03.pod(original) +++ doc/trunk/design/syn/S03.podTue Oct 10 11:57:24 2006 @@ -717,30 +717,62 @@ =head2 Hyper operators The Unicode characters C» (C\x[BB]) and C« (C\x[AB]) and -their ASCII digraphs C and C are used to denote -list operations, which operate on each element of two lists (or -arrays) and return a list (or array) of the results. Spaces are not -allowed on the pointy end of each hyper, but are allowed on the -blunt end (except for postfix operators, which must still follow postfix -spacing rules, but do allow for an additional dot before the hyper). - -The precedence of any hyperoperator is the same as its base operator. -This means that you must parenthesize your lists for most operators. -For example: +their ASCII digraphs C and C are used to denote a +list operation that operates on each element of its list (or array) +argument (or arguments) and returns a single list (or array) of +the results. In otherwords, a hyper operator evaluates its arguments in +scalar context but then distributes the operator over them as lists. + +When writing a hyper operator, spaces are not allowed on the inside, +that is, between any hyper marker and the operator it's modifying. +On the outside the spacing policy is the same as the base operator. +Likewise the precedence of any hyperoperator is the same as its +base operator. This means that you must parenthesize your comma +lists for most operators. For example: + -« (1,2,3)# (-1, -2, -3) (1,1,2,3,5) »+« (1,2,3,5,8); # (2,3,5,8,13) -If either argument is insufficiently dimensioned, Perl upgrades it: +A unary hyper operator (either prefix or postfix) has only one +hyper marker, located on its argument side, while an infix operator +always has one on each side to indicate there are two arguments. +Unary operators always produce a list or array of exactly the same +shape as their single argument. When infix operators are presented with +two lists or arrays of identical shape, a result of that same shape is +produced. Otherwise the result depends on how you write the hyper +markers. - (3,8,2,9,3,8) - 1; # (2,7,1,8,2,7) +For an infix operator, if either argument is insufficiently +dimensioned, Perl upgrades it, but only if you point the sharp end +of the hypermarker at it. -In fact, this is the Ionly form that will work for an unordered type -such as a CBag: + (3,8,2,9,3,8) - 1; # (2,7,1,8,2,7) + @array »+=» 42; # add 42 to each element - Bag(3,8,2,9,3,8) - 1; # Bag(2,7,1,8,2,7) === Bag(1,2,2,7,7,8) +In fact, an upgraded scalar is the only thing that will work for an +unordered type such as a CBag: -When using a unary operator, only put the hyper on the side of the -single operand: + Bag(3,8,2,9,3,8) - 1; # Bag(2,7,1,8,2,7) === Bag(1,2,2,7,7,8) + +In other words, pointing the small end at an argument tells the hyperoperator +to dwim on that side. If you don't know whether one side or the other will +be underdimensioned, you can dwim on both sides: + +$left «*» $right + +The upgrade never happens on the blunt end of a hyper. If you write + +$bigger «*« $smaller +$smaller »*» $bigger + +and exception is thrown, and if you write + +$foo »*« $bar + +you are requiring the shapes to be identical, or an exception will be thrown. + +When using a unary operator, you always aim the blunt end at the +single operand, because no dwimmery every happens: @negatives = -« @positives; @@ -757,19 +789,22 @@ Note that method calls are really postfix operators, not infix, so you shouldn't put a C« after the dot. -Hyper operators are defined recursively on arrays, so: +Hyper operators are defined recursively on shaped arrays, so: -« [[1, 2], 3] #[-«[1, 2], -«3] # == [[-1, -2], -3] -[[1, 2], 3] »+« [4, [5, 6]] #[[1,2] »+« 4, 3 »+« [5, 6]] + +Likewise the dwimminess of dwimmy infixes propagates: + +[[1, 2], 3] «+» [4, [5, 6]] #[[1,2] «+» 4, 3 «+» [5, 6]] # == [[5, 6], [8, 9]] -More generally, hyper operators work recursively for any object +More generally, a dwimmy hyper operator works recursively for any object matching the CEach role even if the object itself doesn't support the operator in question: -Bag(3,8,[2,Seq(9,3)],8) - 1; # Bag(2,7,[1,Seq(8,2)],7) -Seq(3,8,[2,Seq(9,3)],8) - (1,1,2,1); # Seq(2,7,[0,Seq(7,1)],7) +Bag(3,8,[2,Seq(9,3)],8) - 1; #
[svn:perl6-synopsis] r13015 - doc/trunk/design/syn
Author: larry Date: Tue Oct 10 12:10:23 2006 New Revision: 13015 Modified: doc/trunk/design/syn/S03.pod Log: Forgot to update version and date. Also forgot to mention self-extending lists using *. :) Modified: doc/trunk/design/syn/S03.pod == --- doc/trunk/design/syn/S03.pod(original) +++ doc/trunk/design/syn/S03.podTue Oct 10 12:10:23 2006 @@ -12,9 +12,9 @@ Maintainer: Larry Wall [EMAIL PROTECTED] Date: 8 Mar 2004 - Last Modified: 28 Sept 2006 + Last Modified: 10 Oct 2006 Number: 3 - Version: 69 + Version: 70 =head1 Changes to Perl 5 operators @@ -501,6 +501,16 @@ Note: infinite lists are constructed lazily. And even though C*..* can't be constructed at all, it's still useful as a selector object. +For any kind of zip or dwimmy hyper operator, any list ending with C* +is assumed to be infinitely extensible by taking its final element +and replicating it: + +@array, * + +is short for something like: + +@[EMAIL PROTECTED], @array[-1] xx * + =item * The unary C^ operator generates a range from C0 up to one less than its argument. So C^4 is short for C0..^4 or C0..3.
Re: Recursing? hypers
On Sun, Oct 08, 2006 at 04:07:37PM +0200, Juerd wrote: : S03 says that hypers recurse into subarrays. : : That's a nice and useful feature, but that not-recursing is even more : useful. Especially given that many objects will probably does Array, you : want to be explicit about recursion. : : S03 doesn't give a way to avoid recursion. Recursion is not really the issue here. Conformancy is, I think. : I suggested on #perl6 that standard hypers do not recurse, and a new : operator: double hypers. These are the same, but they do recurse. From : my point of view, hypers should operate on lists, not arrays. Recursive : hypers would work on arrays because arrays are single element lists. See the latest S03 changes. Standard hypers now require conformancy, and I introduced small-ended hypers (whimpers?) to ask for dwimmery. : Audrey agreed. Audrey is very agreeable. :) : It would probably be useful to allow combinations of recursive and : non-recursive hypers. : : »+«# do not dive into arrays : »»+«« # do dive into arrays, on both sides : »+«« # dive into arrays only on the RHS : »»+« # same, but LHS : : 42, 15 »+ 1 # 43, 16 : : ( 42, 15 ) »+ 1 # 43, 16 : : [ 42, 15 ] »+ 1 # 2 : : [ 42, 15 ] »»+ 1 # [ 43, 16 ] : : The ASCII variant is a bit big, but that's okay huffmanwise, IMO. : Recursion can be a pretty big operation anyway. Being explicit about : that is good. I think the current S03 solution is a lot prettier, and keeps most of the symmetry of the old hyper solution, while visually indicating the smaller argument: @foo »+» 1 For the old symmetrically dwimmy infix hyper behavior you just write: @foo «+» @bar Larry
[svn:perl6-synopsis] r13019 - doc/trunk/design/syn
Author: larry Date: Tue Oct 10 13:09:12 2006 New Revision: 13019 Modified: doc/trunk/design/syn/S03.pod Log: typo from wolverian++ Modified: doc/trunk/design/syn/S03.pod == --- doc/trunk/design/syn/S03.pod(original) +++ doc/trunk/design/syn/S03.podTue Oct 10 13:09:12 2006 @@ -786,7 +786,7 @@ this happens only on the dwimmy side. When using a unary operator, you always aim the blunt end at the -single operand, because no dwimmery every happens: +single operand, because no dwimmery ever happens: @negatives = -« @positives;
Re: [svn:perl6-synopsis] r12875 - doc/trunk/design/syn
[EMAIL PROTECTED] skribis 2006-10-09 0:22 (-0700):
P5's s[pat][repl] syntax is dead, now use s[pat] = repl
Why keep the s?
substr works perfectly as both rvalue and lvalue, and I think m[], also
known as //, can do the same. No need to do things based on delimiter
(bracket versus non-bracket), then.
+ s[pattern] = doit()
m[pattern] = doit();
/pattern/ = doit();
+ $str.subst(/pat/, replacement);
+ $str.subst(/pat/, {replacement});
+ $str.=subst(/pat/, replacement);
+ $str.=subst(/pat/, {replacement});
Hmmm... I have no answer for the non-mutating version, but:
$str.match(/pat/) = replacement;
$str.m(/pat) = replacement;
+This is not a normal assigment, since the right side is evaluated each
+time the substitution matches
Can't this be generalized somehow? Return an lvalue proxy, like substr
does, and make thunking the default for certain LHS types.
I don't like special syntax that looks like normal syntax.
--
korajn salutojn,
juerd waalboer: perl hacker [EMAIL PROTECTED] http://juerd.nl/sig
convolution: ict solutions and consultancy [EMAIL PROTECTED]
Ik vertrouw stemcomputers niet.
Zie http://www.wijvertrouwenstemcomputersniet.nl/.
Re: [svn:perl6-synopsis] r12875 - doc/trunk/design/syn
On Tue, Oct 10, 2006 at 10:49:11PM +0200, Juerd wrote:
: [EMAIL PROTECTED] skribis 2006-10-09 0:22 (-0700):
: P5's s[pat][repl] syntax is dead, now use s[pat] = repl
:
: Why keep the s?
Because @Larry felt it was better to keep the intent out in front.
: substr works perfectly as both rvalue and lvalue, and I think m[], also
: known as //, can do the same. No need to do things based on delimiter
: (bracket versus non-bracket), then.
:
: + s[pattern] = doit()
:
: m[pattern] = doit();
: /pattern/ = doit();
We thought about that, but the intent is obscured.
: + $str.subst(/pat/, replacement);
: + $str.subst(/pat/, {replacement});
: + $str.=subst(/pat/, replacement);
: + $str.=subst(/pat/, {replacement});
:
: Hmmm... I have no answer for the non-mutating version, but:
:
: $str.match(/pat/) = replacement;
: $str.m(/pat) = replacement;
And I even predicted somewhere that someone would immediately ask for
a method form of pseudo-assignment. But macros and dynamic dispatch
don't mix well, and I think if you really want the macro it's just
about as easy to write:
$str ~~ s(/pat) = replacement;
: +This is not a normal assigment, since the right side is evaluated each
: +time the substitution matches
:
: Can't this be generalized somehow? Return an lvalue proxy, like substr
: does, and make thunking the default for certain LHS types.
Well, I'm not sure I like that much hidden run-time apparatus, and it doesn't
solve the basic macroish problem that the replacement has to be a lazy thunk.
: I don't like special syntax that looks like normal syntax.
Then by all means also avoid these:
has $.answer = 42;
state $s = 0;
:-)
Larry
Re: [svn:perl6-synopsis] r12875 - doc/trunk/design/syn
On Tue, Oct 10, 2006 at 02:17:50PM -0700, Larry Wall wrote: : $str ~~ s(/pat) = replacement; Er, cut-n-paste error. Make that: $str ~~ s[pat] = replacement; Larry
Capturing subexpression numbering example
The example in S05 under Subpattern numbering isn't quite complex enough to give the reader a full understanding of the ramifications of the re-numbering that occurs with alternations, especially with respect to the combination of capturing and non-capturing subpatterns. I've written a small example and explanation to address this (attached as diff) based on an IRC conversation with fglock. If it's deemed correct, could this be included, please? --- Rule.pod.orig 2006-10-10 17:26:39.0 -0400 +++ Rule.pod 2006-10-10 17:37:17.0 -0400 @@ -1956,6 +1956,21 @@ C(undef, undef, undef, undef, undef, undef, 'every', 'green', 'BEM', 'devours', 'faces') (as the same regex would in Perl 5). +If non-capturing brackets are used, this can become more complex. +Every time C| appears inside of non-capturing brackets, the subpattern +index is returned to the index that it had when entering the +brackets. When exiting the brackets, the next capturing subpattern +will have an index one higher than the highest subpattern inside +the non-capturing brackets. Here is such an example: + +#$0$1 $2$1$3 +$match = rx/ (a) [ (b) (c) | (d) ] (e) /; + +Notice that it is not the most recent C$1 that determines +the index of the C(e) subpattern, but the C(c) subpattern that +incremented the index to C$2. Therefore C(e) has an index +of C$3. + =item * Note that it is still possible to mimic the monotonic Perl 5 capture
Re: Nitpick my Perl6 - parametric roles
At 4:08 PM +0200 10/10/06, TSa wrote: HaloO, Darren Duncan wrote: Within a system that already has an underlying set-like type, the Junction in this case, a test for uniqueness is (pardon any spelling): all(@items).elements.size === @items.size The all() will strip any duplicates, so if the number of elements in all(@items) is the same as @items, then @items has no duplicates. OK, but you are not using the 'set with additional behavior' of junctions. How would that be spelled with a pure set? set(@items).elements.size === @items.size perhaps? This would nicely blend with the junction forms. Yes, that is exactly how it would be spelled with a pure set. In fact, your example is the more normal one, in that simply turning a collection into a set removes duplicates. I used all() in my example because that is the Junction equivalent of making a set that contains all distinct members of @items. -- Darren Duncan
[svn:perl6-synopsis] r13022 - doc/trunk/design/syn
Author: larry Date: Tue Oct 10 16:55:33 2006 New Revision: 13022 Modified: doc/trunk/design/syn/S03.pod Log: Clarification of non-ambiguity of «*» Modified: doc/trunk/design/syn/S03.pod == --- doc/trunk/design/syn/S03.pod(original) +++ doc/trunk/design/syn/S03.podTue Oct 10 16:55:33 2006 @@ -770,6 +770,15 @@ $left «*» $right +[Note: if you are worried about Perl getting confused by something like this: + +foo «*» + +then you shouldn't worry about it, because unlike previous versions, +Perl 6 never guesses whether the next thing is a term or operator. +In this case it is always expecting a term unless Cfoo is predeclared +to be a 0-ary sub.] + The upgrade never happens on the blunt end of a hyper. If you write $bigger «*« $smaller
Re: class interface of roles
TSa wrote: TSa wrote: Note that the superclass interface of roles should be mostly inferred from the usage of next METHOD. As such it is a useful guidance for error reports in the class composition process. Actually 'next METHOD' doesn't catch all superclass interface issues. There is the simple case of calling e.g. accessor methods on super which should result in the requirement to provide them. So I still propose a super keyword that in roles means the object as seen from the uncomposed class. I think the word super is already to overloaded to be used for this purpose. Setting that aside for now... 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) I'd prefer to have a declarative mechanism for specifying such requirements. Firstly for self-documenting clarity, there's no need to scan for a super, and secondly because eval and super.$method_name would allow runtime failures. Some alternatives appeared elsewhere in this thread but it's unclear whether they would produce error at composition time or at runtime. (yada methods) The same applies to the next METHOD inference suggested: Note that the superclass interface of roles should be mostly inferred from the usage of next METHOD. 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. (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. $self.blah() is the later, $self.A::blah() or similar is likely to be the former.) Brad -- When one is not capable of true intelligence, it is good to consult with someone of good sense. -- Hagakure http://bereft.net/hagakure/
Re: class interface of roles
Brad Bowman wrote: TSa wrote: TSa wrote: Note that the superclass interface of roles should be mostly inferred from the usage of next METHOD. As such it is a useful guidance for error reports in the class composition process. Actually 'next METHOD' doesn't catch all superclass interface issues. There is the simple case of calling e.g. accessor methods on super which should result in the requirement to provide them. So I still propose a super keyword that in roles means the object as seen from the uncomposed class. What do you mean by uncomposed class? I think the word super is already to overloaded to be used for this purpose. Setting that aside for now... 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) I hope not; that's exactly what declaring an unimplemented method in a role is supposed to do. (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.) The same applies to the next METHOD inference suggested: Note that the superclass interface of roles should be mostly inferred from the usage of next METHOD. 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. (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. $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; 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. 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. -- Jonathan Dataweaver Lang
Re: class interface of roles
TSa wrote:
Jonathan Lang wrote:
TSa wrote:
Dispatch depends on a partial ordering of roles.
Could someone please give me an example to illustrate what is meant by
partial ordering here?
In addition to Matt Fowles explanation I would like to
give the following example lattice build from the roles
role A { has $.x }
role B { has $.y }
role C { has $.z }
There can be the four union combined roles A|B, A|C, B|C
and A|B|C which complete the type lattice:
Any={}
/ | \
/ | \
/|\
/ | \
/ | \
A={x} B={y} C={z}
| \/ \/ |
| \ / \ / |
| \/ \/ |
| /\ /\ |
| / \ / \ |
| /\ /\ |
A|B={x,y} A|C={x,z} B|C={y,z}
\ | /
\ | /
\|/
\ | /
\ | /
A|B|C={x,y,z}
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}
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? 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?
This lattice can then be used for type checks and specificity
comparisons in dispatch. BTW, such a lattice can be calculated lazily
from any set of packages. In pure MMD the selected target has to be
the most specific in all dispatch relevant positions.
By most specific, you'd mean closest to the top?
--
Jonathan Dataweaver Lang
