perl.perl6.language

perl.perl6.language http://www.nntp.perl.org/group/perl.perl6.language/ ... Copyright 1998-2008 perl.org Sun, 27 Jul 2008 08:10:49 +0000 ask@perl.org [svn:perl6-synopsis] r14570 - doc/trunk/design/syn by larry Author: larry Date: Sat Jul 26 21:04:50 2008 New Revision: 14570 Modified: doc/trunk/design/syn/S09.pod Log: Allow stackable subscript declarations and (-->type) Modified: doc/trunk/design/syn/S09.pod ============================================================================== --- doc/trunk/design/syn/S09.pod (original) +++ doc/trunk/design/syn/S09.pod Sat Jul 26 21:04:50 2008 @@ -713,6 +713,12 @@ # Same... @calendar[ **{July; 1..3}; *-3..*-1] +It is also possible to stack subscript declarations of various +types, including a final normal signature to specify named args +and return type: + + my @array[10]{'a'..'z'}(:$sparse --> MyType); + =head1 PDL support An array C<@array> can be tied to a PDL at declaration time: http://www.nntp.perl.org/group/perl.perl6.language/2008/07/msg29400.html Sat, 26 Jul 2008 21:04:58 +0000 [svn:perl6-synopsis] r14569 - doc/trunk/design/syn by larry Author: larry Date: Fri Jul 25 23:27:45 2008 New Revision: 14569 Modified: doc/trunk/design/syn/S02.pod Log: \d123 is now \c123 to avoid confusion with \d character class Modified: doc/trunk/design/syn/S02.pod ============================================================================== --- doc/trunk/design/syn/S02.pod (original) +++ doc/trunk/design/syn/S02.pod Fri Jul 25 23:27:45 2008 @@ -12,9 +12,9 @@ Maintainer: Larry Wall <larry@wall.org> Date: 10 Aug 2004 - Last Modified: 2 Apr 2008 + Last Modified: 25 Jul 2008 Number: 2 - Version: 132 + Version: 133 This document summarizes Apocalypse 2, which covers small-scale lexical items and typological issues. (These Synopses also contain @@ -2174,8 +2174,7 @@ Characters indexed by hex numbers can be interpolated into strings by introducing with C<"\x">, followed by either a bare hex number (C<"\x263a">) or a hex number in square brackets (C<"\x[263a]">). -Similarly, C<"\o12"> and C<"\o[12]"> interpolate octals, while -C<"\d1234"> and C<"\d[1234]"> interpolate decimals--but generally +Similarly, C<"\o12"> and C<"\o[12]"> interpolate octals--but generally you should be using hex in the world of Unicode. Multiple characters may be specified within any of the bracketed forms by separating the numbers with comma: C<"\x[41,42,43]">. You must use the bracketed @@ -2725,10 +2724,19 @@ [Note: none of the official Unicode character names contains comma.] +You may also put one or more decimal numbers inside the square brackets: + + "\c[13,10]" # CRLF + +Any single decimal number may omit the brackets: + + "\c8" # backspace + (Within a regex you may also use C<\C> to match a character that is not the specified character.) -If the character following C<\c> or C<\C> is not a left square bracket, +If the character following C<\c> or C<\C> is neither a left square bracket +nor a decimal digit, the single following character is turned into a control character by the usual trick of XORing the 64 bit. This allows C<\c@> for NULL and C<\c?> for DELETE, but note that the ESCAPE character may not be @@ -2736,6 +2744,7 @@ \e \c[ESCAPE] + \c27 \x1B \o33 http://www.nntp.perl.org/group/perl.perl6.language/2008/07/msg29399.html Fri, 25 Jul 2008 23:27:54 +0000 Perl6::Str on CPAN by Moritz Lenz Hi, today I released Perl6::Str to CPAN. It's a module for grapheme level string handling, and the methods are modeled closely after those of Perl 6. I cheated a bit in that I didn't implement codepoint and byte level semantics, since perl 5 supports them natively already. It lacks some features, some features aren't properly tested yet (like normalization), and some aren't planned at all (pack/unpack for example). It's also meant as an inspiration: grapheme level string handling doesn't have to be hard (it just becomes hard if you optimize the code ...) All comments are welcome. Cheers, Moritz -- Moritz Lenz http://moritz.faui2k3.org/ | http://perl-6.de/ http://www.nntp.perl.org/group/perl.perl6.language/2008/07/msg29398.html Mon, 21 Jul 2008 05:01:27 +0000 Re: meta_postfix:<*> by Aristotle Pagaltzis * Larry Wall <larry@wall.org> [2008-07-16 19:45]: > Speaking on behalf of the mere mortal, My Eyes Glaze Over. Yeah, this proposal seems to be slipping into APL territory. Regards, -- Aristotle Pagaltzis // <http://plasmasturm.org/> http://www.nntp.perl.org/group/perl.perl6.language/2008/07/msg29397.html Fri, 18 Jul 2008 01:00:11 +0000 [svn:perl6-synopsis] r14568 - doc/trunk/design/syn by larry Author: larry Date: Thu Jul 17 11:05:58 2008 New Revision: 14568 Modified: doc/trunk/design/syn/S09.pod Log: typo from DietCoke++ Modified: doc/trunk/design/syn/S09.pod ============================================================================== --- doc/trunk/design/syn/S09.pod (original) +++ doc/trunk/design/syn/S09.pod Thu Jul 17 11:05:58 2008 @@ -789,7 +789,7 @@ @x[0;1;42] @x[0..10; 1,0; 1..*:by(2)] -Built-in array types are expected succeed either way, even if +Built-in array types are expected to succeed either way, even if the cascaded subscript form must be implemented inefficiently by constructing temporary slice objects for later subscripts to use. (User-defined types may choose not to support the cascaded form, but http://www.nntp.perl.org/group/perl.perl6.language/2008/07/msg29396.html Thu, 17 Jul 2008 11:11:18 +0000 [svn:perl6-synopsis] r14567 - doc/trunk/design/syn by larry Author: larry Date: Thu Jul 17 10:57:24 2008 New Revision: 14567 Modified: doc/trunk/design/syn/S09.pod Log: Equivalence of cascaded and semicolon subscript forms suggested by nick++ Modified: doc/trunk/design/syn/S09.pod ============================================================================== --- doc/trunk/design/syn/S09.pod (original) +++ doc/trunk/design/syn/S09.pod Thu Jul 17 10:57:24 2008 @@ -12,9 +12,9 @@ Maintainer: Larry Wall <larry@wall.org> Date: 13 Sep 2004 - Last Modified: 27 May 2008 + Last Modified: 17 July 2008 Number: 9 - Version: 27 + Version: 28 =head1 Overview @@ -776,6 +776,27 @@ @x[0;1;42] +=head1 Cascaded subscripting of multidimensional arrays + +For all multidimensional array types, it is expected that cascaded subscripts: + + @x[0][1][42] + @x[0..10][1,0][1..*:by(2)] + +will either fail or produce the same results as the equivalent +semicolon subscripts: + + @x[0;1;42] + @x[0..10; 1,0; 1..*:by(2)] + +Built-in array types are expected succeed either way, even if +the cascaded subscript form must be implemented inefficiently by +constructing temporary slice objects for later subscripts to use. +(User-defined types may choose not to support the cascaded form, but +if so, they should fail rather than providing different semantics.) +As a consequence, for built-in types of declared shape, the appropriate +number of cascaded subscripts may always be optimized into the +semicolon form. =head1 The semicolon operator http://www.nntp.perl.org/group/perl.perl6.language/2008/07/msg29395.html Thu, 17 Jul 2008 11:01:07 +0000 Re: $foo[0][0] versus $foo[0;0] by Nicholas Clark On Wed, Jul 16, 2008 at 10:04:03AM -0700, Larry Wall wrote: > On Sun, Jul 13, 2008 at 02:17:10PM -0500, Adrian Kreher wrote: > : Hi, > : > : I'm reviewing the tests in S09, and the file > : t/spec/S02-builtin_data_types/multi_dimensional_array.t uses the [0][0] > : indexing format interchangeably with [0;0]. > : > : These two formats mean two different things, correct? The [0][0] form isn't > : mentioned much in the spec, nor is [0;0] or if they interact somehow. > > I think they should come out to meaning the same thing, though the > [0][0] form may be less efficient if it has to temporarily construct > a slice of the next dimension of the array. On the other hand, a > naïve implementation of the multidimensional subscripter might just do > the same thing internally for the semicolon, so it could be a wash. Would it be counter-productive to specify that the implementation is allowed to compile time optimise [$a][$b] etc to [$a;$b] etc? I'm assuming that it is allowed for the implementation of a multidmentional array to have different semantics for [$a][$b] and [$a;$b], but that seems to violate good sense, much like overloading a class in Perl 5 (or any other language) such that (++$a) and ($a + 1) are not the same. Nicholas Clark http://www.nntp.perl.org/group/perl.perl6.language/2008/07/msg29394.html Thu, 17 Jul 2008 08:03:33 +0000 [svn:perl6-synopsis] r14566 - doc/trunk/design/syn by larry Author: larry Date: Wed Jul 16 23:52:23 2008 New Revision: 14566 Modified: doc/trunk/design/syn/S04.pod Log: suggestion from moritz++ that POST blocks be allowed to see the return value Modified: doc/trunk/design/syn/S04.pod ============================================================================== --- doc/trunk/design/syn/S04.pod (original) +++ doc/trunk/design/syn/S04.pod Wed Jul 16 23:52:23 2008 @@ -14,7 +14,7 @@ Date: 19 Aug 2004 Last Modified: 16 July 2008 Number: 4 - Version: 67 + Version: 68 This document summarizes Apocalypse 4, which covers the block and statement syntax of Perl. @@ -1060,6 +1060,14 @@ before C<BEGIN>, C<CHECK>, or C<INIT>, since those are done at compile or process initialization time). +For blocks such as C<KEEP> and C<POST> that are run when exiting a +scope normally, the return value (if any) from that scope is available +as the current topic. (It is presented as a C<Capture> object.) +The topic of the outer block is still available as C<< OUTER::<$_> >>. +Whether the return value is modifiable may be a policy of the block +in question. In particular, the return value should not be modified +within a C<POST> block, but a C<LEAVE> block could be more liberal. + =head1 Statement parsing In this statement: http://www.nntp.perl.org/group/perl.perl6.language/2008/07/msg29393.html Wed, 16 Jul 2008 23:53:08 +0000 [svn:perl6-synopsis] r14565 - doc/trunk/design/syn by larry Author: larry Date: Wed Jul 16 23:26:04 2008 New Revision: 14565 Modified: doc/trunk/design/syn/S04.pod Log: clarification suggested by Bob Rogers++ Modified: doc/trunk/design/syn/S04.pod ============================================================================== --- doc/trunk/design/syn/S04.pod (original) +++ doc/trunk/design/syn/S04.pod Wed Jul 16 23:26:04 2008 @@ -1276,8 +1276,8 @@ symbol tables visible at compile time, this binds to the compile-time view of the lexical scopes. (At run-time, the initial run-time view of these scopes is copied from the compiler's view of them, so that -initializations carry over, for instance.) At run time, whenever such -a subroutine needs to be cloned, an additional C<:=> binding is done +initializations carry over, for instance.) At run time, when such +a subroutine is cloned, an additional C<:=> binding is done at clone time to the same symbol table entry that the original C<::=> was bound to. (The binding is not restored on exit from the current lexical scope; this C<:=> binding records the I<last> cloning, not http://www.nntp.perl.org/group/perl.perl6.language/2008/07/msg29392.html Wed, 16 Jul 2008 23:26:13 +0000 Re: Complex planes by Brandon S. Allbery KF8NH On 2008 Jul 16, at 18:48, Jon Lang wrote: > Moritz Lenz wrote: >> Principle of least surprise: >> >> Suppose sqrt(1) returns any(1, -1): >> if sqrt($x) < 0.5 { do something } >> >> I can see the big, fat WTF written in the face of programmer who >> tries >> to debug that code, and doesn't know about junctions. It just won't >> DTRT. > > This is closely related to my original point. In particular, if > you're unwilling to have sqrt return junctions of distinct values, you > don't really want to mess with junctions of a single complex value on > different planes, either. I suggest that the base library not bother with any of this; if someone wants it they can load a FullComplex module or something like that. -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allbery@kf8nh.com system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH http://www.nntp.perl.org/group/perl.perl6.language/2008/07/msg29391.html Wed, 16 Jul 2008 17:50:24 +0000 Re: Complex planes by Jon Lang Mark Biggar wrote: > Let's worry about getting principal values, branch cuts and handling signed zeros correct before dealing with the interaction of junctions and multi-valued complex functions. Indeed. > BTW, two good references on this that we might want to plagiarizer.....I mean borrow from are the Ada Refernece Manual and the Common LISP Reference Manual. Both go into great detail on this subject. I've just reviewed the Ada Reference Manual's take on this topic, and it did indeed address a few wrinkles that I overlooked. Basic rule: Complex.modulus >= 0; Complex.arg ~~ -pi .. pi. I'm not fully up on the lingo; so I'm going to invent some: Number $x is 'indefinite' if it is defined but has a value of Inf, NaN, or the like. It is 'definite' if it is defined and not indefinite. If either .re or .im is indefinite, the complex number is indefinite. If signed zeroes are used, then a definite complex number can always be assigned to one of the four quadrants. (In particular, if .im == -0, the number falls in one of the lower quadrants, and .arg == -pi or -0, depending on whether .re is negative or positive, respectively; if .im == +0, the number falls in one of the upper quadrants, and .arg == pi or +0. It is impossible for .arg to be indefinite if both .re and .im are definite: complex zeroes are "signed" by a definite .arg.) Conjecture: signed zeroes should be accompanied by signed infinities: as with zeroes, the "sign" of a complex infinity is a definite argument. Without signed zeroes, a definite complex number can be assigned to one of the four quadrants, to the positive or negative real number axes, to the positive or negative imaginary number axes, or to the origin. Under this scheme, some modifications and caveats need to be stated: .arg ~~ -pi ^.. pi. (So if the number falls on the negative real number line, .arg == pi.) If the number is zero, .arg is indefinite. If the number is indefinite, .arg is indefinite. If .re is indefinite, then .im is indefinite, and vice versa. The first paradigm has fewer special cases than the second one, but has several "redundancies" of the same nature as signed zeroes; the second paradigm more closely reflects what a mathematician would expect when seeing a complex number, but has several incongruities that might give a programmer headaches. -- Jonathan "Dataweaver" Lang http://www.nntp.perl.org/group/perl.perl6.language/2008/07/msg29390.html Wed, 16 Jul 2008 17:17:48 +0000 Re: Complex planes by Larry Wall It seems like my smiley went completely whoosh... Larry http://www.nntp.perl.org/group/perl.perl6.language/2008/07/msg29389.html Wed, 16 Jul 2008 16:03:30 +0000 [svn:perl6-synopsis] r14564 - doc/trunk/design/syn by larry Author: larry Date: Wed Jul 16 15:53:34 2008 New Revision: 14564 Modified: doc/trunk/design/syn/S04.pod Log: typo from Brandon++ Modified: doc/trunk/design/syn/S04.pod ============================================================================== --- doc/trunk/design/syn/S04.pod (original) +++ doc/trunk/design/syn/S04.pod Wed Jul 16 15:53:34 2008 @@ -1290,7 +1290,7 @@ do not need a compile-time C<::=> binding, but like global subs, they perform a C<:=> binding to the lexical symbol at clone time (again, conceptually at the entry to the outer lexical scope, but -possible deferred.) +possibly deferred.) sub foo { # conceptual cloning happens to both blocks below http://www.nntp.perl.org/group/perl.perl6.language/2008/07/msg29388.html Wed, 16 Jul 2008 15:53:42 +0000 Re: [svn:perl6-synopsis] r14563 - doc/trunk/design/syn by Brandon S. Allbery KF8NH Minor typo: On 2008 Jul 16, at 15:56, larry@cvs.perl.org wrote: > +(again, conceptually at the entry to the outer lexical scope, but > +possible deferred.) > > sub foo { "possibly" -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allbery@kf8nh.com system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH http://www.nntp.perl.org/group/perl.perl6.language/2008/07/msg29387.html Wed, 16 Jul 2008 15:50:17 +0000 Re: Complex planes by Jon Lang Moritz Lenz wrote: > If the programmer errs on what he thinks is in a variable, it'll always > be a bug. Yes; but some bugs are easier to make, and harder to catch, than others. > Principle of least surprise: > > Suppose sqrt(1) returns any(1, -1): > if sqrt($x) < 0.5 { do something } > > I can see the big, fat WTF written in the face of programmer who tries > to debug that code, and doesn't know about junctions. It just won't DTRT. This is closely related to my original point. In particular, if you're unwilling to have sqrt return junctions of distinct values, you don't really want to mess with junctions of a single complex value on different planes, either. >>>> And even then, I'm concerned that it might very quickly get out of >>>> hand. Consider: >>>> >>>> pow(1, 1/pi() ) :any - 1 >>>> >>>> (I think I got that right...) >>> >>> Not quite. Afaict the only functions that might return a junction are >>> Complex.angle and Complex.log. >> >> Why is that? > > As I pointed out above it's insane to return a junction of logically > distinct values. It's only insane if the programmer isn't expecting it - which goes back to my first point of making sure that the programmer explicitly asked for it before giving it to him. > It might even be insane to do it for Complex.log: Agreed: if you are uncomfortable with sqrt(1) returning a junction of distinct values, then Complex.log should likewise not return a junction of distinct values. > I think that I don't have to comment on the rest of the mail to make > clear that Larry's proposal, although being quite interesting, is a very > bad idea to actually implement (and very hard to implement as well) > (unless somebody comes to its rescue with a really clever idea on how to > resolve all these weirdnesses). Well... yes and no. Remember, I started off by recommending against Larry's proposal. I haven't changed my mind, although I think that it's worth exploring whether or not an alternate treatment of complex numbers is doable. -- Jonathan "Dataweaver" Lang http://www.nntp.perl.org/group/perl.perl6.language/2008/07/msg29386.html Wed, 16 Jul 2008 15:48:58 +0000 Re: Complex planes by mark.a.biggar Let's worry about getting principal values, branch cuts and handling signed zeros correct before dealing with the interaction of junctions and multi-valued complex functions. -- Mark Biggar mark@biggar.org mark.a.biggar@comcast.net mbiggar@paypal.com http://www.nntp.perl.org/group/perl.perl6.language/2008/07/msg29385.html Wed, 16 Jul 2008 15:23:59 +0000 Re: Complex planes by Moritz Lenz Jon Lang wrote: > Moritz Lenz wrote: >> Jon Lang wrote: >>> By the principle of least surprise, I'd recommend against this. Most >>> programmers, when they see 'sqrt(1)', will expect a return value of 1, >> >> And that's what they get unless they write it as sqrt(1 + 0i). > > I suppose that you _could_ use the programmer's choice of whether or > not to use complex numbers in the argument list as the indicator of > whether to return one answer or a junction of them. Of course, this > could lead to subtle bugs where the programmer assigns a complex value > to $x and later takes the sqrt($x), but forgets that he assigned a > complex number earlier. This may or may not be sufficient grounds for > requiring an explicit declaration that you want junctions. If the programmer errs on what he thinks is in a variable, it'll always be a bug. >>> and won't want to jump through the hurdles involved in picking '1' out >>> of 'any(1, -1)'. >> >> 1 and -1 aren't just separated by a complex plane, they are really >> distinct numbers > > True enough. I fail to see how that invalidates my point, though: if > you're going to mess with multiple complex planes, why wouldn't you > also address the issue of distinct numbers as well? Principle of least surprise: Suppose sqrt(1) returns any(1, -1): if sqrt($x) < 0.5 { do something } I can see the big, fat WTF written in the face of programmer who tries to debug that code, and doesn't know about junctions. It just won't DTRT. > The latter issue > is intimately connected to the former, as I demonstrate below. > >>> And even then, I'm concerned that it might very quickly get out of >>> hand. Consider: >>> >>> pow(1, 1/pi() ) :any - 1 >>> >>> (I think I got that right...) >> >> Not quite. Afaict the only functions that might return a junction are >> Complex.angle and Complex.log. > > Why is that? As I pointed out above it's insane to return a junction of logically distinct values. It might even be insane to do it for Complex.log: my $a = (Num::e * 1i).log.angle; What do you expect $a to be? Let's see, 1i can be written as exp(1i*(1/2 + 2 *$k) * pi), for Int $k. So log(Nom::e * 1i) would 1 + any(..., -1.5 * pi, 0.5 * pi, 2.5 * pi, 4.5*pi)*1i if you imagine this, all these values have re = 1, and lie on a straight line. So their angle are discrete (but not dense) values between -pi and +pi. There' no way you can represent that in finite space without a fair bit of algebra, something we don't want to burden on our implementors. And somehow I also don't think that meets the "principle of least surprise" criterion. I think that I don't have to comment on the rest of the mail to make clear that Larry's proposal, although being quite interesting, is a very bad idea to actually implement (and very hard to implement as well) (unless somebody comes to its rescue with a really clever idea on how to resolve all these weirdnesses). Cheers, Moritz -- Moritz Lenz http://moritz.faui2k3.org/ | http://perl-6.de/ http://www.nntp.perl.org/group/perl.perl6.language/2008/07/msg29384.html Wed, 16 Jul 2008 15:05:53 +0000 Re: Complex planes by Jon Lang Moritz Lenz wrote: > Jon Lang wrote: >> By the principle of least surprise, I'd recommend against this. Most >> programmers, when they see 'sqrt(1)', will expect a return value of 1, > > And that's what they get unless they write it as sqrt(1 + 0i). I suppose that you _could_ use the programmer's choice of whether or not to use complex numbers in the argument list as the indicator of whether to return one answer or a junction of them. Of course, this could lead to subtle bugs where the programmer assigns a complex value to $x and later takes the sqrt($x), but forgets that he assigned a complex number earlier. This may or may not be sufficient grounds for requiring an explicit declaration that you want junctions. >> and won't want to jump through the hurdles involved in picking '1' out >> of 'any(1, -1)'. > > 1 and -1 aren't just separated by a complex plane, they are really > distinct numbers True enough. I fail to see how that invalidates my point, though: if you're going to mess with multiple complex planes, why wouldn't you also address the issue of distinct numbers as well? The latter issue is intimately connected to the former, as I demonstrate below. >> And even then, I'm concerned that it might very quickly get out of >> hand. Consider: >> >> pow(1, 1/pi() ) :any - 1 >> >> (I think I got that right...) > > Not quite. Afaict the only functions that might return a junction are > Complex.angle and Complex.log. Why is that? Complex numbers can exist on multiple complex planes even if you don't explicitly look at the angle. One example of this phenomenon in action takes the form of a 'proof' that 1 == -1: 1 == sqrt(1) == sqrt(-1 * -1) == sqrt(-1) * sqrt(-1) == i * i == -1 #< Assumes complex numbers throughout. > The equality between the first and second steps means that the 1 inside the sqrt can only have an angle that is a multiple of 4pi. Because of this, the -1's that appear in the third step cannot exist on the same complex plane with each other: e.g., if the first one has an angle of pi, the second has to have an angle of -pi, 3pi, 7pi, 11pi, ... As a result of this, the signs of the sqrts in the fourth step must be opposed: if the first sqrt(-1) returns i, the second sqrt(-1) must return -i, and vice versa. That means that there's a negative term missing in the fifth step, which would cancel out the negative term that appears in the final step. At the very least, we need to add infix:<**> and all related functions (e.g., sqrt) to the list of functions that might return a junction. And when and if Perl 6 adds constraint programming to its repertoire, it will have to be smart enough to properly constrain complex planes as well as complex values. -- Bringing this back down a bit closer to Earth: if you supply a complex number using rectilinear coordinates, a case could be made that you've provided insufficient information, and that the complex number ought to be stored as a junction of all of the different complex plane representations for that otherwise-distinct value. If you supply a complex number using polar coordinates, you have been able to supply the choice of complex plane as well as a distinct value; so only one representation should be stored. That is: (1 + 0 * i).angle == any (0, 2 * pi, 4 * pi, ...); exp(0 * i).angle == 0; exp(2 * pi * i).angle == 2 * pi; So: (1 + 0 * i) == any (exp(0), exp(2 * pi * i), exp(4 * pi * i), ...); Extending this further: exp($C) effectively reinterprets a complex number's rectilinear coordinates as polar coordinates, and log($C) does the inverse. So as long as $C contains a single value, exp($C) should always return a complex number that exists on a single complex plane, established by $C's imaginary component; conversely, log($C) ought to return a complex value that is represented on every possible complex plane, since neither the angle nor the magnitude of $C provides enough information to determine which plane to use. Of course, there may be (and probably are) technical difficulties that make this unworkable. >> Since pi is an irrational number, there are infinitely many distinct >> results to raising 1 to the power of 1/pi. > > No. exp($x) is a single, well-defined value. True, as long as $x is a single, well-defined value. But I wasn't talking about exp($x); I was talking about pow($x, $y), $x ** $y, sqrt($x), and so on. Just as: sqrt(1 + 0 * i) == sqrt(any(exp(0), exp(2 * pi * i), exp(4 * pi * i), ...)) == any(exp(0), exp(pi * i), exp(2 * pi * i), ...) it is also the case that: (1 + 0 * i) ** pi == any(exp(0), exp(2 * pi * i), exp(4 * pi * i), ...) ** pi == any(exp(0), exp(2 * pi * pi * i), exp(4 * pi * pi * i), ...) And all of those answers are distinct values. > But you do have a point that we can't really use infinite junctions > unless we can ensure that we can do all sorts of arithmetics with it > without losing laziness. And I don't think we can prove that (but I > might give it it shot if I have some spare time) Just noting that we're not totally in disagreement. :P -- Jonathan "Dataweaver" Lang http://www.nntp.perl.org/group/perl.perl6.language/2008/07/msg29383.html Wed, 16 Jul 2008 14:17:47 +0000 [svn:perl6-synopsis] r14563 - doc/trunk/design/syn by larry Author: larry Date: Wed Jul 16 12:56:34 2008 New Revision: 14563 Modified: doc/trunk/design/syn/S04.pod Log: [S04] another whack at defining consistent closure semantics Modified: doc/trunk/design/syn/S04.pod ============================================================================== --- doc/trunk/design/syn/S04.pod (original) +++ doc/trunk/design/syn/S04.pod Wed Jul 16 12:56:34 2008 @@ -12,9 +12,9 @@ Maintainer: Larry Wall <larry@wall.org> Date: 19 Aug 2004 - Last Modified: 12 July 2008 + Last Modified: 16 July 2008 Number: 4 - Version: 66 + Version: 67 This document summarizes Apocalypse 4, which covers the block and statement syntax of Perl. @@ -1253,27 +1253,64 @@ is free to turn unreferenced closures into mere blocks of code. It is also free to turn referenced closures into mere anonymous subroutines if the block does not refer to any external lexicals that -should themselves be cloned. In particular, named subroutines in any -scope do not consider themselves closures unless you take a reference -to them. So +should themselves be cloned. (When we say "clone", we mean the way +the system takes a snapshot of the routine's lexical scope and binds +it to the current instance of the routine so that if you ever use +the current reference to the routine, it gets the current snapshot +of its world in terms of the lexical symbols that are visible to it.) + +All remaining blocks are conceptually cloned into closures as soon +as the lexical scope containing them is entered. (This may be done +lazily as long as consistent semantics are preserved, so a block +that is never executed and never has a reference taken can avoid +cloning altogether. Execution or reference taking forces cloning +in this case--references are not allowed to be lazily cloned, since +no guarantee can be made that the scope needed for cloning will +remain in existence over the life of the reference.) + +In particular, named subroutines are a special problem when embedded in +a changing lexical scope (when they make reference to it). The binding +of such a definition to a name within a symbol table counts as taking +a reference, so at compile time there is an initial C<::=> binding +to the symbol table entry in question. For "global" bindings to +symbol tables visible at compile time, this binds to the compile-time +view of the lexical scopes. (At run-time, the initial run-time view +of these scopes is copied from the compiler's view of them, so that +initializations carry over, for instance.) At run time, whenever such +a subroutine needs to be cloned, an additional C<:=> binding is done +at clone time to the same symbol table entry that the original C<::=> +was bound to. (The binding is not restored on exit from the current +lexical scope; this C<:=> binding records the I<last> cloning, not +the currently in-use cloning, so any use of the global reference must +take into consideration that it is functioning only as a cache of the +most recent cloning, not as a surrogate for the current lexical scope.) + +Lexical names do not share this problem, since the symbol goes out +of scope synchronously with its usage. Unlike global subs, they +do not need a compile-time C<::=> binding, but like global subs, +they perform a C<:=> binding to the lexical symbol at clone time +(again, conceptually at the entry to the outer lexical scope, but +possible deferred.) sub foo { + # conceptual cloning happens to both blocks below my $x = 1; - my sub bar { print $x } # not cloned yet - my &baz = { bar(); print $x }; # cloned immediately - my $code = &bar; # now bar is cloned + my sub bar { print $x } # already conceptualy cloned, but can be lazily deferred + my &baz := { bar(); print $x }; # block is cloned immediately, forcing cloning of bar + my $code = &bar; # this would also force bar to be cloned return &baz; } -When we say "clone", we mean the way the system takes a snapshot of the -routine's lexical scope and binds it to the current instance of the routine -so that if you ever use the current reference to the routine, it gets -the current snapshot of its world, lexically speaking. (When we say that -named subroutines do not consider themselves closures, this is a bit of a -fib, since we must, in fact, take a reference to the subroutine in order to -store it into the symbol table! But this operation happens at compile time -so the lexical scopes in view are just the initial prototype lexical scopes -visible to the compiler.) +In particular, blocks of inline control flow need not be cloned until +called. [Note: this is currently a potential problem for user-defined +constructs, since you have to take references to blocks to pass them +to whatever is managing the control flow. Perhaps the laziness can +be deferred through Captures to binding time, so a slurpy of block +refs doesn't clone them all prematurely. On the other hand, this +either means the Capture must be smart enough to keep track of the +lexical scope it came from so that it can pass the info to the cloner, +or it means that we need some special fat not-cloned-yet references +that can carry the info lazily. Neither approach is pretty.] Some closures produce C<Code> objects at compile time that cannot be cloned, because they're not attached to any runtime code that can http://www.nntp.perl.org/group/perl.perl6.language/2008/07/msg29382.html Wed, 16 Jul 2008 12:56:45 +0000 Re: Complex planes by Moritz Lenz Jon Lang wrote: > Larry Wall wrote: >> On Tue, Jul 15, 2008 at 03:30:24PM +0200, Moritz Lenz wrote: >> : Today bacek++ implement complex logarithms in rakudo, and one of the >> : tests failed because it assumed the result to be on a different complex >> : plane. (log(-1i) returned 0- 1.5708i, while 0 + 3/2*1i was expected). >> : >> : Should we standardize on one complex plane (for example -pi <= $c.angle >> : < pi like Complex.angle does)? Or simply fix the test to be agnostic to >> : complex planes? >> >> Standardizing on one complex plane is the normal solution, though >> this being Perl 6, there's probably a better solution using infinite >> Junctions if we can assume them to be both sufficiently lazy and >> sufficiently intelligent... :) > > By the principle of least surprise, I'd recommend against this. Most > programmers, when they see 'sqrt(1)', will expect a return value of 1, And that's what they get unless they write it as sqrt(1 + 0i). > and won't want to jump through the hurdles involved in picking '1' out > of 'any(1, -1)'. 1 and -1 aren't just separated by a complex plain, they are really distinct numbers > That said, I'm not necessarily opposed to these > functions including something like an ':any' or ':all' adverb that > causes them to return a junction of all possible answers; but this > should be something that you have to explicitly ask for. > > And even then, I'm concerned that it might very quickly get out of > hand. Consider: > > pow(1, 1/pi() ) :any - 1 > > (I think I got that right...) Not quite. Afaict the only functions that might return a junction are Complex.angle and Complex.log. But having $compl.angle > pi always yield True would be quite weird ;-) > Since pi is an irrational number, there are infinitely many distinct > results to raising 1 to the power of 1/pi. No. exp($x) is a single, well-defined value. > (All but one of them are > complex numbers, and all of them have a magnitude of 1, differing only > in their angles.) Thus, pow(1, 1/pi() ) :any would have to return a > junction of an indefinitely long lazy list. Now subtract 1 from that > junction. Do you have to flatten the list in order to do so, > subtracting one from each item in the list? Obviously we'd have to avoid that if there's any infinite list/junction involved somewhere ;-) But you do have a point that we can't really use infinite junctions unless we can ensure that we can do all sorts of arithmetics with it without loosing lazyness. And I don't think we can prove that (but I might give it it shot if I have some spare time) > Or is there a reasonable > way to modify the list generator to incorporate the subtraction? > > Or how about: > > sqrt(1):any + sqrt(1):any > > -- > > In any case, there's the matter of what to do when you only want one > answer, and not a junction of them. IMHO, we should standardize the > angles on '-pi ^.. pi'. My reasoning is as follows: if the imaginary > component is positive, the angle should be positive; if the imaginary > component is negative, the angle should be negative. If the imaginary > component is zero and the real component is not negative, the angle > should be zero. And the square root of -1 should be i, not -i; so if > the imaginary component is zero and the real component is negative, > the angle should be positive, not negative. > -- Moritz Lenz http://moritz.faui2k3.org/ | http://perl-6.de/ http://www.nntp.perl.org/group/perl.perl6.language/2008/07/msg29381.html Wed, 16 Jul 2008 12:33:01 +0000 Re: Complex planes by Jon Lang Larry Wall wrote: > On Tue, Jul 15, 2008 at 03:30:24PM +0200, Moritz Lenz wrote: > : Today bacek++ implement complex logarithms in rakudo, and one of the > : tests failed because it assumed the result to be on a different complex > : plane. (log(-1i) returned 0- 1.5708i, while 0 + 3/2*1i was expected). > : > : Should we standardize on one complex plane (for example -pi <= $c.angle > : < pi like Complex.angle does)? Or simply fix the test to be agnostic to > : complex planes? > > Standardizing on one complex plane is the normal solution, though > this being Perl 6, there's probably a better solution using infinite > Junctions if we can assume them to be both sufficiently lazy and > sufficiently intelligent... :) By the principle of least surprise, I'd recommend against this. Most programmers, when they see 'sqrt(1)', will expect a return value of 1, and won't want to jump through the hurdles involved in picking '1' out of 'any(1, -1)'. That said, I'm not necessarily opposed to these functions including something like an ':any' or ':all' adverb that causes them to return a junction of all possible answers; but this should be something that you have to explicitly ask for. And even then, I'm concerned that it might very quickly get out of hand. Consider: pow(1, 1/pi() ) :any - 1 (I think I got that right...) Since pi is an irrational number, there are infinitely many distinct results to raising 1 to the power of 1/pi. (All but one of them are complex numbers, and all of them have a magnitude of 1, differing only in their angles.) Thus, pow(1, 1/pi() ) :any would have to return a junction of an indefinitely long lazy list. Now subtract 1 from that junction. Do you have to flatten the list in order to do so, subtracting one from each item in the list? Or is there a reasonable way to modify the list generator to incorporate the subtraction? Or how about: sqrt(1):any + sqrt(1):any -- In any case, there's the matter of what to do when you only want one answer, and not a junction of them. IMHO, we should standardize the angles on '-pi ^.. pi'. My reasoning is as follows: if the imaginary component is positive, the angle should be positive; if the imaginary component is negative, the angle should be negative. If the imaginary component is zero and the real component is not negative, the angle should be zero. And the square root of -1 should be i, not -i; so if the imaginary component is zero and the real component is negative, the angle should be positive, not negative. -- Jonathan "Dataweaver" Lang http://www.nntp.perl.org/group/perl.perl6.language/2008/07/msg29380.html Wed, 16 Jul 2008 12:15:49 +0000 Re: meta_postfix:<*> by Larry Wall On Sun, Jul 13, 2008 at 12:46:30PM +0200, TSa (Thomas Sandlaß) wrote: : HaloO, : : I know that the hot phase of the operator discussions are over. : But here's a little orthogonalizing idea from my side. The observation : is that * can be regarded as repeated addition: 5 * 3 == 5 + 5 + 5 : and ** as repeated multiplication. Now imagine having a meta_postfix:<*> : that gives +* as multiplication (perhaps abbreviated as *) and ** as : (integer) exponentiation. We can then continue with replication as ~* : for strings and ,* for lists thus freeing x and xx as some generic : multiplication operators. I think this is not going to fly from the standpoint of keeping common operators visually distinct. Also, how will you parse 1..* and such? (Another consideration is that every time you add another metaoperator you're potentially exploding the number of operators that the longest token matcher needs to deal with, though STD currently cheats on this.) : The meta * also is useful e.g. as (1,2) Z* 3 === (1,1,1),(2,2,2). Also : when we apply it to unary postfix as well: $x++* 3 === $x++.++.++ which : is useful when $x is of some class with overloaded ++ where the single : steps are important. The meta postfix * could also be stacked and tetration : falls out naturally as ***. Speaking on behalf of the mere mortal, My Eyes Glaze Over. Speaking as a parser writer, you're confusing the parser with a metaoperator that changes expectation of term vs infix. Sepaking as a programmer, $x++.++.++ won't do what you seem to think it does. : With + as the default case for meta_postfix:<*> we win the advantage that : we have +* and * as multiplication operators with the latter being a special : form of the former. But for Vectors +* would automatically yield the scalar : multiplication infix:<+*>:(Vector,Num) when infix:<+>:(Vector,Vector) is : defined as expected. You can, of course, do anything you like with your own copy, but the standard reserves most of Unicode as the playground of mathematicians, so please leave our poor little * alone. :) Larry http://www.nntp.perl.org/group/perl.perl6.language/2008/07/msg29379.html Wed, 16 Jul 2008 10:43:44 +0000 Re: Complex planes by Larry Wall On Tue, Jul 15, 2008 at 03:30:24PM +0200, Moritz Lenz wrote: : Today bacek++ implement complex logarithms in rakudo, and one of the : tests failed because it assumed the result to be on a different complex : plane. (log(-1i) returned 0- 1.5708i, while 0 + 3/2*1i was expected). : : Should we standardize on one complex plane (for example -pi <= $c.angle : < pi like Complex.angle does)? Or simply fix the test to be agnostic to : complex planes? Standardizing on one complex plane is the normal solution, though this being Perl 6, there's probably a better solution using infinite Junctions if we can assume them to be both sufficiently lazy and sufficiently intelligent... :) Larry http://www.nntp.perl.org/group/perl.perl6.language/2008/07/msg29378.html Wed, 16 Jul 2008 10:10:29 +0000 Re: $foo[0][0] versus $foo[0;0] by Larry Wall On Sun, Jul 13, 2008 at 02:17:10PM -0500, Adrian Kreher wrote: : Hi, : : I'm reviewing the tests in S09, and the file : t/spec/S02-builtin_data_types/multi_dimensional_array.t uses the [0][0] : indexing format interchangeably with [0;0]. : : These two formats mean two different things, correct? The [0][0] form isn't : mentioned much in the spec, nor is [0;0] or if they interact somehow. I think they should come out to meaning the same thing, though the [0][0] form may be less efficient if it has to temporarily construct a slice of the next dimension of the array. On the other hand, a naïve implementation of the multidimensional subscripter might just do the same thing internally for the semicolon, so it could be a wash. Larry http://www.nntp.perl.org/group/perl.perl6.language/2008/07/msg29377.html Wed, 16 Jul 2008 10:04:34 +0000 Re: Parrot 0.6.4 by François Perrad Bernhard Schmalhofer a écrit : > Hi, > > on behalf of the Parrot team, I'm proud to announce the release of > Parrot 0.6.4 > "St. Vincent Amazon." > As usual, the Windows setup is available on http://parrotwin32.sourceforge.net/ François. > Parrot 0.6.4 is available via CPAN, or follow the download > instructions at http://parrotcode.org/source.html. For those who would > like to develop on > Parrot, or help develop Parrot itself, we recommend using Subversion on > the source code repository to get the latest and best Parrot code. > > Parrot 0.6.4 News: > - Documentation > + removed a lot of old information from the FAQ > + improved function level documentation > - Configuration > + removed the configuration item 'has_gnu_m4' > + refactored ICU-detection > - Languages > + ChitChat > - improved the Smalltalk implementation > + Pipp > - renamed Plumhead to Pipp > - support for a lot of builtin functions. > - Pipp now uses PHP specific data types. > - converted from PCT with TGE to PCT with NQP actions > - improvements in the PCT variant by using optok parsing > - start of object support > + pir > - simple assignments work > + json > - added a PCT-based implementation of JSON parsing > + lolcode > - improved handling of symbols > - added support for block handling > - added support for globals > + Lua > - more tests > + Rakudo > - updated Range implementation > - added enums > - added generic type declarations (::T) > - added runtime mixing of roles with 'does' and 'but' > - added generic type declarations > - fixed handling of implicit lexicals ($_, $!, and $/) > - fixed implicit method calls on $_ > - improved complex math builtins, added Complex > - moved many builtins to class Any > - declaration of lists of variables now work > - improved test infrastructure > - 910 additional passing spec tests since last release > - more convergence with STD.pm grammar > - added named 0-ary parsing and ops > - Compilers > + PCT: > - allowed subroutine and method names to be a PAST tree that produces > the name > - Improved lexical handling > - Tools > + pbc_disassemble renamed from disassemble > - Implementation > + allowed .macro_const in PIR > + added the flag :lexid(...) for subroutines > + made multiple dispatch work for sub types > + fixed garbage collection bug related to the metadata attached to a > PMC_EXT structure > + added a warning when using deprecated opcodes > + simplified the stacks implementation > + fixed C++ build > + improved closure and lexical support > + improved IMCC register allocator > + added cache for all runtime-constant strings, reducing memory usage > - Miscellaneous > + improved OpenGL/GLU/GLUT bindings > + added a standard profile for Perl::Critic coding standard testing > + added support for smoke testing with Smolder > + enabled use of Test::Harness 3.0 if available, but don't require it > for 'make test' > + added the executable 'parrot_config' to query Parrot configuration > > > Many thanks to all our contributors for making this possible, and our > sponsors > for supporting this project. Our next scheduled release is August 19th > 2008. > > Enjoy! > > > > > http://www.nntp.perl.org/group/perl.perl6.language/2008/07/msg29376.html Wed, 16 Jul 2008 05:19:24 +0000 Re: meta_postfix:<*> by Jon Lang Kealey, Martin, wrote: > Nice idea; introduces one particular ambiguity though: would > > $m ** $n > > then be > > pow($m, $n) > > or > > pow($n, $m) > > ? Neither. As with the reducing meta-operator, you would need to have the ability to define an operator that takes precedence over a meta'd operator, for those cases where a particular combination of symbols has a meaning that is either more broad or incompatible with what the replication meta would supply. Conveniently, '**' is one such operator. To whit: In '$count *op $value' and '$value op* $count', $count must be an unsigned integer of some sort: it's nonsense to replicate an operation half of a time, or negative two times, or i times. However, '$base ** $power' places no such restrictions on either $base or $power; thus, it needs to be separately defined. The fact that its behavior coincides with a replicator appended to a multiplication operator when the power is an unsigned integer is merely a convenient coincidence as far as the compiler is concerned. That said, there _is_ still some potential ambiguity if you have operators that begin or end with '*'. For instance: let's say that you want to apply replication to exponentials: does '$m *** $n' mean '$m repetitions of $n ** $n', or does it mean '$m ** $m, repeated $n times'? The longest-token rule resolves this dilemma in favor of the latter. -- Jonathan "Dataweaver" Lang http://www.nntp.perl.org/group/perl.perl6.language/2008/07/msg29375.html Tue, 15 Jul 2008 20:45:51 +0000 Re: meta_postfix:<*> by Jon Lang Dave Whipp wrote: > Jon Lang wrote: > >> So you're suggesting that >> >> A op* n >> >> should map to >> >> [op] A xx n >> > > I don't think that that mapping works for Thomas' proposal of a repetition > count on post-increment operator. I.e. > > $a ++* 3 > > is not the same as > > [++] $a xx 3 > > (which I think is a syntax error) It is. > Also, he's suggesting getting rid of the "xx" operator, and replacing it > with ",*" -- I'm sure I could get used to that > Currently, it's being assumed that the repetition meta-operator will be appended to the operator, followed by the repetition count: $value op* $count This makes it difficult to apply the replication meta-operator to a prefix operator. However, a second option could be provided, where the meta-operator gets prepended: $count *op $value So: 5 *, $n === $n ,* 5 === $n, $n, $n, $n, $n $n ++* 5 === (((($n++)++)++)++)++ 5 *++ $n === ++(++(++(++(++$n)))) And obviously the metaoperator is nonsensical when applied to a binary operator with different types of values on its left and right sides. As with other meta-operators, it should be possible to explicitly define a symbol that would otherwise be interpreted as a meta'd operator, because of efficiency; because the operator in question has capabilities above and beyond what the meta-operator would indicate; or because the operator in question doesn't bear any resemblance to the replicated use of a shorter operator. In particular, ** would be overloaded in this manner: to make reasonable sense, the count of a repetition meta-operator must be an unsigned integer of some sort, whereas exponents can be any type of number. Heck, they don't even have to be real. -- Jonathan "Dataweaver" Lang http://www.nntp.perl.org/group/perl.perl6.language/2008/07/msg29374.html Tue, 15 Jul 2008 16:56:25 +0000 Re: meta_postfix:<*> by Dave Whipp Jon Lang wrote: > So you're suggesting that > > A op* n > > should map to > > [op] A xx n I don't think that that mapping works for Thomas' proposal of a repetition count on post-increment operator. I.e. $a ++* 3 is not the same as [++] $a xx 3 (which I think is a syntax error) and also not the same as $a++ * 3 Also, he's suggesting getting rid of the "xx" operator, and replacing it with ",*" -- I'm sure I could get used to that http://www.nntp.perl.org/group/perl.perl6.language/2008/07/msg29373.html Tue, 15 Jul 2008 16:20:03 +0000 Parrot 0.6.4 by Bernhard Schmalhofer Hi, on behalf of the Parrot team, I'm proud to announce the release of Parrot 0.6.4 "St. Vincent Amazon." Parrot 0.6.4 is available via CPAN, or follow the download instructions at http://parrotcode.org/source.html. For those who would like to develop on Parrot, or help develop Parrot itself, we recommend using Subversion on the source code repository to get the latest and best Parrot code. Parrot 0.6.4 News: - Documentation + removed a lot of old information from the FAQ + improved function level documentation - Configuration + removed the configuration item 'has_gnu_m4' + refactored ICU-detection - Languages + ChitChat - improved the Smalltalk implementation + Pipp - renamed Plumhead to Pipp - support for a lot of builtin functions. - Pipp now uses PHP specific data types. - converted from PCT with TGE to PCT with NQP actions - improvements in the PCT variant by using optok parsing - start of object support + pir - simple assignments work + json - added a PCT-based implementation of JSON parsing + lolcode - improved handling of symbols - added support for block handling - added support for globals + Lua - more tests + Rakudo - updated Range implementation - added enums - added generic type declarations (::T) - added runtime mixing of roles with 'does' and 'but' - added generic type declarations - fixed handling of implicit lexicals ($_, $!, and $/) - fixed implicit method calls on $_ - improved complex math builtins, added Complex - moved many builtins to class Any - declaration of lists of variables now work - improved test infrastructure - 910 additional passing spec tests since last release - more convergence with STD.pm grammar - added named 0-ary parsing and ops - Compilers + PCT: - allowed subroutine and method names to be a PAST tree that produces the name - Improved lexical handling - Tools + pbc_disassemble renamed from disassemble - Implementation + allowed .macro_const in PIR + added the flag :lexid(...) for subroutines + made multiple dispatch work for sub types + fixed garbage collection bug related to the metadata attached to a PMC_EXT structure + added a warning when using deprecated opcodes + simplified the stacks implementation + fixed C++ build + improved closure and lexical support + improved IMCC register allocator + added cache for all runtime-constant strings, reducing memory usage - Miscellaneous + improved OpenGL/GLU/GLUT bindings + added a standard profile for Perl::Critic coding standard testing + added support for smoke testing with Smolder + enabled use of Test::Harness 3.0 if available, but don't require it for 'make test' + added the executable 'parrot_config' to query Parrot configuration Many thanks to all our contributors for making this possible, and our sponsors for supporting this project. Our next scheduled release is August 19th 2008. Enjoy! http://www.nntp.perl.org/group/perl.perl6.language/2008/07/msg29372.html Tue, 15 Jul 2008 07:51:39 +0000 Complex planes by Moritz Lenz Today bacek++ implement complex logarithms in rakudo, and one of the tests failed because it assumed the result to be on a different complex plane. (log(-1i) returned 0- 1.5708i, while 0 + 3/2*1i was expected). Should we standardize on one complex plane (for example -pi <= $c.angle < pi like Complex.angle does)? Or simply fix the test to be agnostic to complex planes? Cheers, Moritz -- Moritz Lenz http://moritz.faui2k3.org/ | http://perl-6.de/ http://www.nntp.perl.org/group/perl.perl6.language/2008/07/msg29371.html Tue, 15 Jul 2008 06:30:46 +0000 $foo[0][0] versus $foo[0;0] by Adrian Kreher Hi, I'm reviewing the tests in S09, and the file t/spec/S02-builtin_data_types/multi_dimensional_array.t uses the [0][0] indexing format interchangeably with [0;0]. These two formats mean two different things, correct? The [0][0] form isn't mentioned much in the spec, nor is [0;0] or if they interact somehow. Thanks, -- Adrian Kreher http://www.nntp.perl.org/group/perl.perl6.language/2008/07/msg29370.html Sun, 13 Jul 2008 12:17:27 +0000 Re: meta_postfix:<*> by Jon Lang So you're suggesting that A op* n should map to [op] A xx n ? -- Jonathan "Dataweaver" Lang http://www.nntp.perl.org/group/perl.perl6.language/2008/07/msg29369.html Sun, 13 Jul 2008 10:01:59 +0000 meta_postfix:<*> by TSa HaloO, I know that the hot phase of the operator discussions are over. But here's a little orthogonalizing idea from my side. The observation is that * can be regarded as repeated addition: 5 * 3 == 5 + 5 + 5 and ** as repeated multiplication. Now imagine having a meta_postfix:<*> that gives +* as multiplication (perhaps abbreviated as *) and ** as (integer) exponentiation. We can then continue with replication as ~* for strings and ,* for lists thus freeing x and xx as some generic multiplication operators. The meta * also is useful e.g. as (1,2) Z* 3 === (1,1,1),(2,2,2). Also when we apply it to unary postfix as well: $x++* 3 === $x++.++.++ which is useful when $x is of some class with overloaded ++ where the single steps are important. The meta postfix * could also be stacked and tetration falls out naturally as ***. With + as the default case for meta_postfix:<*> we win the advantage that we have +* and * as multiplication operators with the latter being a special form of the former. But for Vectors +* would automatically yield the scalar multiplication infix:<+*>:(Vector,Num) when infix:<+>:(Vector,Vector) is defined as expected. Regards, TSa. -- "The unavoidable price of reliability is simplicity" -- C.A.R. Hoare "Simplicity does not precede complexity, but follows it." -- A.J. Perlis 1 + 2 + 3 + 4 + ... = -1/12 -- Srinivasa Ramanujan http://www.nntp.perl.org/group/perl.perl6.language/2008/07/msg29368.html Sun, 13 Jul 2008 03:46:48 +0000 S04-related closure question by Patrick R. Michaud What would be the expected output from the following? my $a = foo(); my $b; { my $x = 1; sub get_x() { return $x; } sub foo() { return &get_x; } $b = foo(); } my $c = foo(); say "a: ", $a(); say "b: ", $b(); say "c: ", $c(); As a followup question, what about...? my @array; for 1..3 -> $x { sub get_x() { return $x; } push @array, &get_x; } for @array -> $f { say $f(); } Pm http://www.nntp.perl.org/group/perl.perl6.language/2008/07/msg29367.html Sat, 12 Jul 2008 19:52:42 +0000 Re: Question about .sort and .reduce by Larry Wall On Fri, Jul 11, 2008 at 09:01:09AM -0500, Patrick R. Michaud wrote: : I'm not entirely certain if any of the following : examples with adverbial blocks would also work. I'm guessing : they do, but could use confirmation. : : sort @a, :{ $^a <=> $^b }; : sort @a :{ $^a <=> $^b }; : sort :{ $^a <=> $^b }, @a; : @a.sort: :{ $^a <=> $^b }; I think they all work, but the second one is fragile and will break if you replace @a with an expression containing an operator that the adverb would attach itself to instead of to the sort, since adverbs in infix position always pick the most recent operator (that isn't hidden inside brackets or parens). Larry http://www.nntp.perl.org/group/perl.perl6.language/2008/07/msg29366.html Sat, 12 Jul 2008 11:19:35 +0000 Re: Question about .sort and .reduce by Larry Wall On Fri, Jul 11, 2008 at 03:27:26PM +0200, TSa wrote: > HaloO, > > Patrick R. Michaud wrote: >> S29 doesn't show a 'sort' method defined on block/closure >> invocants... should there be? > > I doubt that. And to my eyes it looks funny. Only real block > methods should be useful and since the class is mostly known > at parse time unapplicable methods should be a compile error. > > my &f = { $^a <=> $^b }.assuming($^a = 3); > > say f(3); # prints 0 > > Would that be valid? I mean the usuage of automatic variables > in the assuming method? No, that could not work, because $^a = 3 would be in an rvalue context and refer to the block around the entire statement as a different parameter. Setting a named parameter with .assuming must use named argument notation: my &f = { $^a <=> $^b }.assuming(:a(3)); Also, it may well be that f(3) will say Order::Same rather than 0. :) Larry http://www.nntp.perl.org/group/perl.perl6.language/2008/07/msg29365.html Sat, 12 Jul 2008 11:06:27 +0000 [svn:perl6-synopsis] r14562 - doc/trunk/design/syn by larry Author: larry Date: Sat Jul 12 10:50:57 2008 New Revision: 14562 Modified: doc/trunk/design/syn/S04.pod Log: [S04] small clarification to whether named subs are really closures Modified: doc/trunk/design/syn/S04.pod ============================================================================== --- doc/trunk/design/syn/S04.pod (original) +++ doc/trunk/design/syn/S04.pod Sat Jul 12 10:50:57 2008 @@ -12,9 +12,9 @@ Maintainer: Larry Wall <larry@wall.org> Date: 19 Aug 2004 - Last Modified: 2 Apr 2008 + Last Modified: 12 July 2008 Number: 4 - Version: 65 + Version: 66 This document summarizes Apocalypse 4, which covers the block and statement syntax of Perl. @@ -1268,7 +1268,12 @@ When we say "clone", we mean the way the system takes a snapshot of the routine's lexical scope and binds it to the current instance of the routine so that if you ever use the current reference to the routine, it gets -the current snapshot of its world, lexically speaking. +the current snapshot of its world, lexically speaking. (When we say that +named subroutines do not consider themselves closures, this is a bit of a +fib, since we must, in fact, take a reference to the subroutine in order to +store it into the symbol table! But this operation happens at compile time +so the lexical scopes in view are just the initial prototype lexical scopes +visible to the compiler.) Some closures produce C<Code> objects at compile time that cannot be cloned, because they're not attached to any runtime code that can http://www.nntp.perl.org/group/perl.perl6.language/2008/07/msg29364.html Sat, 12 Jul 2008 10:51:06 +0000 Re: Question about .sort and .reduce by Patrick R. Michaud On Fri, Jul 11, 2008 at 03:27:26PM +0200, TSa wrote: > >Note that we already have: > > > > my @s = sort { $^a <=> $^b }, @a; > > my @s = @a.sort { $^a <=> $^b }; > > Is that the adverbial block syntax? If not how > would it look? The adverbial block syntax would be: @a.sort:{ $^a <=> $^b }; sort(@a) :{ $^a <=> $^b }; I'm not entirely certain if any of the following examples with adverbial blocks would also work. I'm guessing they do, but could use confirmation. sort @a, :{ $^a <=> $^b }; sort @a :{ $^a <=> $^b }; sort :{ $^a <=> $^b }, @a; @a.sort: :{ $^a <=> $^b }; Pm http://www.nntp.perl.org/group/perl.perl6.language/2008/07/msg29363.html Fri, 11 Jul 2008 07:01:20 +0000 Re: Question about .sort and .reduce by TSa HaloO, Patrick R. Michaud wrote: > S29 doesn't show a 'sort' method defined on block/closure > invocants... should there be? I doubt that. And to my eyes it looks funny. Only real block methods should be useful and since the class is mostly known at parse time unapplicable methods should be a compile error. my &f = { $^a <=> $^b }.assuming($^a = 3); say f(3); # prints 0 Would that be valid? I mean the usuage of automatic variables in the assuming method? > Note that we already have: > > my @s = sort { $^a <=> $^b }, @a; > my @s = @a.sort { $^a <=> $^b }; Is that the adverbial block syntax? If not how would it look? my @s = sort @a :{ $^a <=> $^b }; Or with a comma after @a? Regards, TSa. -- "The unavoidable price of reliability is simplicity" -- C.A.R. Hoare "Simplicity does not precede complexity, but follows it." -- A.J. Perlis 1 + 2 + 3 + 4 + ... = -1/12 -- Srinivasa Ramanujan http://www.nntp.perl.org/group/perl.perl6.language/2008/07/msg29362.html Fri, 11 Jul 2008 06:27:41 +0000 Question about .sort and .reduce by Patrick R. Michaud t/spec/S29-list/sort.t has the following test: my @a = (2, 45, 6, 1, 3); my @e = (1, 2, 3, 6, 45); my @s = { $^a <=> $^b }.sort: @a; is(@s, @e, '... with closure as direct invocant'); S29 doesn't show a 'sort' method defined on block/closure invocants... should there be? Note that we already have: my @s = sort { $^a <=> $^b }, @a; my @s = @a.sort { $^a <=> $^b }; A similar question applies for .reduce in S29-list/reduce.t : is(({ $^a * $^b }.reduce: 1,2,3,4,5), 120, "basic reduce works (3)"); Thanks! Pm http://www.nntp.perl.org/group/perl.perl6.language/2008/07/msg29361.html Fri, 11 Jul 2008 06:00:32 +0000