make POST blocks more usable
I skimmed through S06 and I found no convenient way to use the return
value of sub/method in it's POST blocks.
Since they can (and should) be used (among other things) to check the
sub's/method's return value, I'd like to propose that the return value
of a sub is given as the argument to POST block, so that you can write
sub my_sqrt ($x) {
# calculation with many possible return pathes
POST - $result {
$result * $result == $x
}
}
I don't really know what do when the sub is left through an exception,
maybe it should search for a POST multi with empty arguments? (or do
exceptions ignore POST blocks anyway?)
Cheers,
Moritz
--
Moritz Lenz
http://moritz.faui2k3.org/ | http://perl-6.de/
signature.asc
Description: OpenPGP digital signature
Re: assignable mutators (S06/Lvalue subroutines)
TSa wrote:
class Length
{
has Num $.mm is rw = 0;
method inch
{
yield $inch = $.mm * 25.4;
self.mm = $inch / 25.4;
}
}
Would you regard that as elegant?
That looks functionally incorrect to my eyes: if the caller resumes at
the time of the yield statement, and immediately assigns a new value
to the mm attribute, then there is a race between the two updates to mm.
Re: assignable mutators (S06/Lvalue subroutines)
TSa wrote:
TSa wrote:
class Length
{
has Num $.mm is rw = 0;
method inch
{
yield $inch = $.mm * 25.4;
self.mm = $inch / 25.4;
}
}
Would you regard that as elegant?
That looks functionally incorrect to my eyes: if the caller resumes at
the time of the yield statement, and immediately assigns a new value
to the mm attribute, then there is a race between the two updates to
mm.
Why two assignments? [cut]
The sequence I was thing of is:
my $obj = Length.new;
$obj.mm = 42;
say $obj.inch; # your Length.inch method yields
$obj.mm = 63;
say $obj.inch; # Length.inch to resumes, overwriting $obj.mm back to 42
It seems to me that the assignment within your inch method will occur
*after* my assignment of $obj.mm = 63
[svn:perl6-synopsis] r14546 - doc/trunk/design/syn
Author: larry
Date: Tue May 27 16:19:34 2008
New Revision: 14546
Modified:
doc/trunk/design/syn/S09.pod
Log:
Cleanup bogus use of adverbs on bare terms
Modified: doc/trunk/design/syn/S09.pod
==
--- doc/trunk/design/syn/S09.pod(original)
+++ doc/trunk/design/syn/S09.podTue May 27 16:19:34 2008
@@ -12,9 +12,9 @@
Maintainer: Larry Wall [EMAIL PROTECTED]
Date: 13 Sep 2004
- Last Modified: 2 Apr 2008
+ Last Modified: 27 May 2008
Number: 9
- Version: 26
+ Version: 27
=head1 Overview
@@ -524,29 +524,21 @@
say @dwarves{1}; # Fails: can't map .{1} to a standard .[] index
-When a C:k, C:kv, or C:p adverb is applied to a full array,
-the keys returned are always the standard indices.
-
-my @arr{1,3,5,7,9} = one two three four five;
-
-say @arr:k; # 0, 1, 2, 3, 4
-
-However, you can specify which set of keys are returned:
-
-say @arr:k[] # 0, 1, 2, 3, 4
-say @arr:k{} # 1, 3, 5, 7, 9
-
When C:k, C:kv, or C:p is applied to an array slice, it returns
-the kind of indices that were used to produce the slice, unless the type
-of index is explicitly requested:
+the kind of indices that were used to produce the slice:
@arr[0..2]:p # 0='one', 1='two', 2='three'
-@arr[0..2]:p[]# 0='one', 1='two', 2='three'
-@arr[0..2]:p{}# 1='one', 3='two', 5='three'
-
@arr{1,3,5}:p # 1='one', 3='two', 5='three'
-@arr{1,3,5}:p[] # 0='one', 1='two', 2='three'
-@arr{1,3,5}:p{} # 1='one', 3='two', 5='three'
+
+Adverbs may be applied only to operators, not to terms, so C:k,
+C:kv, and C:p may not be applied to a full array. However, you
+may apply an adverb to a Zen slice, which can indicate which set of
+keys are desired:
+
+my @arr{1,3,5,7,9} = one two three four five;
+
+say @arr[]:k; # 0, 1, 2, 3, 4
+say @arr{}:k; # 1, 3, 5, 7, 9
The C.keys method also returns the keys of all existing elements.
For a multidimensional array each key is a list containing one value for
@@ -588,7 +580,7 @@
say @results[*]; # Same as: say @results[0..49]
say @results{*}; # Same as: say @results{1..100 :by(2)}
-You can omit unallocated elements, either by using the :v adverb:
+You can omit unallocated elements, either by using the C:v adverb:
say @results[*]:v;# Same as: say @results[0..3]
say @results{*}:v;# Same as: say @results{1,3,5,7}
@@ -846,7 +838,7 @@
need to be, if ever. So a PDL implementation is free to steal the
values from these ranges and piddle around with them:
-@nums[$min..$max:by(3)]
+@nums[$min..$max :by(3)]
@nums[$min..$max]
@nums[$min..*:by(3)]
@nums[1..*:by(2)] # the odds
ordinal access to autosorted hashes
From S09: The default hash iterator is a property called .iterator
that can be user replaced. When the hash itself needs an iterator for
.pairs, .keys, .values, or .kv, it calls %hash.iterator() to start
one. In item context, .iterator returns an iterator object. In list
context, it returns a lazy list fed by the iterator.
Would it be reasonable to allow hashes to use .[] syntax as something
of a shortcut for .iterator in list context, thus allowing
autosorted hashes to partake of the same sort of dual cardinal/ordinal
lookup capabilities that lists with user-defined array indices have?
e.g.:
my %point{Int};
%point{3} = Star;
say %point[0]; # same as 'say %point{3}'
say %point[1]; # error: asking for the second of one key is nonsense.
%point{-2} = Base;
say %point[0]; # same as 'say %point{-2}'
say %point[1]; # same as 'say %point{3}'
Mind you, this could get messy with multidimensional keys:
my %grid{Int;Int};
%grid{3;-2} = Star;
%grid{-2;3} = Base;
say %grid[0;1]; # Base
say %grid[1;0]; # Star
say %grid[0;0]; # error? %grid{-2;-2} has never had anything assigned to it.
Still, it could be useful to be able to access an autosorted hash's
keys in an ordinal fashion.
Side issue: S09 doesn't specify whether or not you need to explicitly
declare a hash as autosorted. I'm assuming that the parser is
supposed to figure that out based on whether or not .iterator is ever
used; but it isn't immediately obvious from reading the Autosorted
hashes section. As well, there might be times when explicitly
declaring a hash as autosorted (or not) might be useful for
optimization purposes.
--
Jonathan Dataweaver Lang
