Language Testing
hello, I'm trying to set up a test harness for languages/PIR I did the following: 1. added a file lib\Parrot\Test\PIR.pm (there are others, like Punie.pm). I changed this file a bit, so it uses pir.pbc as compiler (I copied the file from Punie.pm, and changed the compiler from punie.pbc to pir.pbc) 2. I added a file languages\PIR\t\harness containing: #! perl -w use Parrot::Test::Harness language = 'PIR'; 3. I added 1 test file sub.t Now, if I run it with a deliberate error in the test file, I see that: [...] # '.\parrot.exe C:\parrot\languages\PIR\t\sub_1.pir' failed with exit code 1 [...] which obviously means that languages\pir.pbc is not even used. In other words, it seems that this module PIR.pm is not used. I could not find docs on how to set this up. Help would greatly be appreciated. (and I could provide a patch after that for compiler FAQ, right below Languages explaining this) Thanks, Klaas-Jan
Re: Language Testing
I just tried this setup in my sandbox as well. Turns out you have an unfortunately named language, as language=PIR forces the usage of output_is(), as the author assumed PIR was reserved for internal testing. This will require either an update to lib/Parrot/Test.pm, or that you use a different language name for the language arg and module. I recommend the latter, e.g. PIR_PGE. You won't need to change the language DIR or the compiled .pbc you're using. Regards. On Jan 30, 2007, at 5:03 AM, Klaas-Jan Stol wrote: hello, I'm trying to set up a test harness for languages/PIR I did the following: 1. added a file lib\Parrot\Test\PIR.pm (there are others, like Punie.pm). I changed this file a bit, so it uses pir.pbc as compiler (I copied the file from Punie.pm, and changed the compiler from punie.pbc to pir.pbc) 2. I added a file languages\PIR\t\harness containing: #! perl -w use Parrot::Test::Harness language = 'PIR'; 3. I added 1 test file sub.t Now, if I run it with a deliberate error in the test file, I see that: [...] # '.\parrot.exe C:\parrot\languages\PIR\t\sub_1.pir' failed with exit code 1 [...] which obviously means that languages\pir.pbc is not even used. In other words, it seems that this module PIR.pm is not used. I could not find docs on how to set this up. Help would greatly be appreciated. (and I could provide a patch after that for compiler FAQ, right below Languages explaining this) Thanks, Klaas-Jan -- Will Coke Coleda [EMAIL PROTECTED]
Re: Language Testing
Thanks a bunch! It's working :-) kjs Will Coleda wrote: I just tried this setup in my sandbox as well. Turns out you have an unfortunately named language, as language=PIR forces the usage of output_is(), as the author assumed PIR was reserved for internal testing. This will require either an update to lib/Parrot/Test.pm, or that you use a different language name for the language arg and module. I recommend the latter, e.g. PIR_PGE. You won't need to change the language DIR or the compiled .pbc you're using. Regards. On Jan 30, 2007, at 5:03 AM, Klaas-Jan Stol wrote: hello, I'm trying to set up a test harness for languages/PIR I did the following: 1. added a file lib\Parrot\Test\PIR.pm (there are others, like Punie.pm). I changed this file a bit, so it uses pir.pbc as compiler (I copied the file from Punie.pm, and changed the compiler from punie.pbc to pir.pbc) 2. I added a file languages\PIR\t\harness containing: #! perl -w use Parrot::Test::Harness language = 'PIR'; 3. I added 1 test file sub.t Now, if I run it with a deliberate error in the test file, I see that: [...] # '.\parrot.exe C:\parrot\languages\PIR\t\sub_1.pir' failed with exit code 1 [...] which obviously means that languages\pir.pbc is not even used. In other words, it seems that this module PIR.pm is not used. I could not find docs on how to set this up. Help would greatly be appreciated. (and I could provide a patch after that for compiler FAQ, right below Languages explaining this) Thanks, Klaas-Jan -- Will Coke Coleda [EMAIL PROTECTED]
Re: Numeric Semantics
HaloO,
Luke Palmer wrote:
When do we do integer/rational math and when do we do floating point math?
Since we have now flooring semantics on modulus and division I wonder
how the coercion of nums to ints takes place. Does it also use floor?
E.g. is @array[-0.3] accessing the last element or is it truncating
to zero and indexing from the front?
Another integer issue is how the ++ and -- operators behave. Do they
coerce to int before the operation or do they keep nums as nums?
E.g.
my $x = 3.25;
$x++; # 4.25 or 4?
$x = -2.25;
$x--; # -3.25 or -4 or -3?
How are coercions handled when calling functions?
sub identity ( Int $i ) { return $i }
my Num $x = 3.25;
say indentity($x); # prints 3 or type error? Or even 3.25?
I'm opting for type error on the footing that Int : Num and
you can't allow a supertype where a subtype is expected.
BTW, are character positions integers or can we have fractional
characters on a higher unicode level that is a sequence of lower
level chars?
Regards, TSa.
--
Re: Numeric Semantics
Note: it would be good to break multiple questions into separate threads with different subjects for those of us who use threaded mail readers, so I will answer each of these with a different subject. Larry
Negative fraction subscripts
On Tue, Jan 30, 2007 at 06:02:59PM +0100, TSa wrote: : HaloO, : : Luke Palmer wrote: : When do we do integer/rational math and when do we do floating point math? : : Since we have now flooring semantics on modulus and division I wonder : how the coercion of nums to ints takes place. Does it also use floor? : E.g. is @array[-0.3] accessing the last element or is it truncating : to zero and indexing from the front? Perl 5 truncates, I believe. One could argue that floor is better behaved, but the 0/-1 transition in subscripts is totally cork-brained anyway, so I don't think it really matters if our numbers behave when wrapping around the end of an array. Interestingly, negative fractions, if truncated, would give us a way to talk about the element off the end of the array, presuming that the endness of the subscript is determined from the sign before it is truncated: push @array, 42; @array[-0.1] = 42; # same thing @array[-0.0] = 42; # same thing? Since -0.0 is a possible Num representation, that last one probably works. But @array[-0] probably doesn't, since Int probably doesn't represent -0, and the constant folder would remove the sign before the subscript can see it. But it probably doesn't matter. If one really wants infinite modular arrays, then you probably just say @array[$x % @array] or some such, which gives you the floor semantics. Larry
Typology of auto*crement
On Tue, Jan 30, 2007 at 06:02:59PM +0100, TSa wrote:
: Another integer issue is how the ++ and -- operators behave. Do they
: coerce to int before the operation or do they keep nums as nums?
: E.g.
:
: my $x = 3.25;
: $x++; # 4.25 or 4?
: $x = -2.25;
: $x--; # -3.25 or -4 or -3?
Since Str obviously stays Str when you ++ it, I think Num does too.
Let each type decide for itself, but I think most types will not want
to auto-transmogrify themselves to a different type. One exception
is that ++ of an Undef produces Int, unless it was an undefined prototype
of some actual type. So
Str $s;
$s++;
probably increments $s to A or some such.
If ++ and -- are really .succ and .pred in disguise (see C++), then
I'm suddenly wondering if the successor of an iterator is the iterator
with one less element on the front. In which case,
for $*IN++ {...}
would read through the iterator. That doesn't quite work unless we also
make it that $($*IN) returns the head of the iterator. So maybe that's
just a bogus idea.
Larry
Numeric (non)typology of string positions
On Tue, Jan 30, 2007 at 06:02:59PM +0100, TSa wrote: : BTW, are character positions integers or can we have fractional : characters on a higher unicode level that is a sequence of lower : level chars? Unfortunately this is a units problem where the units are not of fixed length. StrPos is already defined in S02 to be an opaque type that you should not think of as being in any particular units except perhaps chars at the current Unicode level. Subtracting two StrPos objects gives you a StrLen at the current Unicode level. These might all be represented underneath as byte or codepoint offsets, but the user should not rely on it. Larry
Int-to-Num autocoercion
On Tue, Jan 30, 2007 at 06:02:59PM +0100, TSa wrote:
: How are coercions handled when calling functions?
:
: sub identity ( Int $i ) { return $i }
:
: my Num $x = 3.25;
:
: say indentity($x); # prints 3 or type error? Or even 3.25?
:
: I'm opting for type error on the footing that Int : Num and
: you can't allow a supertype where a subtype is expected.
Num-to-Int autocoercion is an explicit exception built into the
language. Perl 5 programmars would lynch us if we broke it. But yes,
it's basically cheating. We also cheat and autocoerce Str-to-Num
and Num-to-Str all over the place. :)
The interesting question is how this autocoercion is best declared.
We've batted around several ideas on that in the past, but the general
feeling is that it should only be applied to these basic everyday types,
and that exotic types should not generally autocoerce unless you've
explicitly declared a multi to handle the situation.
Larry
[svn:perl6-synopsis] r13549 - doc/trunk/design/syn
Author: larry Date: Tue Jan 30 12:11:00 2007 New Revision: 13549 Modified: doc/trunk/design/syn/S09.pod Log: Disabled negative subscript dwimmery for all shaped arrays. * can now take + and - operators. Modified: doc/trunk/design/syn/S09.pod == --- doc/trunk/design/syn/S09.pod(original) +++ doc/trunk/design/syn/S09.podTue Jan 30 12:11:00 2007 @@ -12,9 +12,9 @@ Maintainer: Larry Wall [EMAIL PROTECTED] Date: 13 Sep 2004 - Last Modified: 1 Oct 2006 + Last Modified: 30 Jan 2007 Number: 9 - Version: 15 + Version: 16 =head1 Overview @@ -763,4 +763,54 @@ This rule applies to CArray, CHash, and CScalar container objects. +=head1 Negative subscript dwimmery + +It has become the custom to use negative subscripts to indicate counting +from the end of an array. This is still supported, but only for unshaped +arrays: + +my @a1 = 1,2,3; +my @a2[*] = 1,2,3; +@a1[-1] # 3 +@a1[-0.5] # also 3 (uses floor semantics) +@a2[-1] # ERROR +@a2[-0.0001] # ERROR +@a2[0.0001] # 1 + +For shaped arrays you must explicitly refer to the current endpoint +using C*, the CWhatever object: + +@a2[*-1] # 3 +@a2[+*] = 1 # same as push(@a2, 1) + +When you use C* with C+ and C-, it creates a value of CWhatever +but CNum, which the array subscript interpreter will interpret as the +subscript one off the end of that dimension of the array. The lower +right corner of a two dimesional array is C@array[*-1, *-1]. + +This policy has the fortuitous outcome that arrays declared with negative +subscripts will never interpret negative subscripts as relative to the end: + +my @array[-5..5]; +@array[-1]; # always the 4th element, not the 11th. +@array[*-1];# always the 11th element, not the 4th. + +Oddly, this gives us a canonical way to get the last element, but no +canonical way to get the first element, unless + +@array[*-*]; + +works... + +Conjecture: we might provide a way to declare a modular subscript that +emulates the dwimmery, perhaps by using a subset type: + +subset Mod10 of Int where ^10; +my @array[Mod5]; +@array[42] = 1; # sets @array[2] +@array[582];# returns 1 + +But perhaps CMod10 should work just like C^10, and the modular behavior +requires some extra syntax. + =for vim:set expandtab sw=4:
[svn:perl6-synopsis] r13550 - doc/trunk/design/syn
Author: larry Date: Tue Jan 30 12:20:47 2007 New Revision: 13550 Modified: doc/trunk/design/syn/S09.pod Log: Another idea for *+ vs *- in subscripts Modified: doc/trunk/design/syn/S09.pod == --- doc/trunk/design/syn/S09.pod(original) +++ doc/trunk/design/syn/S09.podTue Jan 30 12:20:47 2007 @@ -802,6 +802,12 @@ works... +Alternately, C*+0 is the first element, and the subscript dwims +from the front or back depending on the sign. That would be more +symmetrical, but makes the idea of C* in a subscript a little more +distant from the notion of all the keys, which would be a loss, +and potentially makes C+* not mean the number of keys. + Conjecture: we might provide a way to declare a modular subscript that emulates the dwimmery, perhaps by using a subset type:
Re: [svn:perl6-synopsis] r13549 - doc/trunk/design/syn
HaloO, [EMAIL PROTECTED] wrote: + The lower +right corner of a two dimesional array is C@array[*-1, *-1]. That should read @array[*-1; *-1], or not? --
[svn:perl6-synopsis] r13551 - doc/trunk/design/syn
Author: larry Date: Tue Jan 30 12:31:16 2007 New Revision: 13551 Modified: doc/trunk/design/syn/S09.pod Log: Braino spotted by TSa++ Modified: doc/trunk/design/syn/S09.pod == --- doc/trunk/design/syn/S09.pod(original) +++ doc/trunk/design/syn/S09.podTue Jan 30 12:31:16 2007 @@ -786,7 +786,7 @@ When you use C* with C+ and C-, it creates a value of CWhatever but CNum, which the array subscript interpreter will interpret as the subscript one off the end of that dimension of the array. The lower -right corner of a two dimesional array is C@array[*-1, *-1]. +right corner of a two dimesional array is C@array[*-1; *-1]. This policy has the fortuitous outcome that arrays declared with negative subscripts will never interpret negative subscripts as relative to the end:
Re: [svn:perl6-synopsis] r13549 - doc/trunk/design/syn
On Tue, Jan 30, 2007 at 08:25:37PM +0100, TSa wrote: : HaloO, : : [EMAIL PROTECTED] wrote: : + The lower : +right corner of a two dimesional array is C@array[*-1, *-1]. : : That should read @array[*-1; *-1], or not? Right you are. Though that makes me wonder if a multidimensional Whatever (**) will work to mean the same thing in whatever dimensions there are: @array[**-1] No clue if that every would be useful to anyone... Larry
Re: Int-to-Num autocoercion
HaloO Larry,
you wrote:
Num-to-Int autocoercion is an explicit exception built into the
language. Perl 5 programmars would lynch us if we broke it. But yes,
it's basically cheating.
In your array subscript reply you conceded that flooring
is better behaved than truncation. Which would mean that
-4 === Int(-3.25) should be True. This is important if the
right hand side is an auto-coerced parameter:
sub foo (Int $x)
{
if $x === -4 { say floored }
}
foo(-3.25);
sub distance (Int $from, Int $to) { return $to - $from }
say distance(-3.3, 2.3); # should print 6 or perhaps 5.6
The 5.6 return value would somehow maintain the type
prior to the auto-coercion and not violate the unspecified
return value of foo. That is, one needs a sig of :(Int,Int--Int)
to also force an Int return value. But then that would be
floored to 5. So one way or another you loose precision
when making the Num to Int transition. With auto-coercion
results '-4 but -3.3' and '2 but 2.3' one could calculate a
return value '6 but 5.6' and maintain a maximum of information
while staying type safe.
Hmm, and floor(-0.0) == -1? But this does not carry over the
Num equality -0.0 == +0.0 to Int. So what is more important
sign or magnitude? BTW, does floor return an Int or a Num?
Regards, TSa.
--
[svn:perl6-synopsis] r13552 - doc/trunk/design/syn
Author: larry Date: Tue Jan 30 13:11:37 2007 New Revision: 13552 Modified: doc/trunk/design/syn/S09.pod Log: typo from [particle]++ Modified: doc/trunk/design/syn/S09.pod == --- doc/trunk/design/syn/S09.pod(original) +++ doc/trunk/design/syn/S09.podTue Jan 30 13:11:37 2007 @@ -786,7 +786,7 @@ When you use C* with C+ and C-, it creates a value of CWhatever but CNum, which the array subscript interpreter will interpret as the subscript one off the end of that dimension of the array. The lower -right corner of a two dimesional array is C@array[*-1; *-1]. +right corner of a two dimensional array is C@array[*-1; *-1]. This policy has the fortuitous outcome that arrays declared with negative subscripts will never interpret negative subscripts as relative to the end:
Re: [svn:perl6-synopsis] r13550 - doc/trunk/design/syn
HaloO, [EMAIL PROTECTED] wrote: +Alternately, C*+0 is the first element, and the subscript dwims +from the front or back depending on the sign. That would be more +symmetrical, but makes the idea of C* in a subscript a little more +distant from the notion of all the keys, which would be a loss, +and potentially makes C+* not mean the number of keys. The distinction of the three cases would be through dispatch to different functions. The plain * goes to postcircumfix[ ]:(Array,Whatever) while the other two go to infix:+(Whatever,Int) and infix:-:(Whatever,Int) respectively. In the latter cases the Whatever type somehow must package the array. Perhaps it is actually Whatever of Array or somesuch. The return value is a normal Int suitable for indexing the array. Perhaps we need to restrict the second parameter to UInt unless these two operators wrap around depending on sign ;) That is @array[*+(-1)] actually retrieves that last entry and @array[*-(-1)] the first =:() Can the index be set up before using it in an array index? my @a = 1,2,3; my $x = *-1; say @a[$x]; # prints 3 Would infix:- return a lazy Whatever value that becomes a specific index when it hits postcircumfix[ ]? That is we have something like Whatever arithmetic? Regards, TSa. --
Re: [svn:perl6-synopsis] r13550 - doc/trunk/design/syn
On Tue, Jan 30, 2007 at 09:29:03PM +0100, TSa wrote: : HaloO, : : [EMAIL PROTECTED] wrote: : +Alternately, C*+0 is the first element, and the subscript dwims : +from the front or back depending on the sign. That would be more : +symmetrical, but makes the idea of C* in a subscript a little more : +distant from the notion of all the keys, which would be a loss, : +and potentially makes C+* not mean the number of keys. : : The distinction of the three cases would be through dispatch : to different functions. The plain * goes to : postcircumfix[ ]:(Array,Whatever) while the other two go : to infix:+(Whatever,Int) and infix:-:(Whatever,Int) : respectively. In the latter cases the Whatever type somehow must : package the array. I don't think we want Whatever to package the array, since... : Perhaps it is actually Whatever of Array or : somesuch. The return value is a normal Int suitable for indexing : the array. Perhaps we need to restrict the second parameter to : UInt unless these two operators wrap around depending on sign ;) : That is @array[*+(-1)] actually retrieves that last entry and : @array[*-(-1)] the first =:() : : Can the index be set up before using it in an array index? : :my @a = 1,2,3; :my $x = *-1; :say @a[$x]; # prints 3 : : Would infix:- return a lazy Whatever value that becomes : a specific index when it hits postcircumfix[ ]? That is : we have something like Whatever arithmetic? ...I think that should work. The *-1 value just means one before Whatever, and the dwim is, as you say, lazy. Or perhaps this generalizes to an odd form of currying: replicate := * xx 42; But then it's not clear how the eventual victim would know how to distinguish *+42 from *-42 if it's only getting some kind of closure to call. So I think we still have to dispatch to Whatever and let the Whatever code extract any relevant relative information knowing that a dwim was explicitly called for by use of *. Larry
Re: Negative fraction subscripts
Larry Wall wrote: TSa wrote: : Luke Palmer wrote: : When do we do integer/rational math and when do we do floating point math? : : Since we have now flooring semantics on modulus and division I wonder : how the coercion of nums to ints takes place. Does it also use floor? : E.g. is @array[-0.3] accessing the last element or is it truncating : to zero and indexing from the front? Perl 5 truncates, I believe. One could argue that floor is better behaved, but the 0/-1 transition in subscripts is totally cork-brained anyway, so I don't think it really matters if our numbers behave when wrapping around the end of an array. Perhaps. Then again, it isn't the remainder that would define which element you're looking at in this case; it would be the integer portion. And if I understand flooring semantics properly, -0.3 div 1 == -1. Also, -0.3 mod 1 == 0.7; right? Or is that the difference between mod and %: the former returns the remainder as an integer (e.g., '0'), while % return the remainder as a Num (e.g., '0.7')? With truncating semantics, -0.3 div 1 == 0, and -0.3 % 1 == -0.3. I think that TSa has a point here: converting from Num to Int should always be equivalent to saying 'Num div 1'. Which means that if you ever override div to provide different semantics by default (e.g., Euclidean), you would also change the semantics of the Num-to-Int coercion. Interestingly, negative fractions, if truncated, would give us a way to talk about the element off the end of the array, presuming that the endness of the subscript is determined from the sign before it is truncated: push @array, 42; @array[-0.1] = 42; # same thing @array[-0.0] = 42; # same thing? Eh. A neat little bell-and-whistle, but more confusing than it is useful. But it probably doesn't matter. If one really wants infinite modular arrays, then you probably just say @array[$x % @array] or some such, which gives you the floor semantics. True enough. I'd suggest doing this implicitly (with 'mod' instead of '%'), ensuring that virtually every index maps to an existing element; but then you'd lose the ability to append to an array by assigning to '@[EMAIL PROTECTED]' (not that I'd do this; but I can see why some might prefer this idiom to being pushy). It's the sort of thing that I could see using a trait for: 'my @array but oroborus' would invoke an implicit modulus on the index, while standard arrays would not. Likewise, those who don't want the backward-indexing semantics could remove them by saying something like 'my @array but ray', causing negative indices to throw errors instead. Ideally, applying both would cause negative indices to choke, but would wrap too-large positive indices back to the beginning of the array. -- Jonathan Dataweaver Lang
Enhancing array indices
Could we get a single-character symbol that could be used in an array index to refer to its shape in a dwimmy way? Something like: @x[*.head] @x[*.tail] # equivalent to @x[*] @A[*.head+2, *.tail-1] (where head and tail are methods of the shape that return the current dimension's start and end points.) -- Jonathan Dataweaver Lang
Re: Negative fraction subscripts
On Tue, Jan 30, 2007 at 09:23:33AM -0800, Larry Wall wrote: Since -0.0 is a possible Num representation, that last one probably works. But @array[-0] probably doesn't, since Int probably doesn't represent -0, Well, it might just be using 1's complement :-) Nicholas Clark
Re: Negative fraction subscripts
On Tue, Jan 30, 2007 at 02:19:01PM -0800, Jonathan Lang wrote: : It's the sort of thing that I could see using a trait for: 'my @array : but oroborus' would invoke an implicit modulus on the index, while : standard arrays would not. Likewise, those who don't want the : backward-indexing semantics could remove them by saying something like : 'my @array but ray', causing negative indices to throw errors instead. : Ideally, applying both would cause negative indices to choke, but : would wrap too-large positive indices back to the beginning of the : array. Um, negative indices on shaped arrays were outlawed several hours ago... Larry
Re: Negative fraction subscripts
Larry Wall wrote: Um, negative indices on shaped arrays were outlawed several hours ago... Yeah; I hadn't gotten around to that when I posted this. Sorry about that. -- Jonathan Dataweaver Lang
Re: Enhancing array indices
On Tue, Jan 30, 2007 at 02:54:26PM -0800, Jonathan Lang wrote: : Could we get a single-character symbol that could be used in an array : index to refer to its shape in a dwimmy way? Something like: : : @x[*.head] : @x[*.tail] # equivalent to @x[*] : @A[*.head+2, *.tail-1] : : (where head and tail are methods of the shape that return the current : dimension's start and end points.) This mornings up date proposed @x[*+0] @x[*-1] @A[*+2, *-1] for that. But maybe you meant @x[*+2 .. *-1]? And @x[*] would be @x[*+0..^*-0] written out that way. Or possibly @x[-* ..^ +*] depending on how we define the unaries. [BTW, I'm suddenly wondering now if spam filters are weeding out the synopsis updates for certain people...I've noticed that when I respond to a thread by doing a synopsis update it tends not to end up in the summaries, for instance. Maybe gmail thinks they're spam because of too much self-similarity?] Larry
Re: Enhancing array indices
On Tue, Jan 30, 2007 at 03:47:34PM -0800, Larry Wall wrote: : This mornings up date proposed Now the da rn spam fi1ters are chang.ng my spelling to look like sp*m. Yeah, that's the 4icket... :) Larry
Re: Int-to-Num autocoercion
At 9:07 PM +0100 1/30/07, TSa wrote: BTW, does floor return an Int or a Num? A floor() returns an Int of course, because by definition floor() returns an integer. See http://en.wikipedia.org/wiki/Floor_function for an explanation. Same with ceiling(), and some other operators. If anything, people should be able to call floor() etc explicitly if they want to make their Num-Int conversions explicit rather than implicit. -- Darren Duncan
Re: Enhancing array indices
At 12:11 PM -0800 1/30/07, [EMAIL PROTECTED] wrote: Log: Disabled negative subscript dwimmery for all shaped arrays. * can now take + and - operators. At 2:54 PM -0800 1/30/07, Jonathan Lang wrote: Could we get a single-character symbol that could be used in an array index to refer to its shape in a dwimmy way? Something like: @x[*.head] @x[*.tail] # equivalent to @x[*] @A[*.head+2, *.tail-1] (where head and tail are methods of the shape that return the current dimension's start and end points.) In a related fashion ... I'm thinking it may be better to just get rid of negative subscript dwimmery entirely, eg @foo[-1], and use things like @foo[*.head] and @foo[*.tail] instead to refer to the first and last elements. That solution is a lot more self-describing, leads to better consistency between shaped and unshaped arrays, and is easy to learn for both Perl 5 people and people coming from other languages. Also importantly, it should prevent common types of errors. If being more terse is important, you could further abbreviate .head and .tail, but the main point is that a plain -N array index never means count from the end. -- Darren Duncan
[svn:perl6-synopsis] r13553 - doc/trunk/design/syn
Author: larry
Date: Tue Jan 30 18:40:29 2007
New Revision: 13553
Modified:
doc/trunk/design/syn/S03.pod
Log:
Various suggestions by Nick++
Modified: doc/trunk/design/syn/S03.pod
==
--- doc/trunk/design/syn/S03.pod(original)
+++ doc/trunk/design/syn/S03.podTue Jan 30 18:40:29 2007
@@ -12,9 +12,9 @@
Maintainer: Larry Wall [EMAIL PROTECTED]
Date: 8 Mar 2004
- Last Modified: 28 Jan 2007
+ Last Modified: 30 Jan 2007
Number: 3
- Version: 92
+ Version: 93
=head1 Overview
@@ -293,14 +293,33 @@
As in C, these operators increment or decrement the object in question
either before or after the value is taken from the object, depending on
-whether it is put before or after. Also as in C, use of multiple side
-effects on a single object in the same expression results in undefined
+whether it is put before or after. Also as in C, multiple references
+to a single mutating object in the same expression may result in undefined
behavior unless some explicit sequencing operator is interposed.
+See L/Sequence points.
As with all postfix operators in Perl 6, no space is allowed between
a term and its postfix. See S02 for why, and for how to work around the
restriction with a long dot.
+As mutating methods, all these operators dispatch to the type of
+the operand and return a result of the same time, but they are legal
+on value types only if the (immutable) value is stored in a mutable
+container. However, a bare undefined value (in a suitable CScalar
+container) is allowed to mutate itself into an CInt in order to
+support the common idiom:
+
+say $x unless %seen{$x}++;
+
+Increment of a CStr (in a suitable container) works as in Perl 5.
+(Use a derived type or a lexical multi to change this.) Perl 6 also
+supports CStr decrement.
+
+Increment of a CBool (in a suitable container) turns it true.
+Decrement turns it false. This is useful if your C%seen array is
+actually a CKeySet, in which case decrement actually deletes it
+from the CKeySet.
+
=over
=item *
@@ -332,7 +351,7 @@
If the right argument is not an integer, the result is likely to
be an approximation. If the right argument is of an integer type,
exponentiation is at least as accurate as repeated multiplication on
-the left side's type. (From which it can be deduced that CInt**Int
+the left side's type. (From which it can be deduced that CInt**UInt
is always exact, since Int supports arbitrary precision.) If the
right argument is an integer represented in a non-integer type, the
accuracy is left to implementation provided by that type; there is
@@ -425,9 +444,9 @@
Unary C= reads lines from a filehandle or filename, or
iterates an iterator, or in general causes a scalar to explode its guts
when it would otherwise not. How it does that is context sensitive.
-For instance, C=$iterator is scalar/list sensitive and will
-produce one value in scalar context but many values in list context.
-(Use C@$iterator to force a fetch of all the values even in scalar
+For instance, C=$iterator is item/list sensitive and will
+produce one value in item context but many values in list context.
+(Use C@$iterator to force a fetch of all the values even in item
context, and C$$iterator to force a fetch of a single value even
in list context.) On the other hand, C=$capture interpolates all
parts of the capture that makes sense in the current list context,
@@ -649,6 +668,8 @@
item
The new name for Perl 5's Cscalar contextualizer. Equivalent to C$().
+We still call the values scalars, and talk about scalar operators, but
+scalar operators are those that put their arguments into item context.
=back
@@ -816,9 +837,10 @@
-Returns the left argument if the left argument is false, otherwise returns
-the right argument. In list context forces a false return to mean C().
-See Cand below for low-precedence version.
+Returns the left argument if the left argument is false, otherwise
+evaluates and returns the right argument. In list context forces
+a false return to mean C(). See Cand below for low-precedence
+version.
=back
@@ -832,9 +854,9 @@
||
-Returns the left argument if it's true, otherwise the right argument.
-In list context forces a false return to mean C().
-See Cor below for low-precedence version.
+Returns the left argument if it's true, otherwise evaluates and
+returns the right argument. In list context forces a false return
+to mean C(). See Cor below for low-precedence version.
=item *
@@ -853,9 +875,9 @@
//
-Returns the left argument if it's defined, otherwise the right argument.
-In list context forces a false return to mean C().
-See Cerr below for low-precedence version.
+Returns the left argument if it's defined, otherwise evaluates and
+returns the right argument. In list context forces a false return
+to mean C(). See Cerr below for low-precedence version.
Re: Enhancing array indices
Larry Wall wrote: And @x[*] would be @x[*+0..^*-0] written out that way. Or possibly @x[-* ..^ +*] depending on how we define the unaries. Hmm... how about this: Normally, * in the context of an indexer acts as a Range object, covering the range of available indices (defined inclusively). I'm assuming that Range objects provide methods for accessing the lower and upper bounds of the range (probably 'min' and 'max'); these methods could be used to refer to the start and end of the array explicitly. When coerced to Num, * points to the first element of the array and enables negative-index dwimmery relative to it - i.e., '* + Int' (where Int 0) counts from the end (with '*-1' being the end), while '* + Int' (where Int = 0) counts from the start (with '*+0' being the start). Or perhaps it uses Oroborus dwimmery, with too-large indices wrapping back around to where they started: @x[*+5] is the same as @x[*+0] for a five-element array. So: @x[*] # every element @x[*.min] # first element @x[*.min+0] # first element @x[*.min+1] # second element @x[*.min-1] # just before first element @x[*.max] #last element @x[*.max+0] # last element @x[*.max+1] # just after last element @x[*.max-1] # second to last element @x[+*] # first element @x[*+0] # first element @x[*+1] # second element @x[*-1] # last element Unshaped arrays work exactly like shaped arrays; so perl 5's '$x[-1]' becomes '@x[*-1]', while '@x[-1]' is a reference to just before the first element (and assigning a value to it shapes the array to include it within the lower bound). That said, I'd like to be able to spell '[*.min]' as '[1st]', '[*.min+1]' as '[2nd]', and '[*.max]' as '[last]'; but I could live without 'em. -- Jonathan Dataweaver Lang
[svn:perl6-synopsis] r13554 - doc/trunk/design/syn
Author: larry Date: Tue Jan 30 18:54:32 2007 New Revision: 13554 Modified: doc/trunk/design/syn/S03.pod Log: Deleted stylistic notes ill-suited for a spec. Modified: doc/trunk/design/syn/S03.pod == --- doc/trunk/design/syn/S03.pod(original) +++ doc/trunk/design/syn/S03.podTue Jan 30 18:54:32 2007 @@ -945,19 +945,6 @@ my $x = hmm() ?? 1 !! 2; # much better -Some people like to write it like this: - -my $x = hmm() -?? 1 -!! 2; - -A tabular form is also popular for cascaded conditionals: - -my $result = $a ?? 1 !! - $b ?? 2 !! - $c ?? 3 !! - 4; - =back =head2 Item assignment precedence
[svn:perl6-synopsis] r13555 - doc/trunk/design/syn
Author: larry Date: Tue Jan 30 19:00:44 2007 New Revision: 13555 Modified: doc/trunk/design/syn/S01.pod Log: While the month of Nob is cute... Modified: doc/trunk/design/syn/S01.pod == --- doc/trunk/design/syn/S01.pod(original) +++ doc/trunk/design/syn/S01.podTue Jan 30 19:00:44 2007 @@ -12,7 +12,7 @@ Maintainer: Larry Wall [EMAIL PROTECTED] Date: 10 Aug 2004 - Last Modified: 1 Nob 2006 + Last Modified: 1 Nov 2006 Number: 1 Version: 5
[svn:perl6-synopsis] r13556 - doc/trunk/design/syn
Author: larry Date: Tue Jan 30 19:05:36 2007 New Revision: 13556 Modified: doc/trunk/design/syn/S01.pod Log: Forgot to change the date... :) Modified: doc/trunk/design/syn/S01.pod == --- doc/trunk/design/syn/S01.pod(original) +++ doc/trunk/design/syn/S01.podTue Jan 30 19:05:36 2007 @@ -12,9 +12,9 @@ Maintainer: Larry Wall [EMAIL PROTECTED] Date: 10 Aug 2004 - Last Modified: 1 Nov 2006 + Last Modified: 30 Jan 2007 Number: 1 - Version: 5 + Version: 6 This document originally summarized Apocalypse 1, which covers the initial design concept. That original summary may be found below
What Skills Do We Need to Finish Parrot?
Do we have answers to the following questions? 1. What code is still unwritten that we will need to have Parrot ready to go (where ready to go is defined as: ready for a Perl 6 alpha)? (I'll leave aside the question of when *that* will be ready.) 2. What skills are needed to write that code? In particular, what skills do we need that are currently in short supply? I ask these questions because I want to know what specific aspects of the Parrot project to focus on if I should run into people with skills I don't have who could be induced to join the project. kid51
[perl #41380] [PATCH]: docs/roles_responsibilities.pod: Minor grammatical corrections
# New Ticket Created by James Keenan # Please include the string: [perl #41380] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org/rt3/Ticket/Display.html?id=41380 Delete superluous commas before close-parens in 2 locations. [parrot] 520 $ diffstat roles_responsibilities.patch roles_responsibilities.pod |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) kid51 roles_responsibilities.patch Description: Binary data
Re: [perl #41380] [PATCH]: docs/roles_responsibilities.pod: Minor grammatical corrections
On Tuesday 30 January 2007 19:51, James Keenan wrote: Delete superluous commas before close-parens in 2 locations. Thanks, applied as r16850. -- c
