r27033 - docs/Perl6/Spec
Author: pmichaud
Date: 2009-06-08 17:20:31 +0200 (Mon, 08 Jun 2009)
New Revision: 27033
Modified:
docs/Perl6/Spec/S11-modules.pod
Log:
Remove line about module Foo; needing to be first in file.
Modified: docs/Perl6/Spec/S11-modules.pod
===
--- docs/Perl6/Spec/S11-modules.pod 2009-06-08 08:18:53 UTC (rev 27032)
+++ docs/Perl6/Spec/S11-modules.pod 2009-06-08 15:20:31 UTC (rev 27033)
@@ -34,8 +34,6 @@
module Bar {...}# block is in module Bar
-The first form is allowed only as the first statement in the file.
-
A named module declaration can occur as part of an expression, just like
named subroutine declarations.
r27034 - docs/Perl6/Spec
Author: lwall
Date: 2009-06-08 17:27:48 +0200 (Mon, 08 Jun 2009)
New Revision: 27034
Modified:
docs/Perl6/Spec/S03-operators.pod
Log:
[S03] reduce prececedence of adverbs from inside comma to inside item_assignment
Modified: docs/Perl6/Spec/S03-operators.pod
===
--- docs/Perl6/Spec/S03-operators.pod 2009-06-08 15:20:31 UTC (rev 27033)
+++ docs/Perl6/Spec/S03-operators.pod 2009-06-08 15:27:48 UTC (rev 27034)
@@ -13,8 +13,8 @@
Maintainer: Larry Wall la...@wall.org
Date: 8 Mar 2004
- Last Modified: 24 May 2009
- Version: 166
+ Last Modified: 7 Jun 2009
+ Version: 167
=head1 Overview
@@ -1342,6 +1342,54 @@
=back
+=head1 Adverbs
+
+Operator adverbs
+are parsed as trailing unary operators at this precedence level,
+just tighter than item assignment. (They're not officially postfix operators
+because those require the absense of whitespace, and these allow whitespace.
+These adverbs insert themselves in the spot where the parser is
+expecting an infix operator, but the parser continues to look for
+an infix after parsing the adverb and applying it to the previous
+term.) Thus,
+
+$a 1 and $b == 2 :carefully
+
+does the C== carefully, while
+
+$a 1 $b == 2 :carefully
+
+does the C carefully because C is of
+tighter precedence than comma. Use
+
+$a 1 ($b == 2 :carefully)
+
+to apply the adverb to the C== operator instead. We say that
+C== is the topmost operator in the sense that it is at the
+top of the parse tree that the adverb could possibly apply to.
+(It could not apply outside the parens.) If you are unsure
+what the topmost operator is, just ask yourself which operator
+would be applied last. For instance, in
+
++%hash{$key} :foo
+
+The subscript happens first and the C+ operator happens last,
+so C:foo would apply to that. Use
+
++(%hash{$key} :foo)
+
+to apply C:foo to the subscripting operator instead.
+
+Adverbs will generally attach the way you want when you say things like
+
+1 .. $x+2 :by(2)
+
+The proposed internal testing syntax makes use of these precedence rules:
+
+$x eqv $y+2 :ok$x is equivalent to $y+2;
+
+Here the adverb is considered to be modifying the Ceqv operator.
+
=head2 Item assignment precedence
=over
@@ -1442,60 +1490,6 @@
=back
-While the preceding are parsed as prefix operators, operator adverbs
-are parsed as trailing unary operators at this precedence level,
-just tighter than comma. (They're not officially postfix operators
-because those require the absense of whitespace, and these allow whitespace.
-These adverbs insert themselves in the spot where the parser is
-expecting an infix operator, but the parser continues to look for
-an infix after parsing the adverb and applying it to the previous
-term.) Thus,
-
-$a 1 and $b == 2 :carefully
-
-does the C== carefully, while
-
-$a 1 $b == 2 :carefully
-
-does the C carefully because C is of
-tighter precedence than comma. Use
-
-$a 1 ($b == 2 :carefully)
-
-to apply the adverb to the C== operator instead. We say that
-C== is the topmost operator in the sense that it is at the
-top of the parse tree that the adverb could possibly apply to.
-(It could not apply outside the parens.) If you are unsure
-what the topmost operator is, just ask yourself which operator
-would be applied last. For instance, in
-
-+%hash{$key} :foo
-
-The subscript happens first and the C+ operator happens last,
-so C:foo would apply to that. Use
-
-+(%hash{$key} :foo)
-
-to apply C:foo to the subscripting operator instead. Likewise
-
-$x = 1..10:by(2)
-
-will apply the adverb to the item assignment (and fail), but since
-
-@x = 1..10:by(2)
-
-is a (looser) list assignment, the adverb applies to the range operator
-as expected. And in general note that adverbs will attach the way
-you want when you say things like
-
-1 .. $x+2 :by(2)
-
-The new internal testing syntax makes use of these precedence rules:
-
-$x eqv $y+2 :ok$x is equivalent to $y+2;
-
-Here the adverb is considered to be modifying the Ceqv operator.
-
=head2 Comma operator precedence
=over
r27035 - docs/Perl6/Spec
Author: lwall Date: 2009-06-08 17:38:07 +0200 (Mon, 08 Jun 2009) New Revision: 27035 Modified: docs/Perl6/Spec/S03-operators.pod Log: [S03] slight clarifications to previous adverbial changes Modified: docs/Perl6/Spec/S03-operators.pod === --- docs/Perl6/Spec/S03-operators.pod 2009-06-08 15:27:48 UTC (rev 27034) +++ docs/Perl6/Spec/S03-operators.pod 2009-06-08 15:38:07 UTC (rev 27035) @@ -47,7 +47,7 @@ X Tight or || ^^ // min max R Conditional ?? !! ff fff R Item assignment = := ::= = += -= **= xx= .= -L Loose unary true not :by(2) +L Loose unary true not X Comma operator, p5= : X List infixZ minmax X X~ X* Xeqv ... R List prefix print push say die map substr ... [+] [*] any $ @ @@ -1344,9 +1344,10 @@ =head1 Adverbs -Operator adverbs -are parsed as trailing unary operators at this precedence level, -just tighter than item assignment. (They're not officially postfix operators +Operator adverbs are special-cased in the grammar, but give +the appearance of being parsed as trailing unary operators at a +pseudo-precedence level slightly tighter than item assignment. +(They're not officially postfix operators because those require the absense of whitespace, and these allow whitespace. These adverbs insert themselves in the spot where the parser is expecting an infix operator, but the parser continues to look for
Assigning duplicate values to several hash keys using junctions?
Hello all,
I was curious if this is possible in Perl 6:
%hash{ 'foo' 'bar' } = 'some value';
# %hash{'foo'} eq 'some value' and %hash{'bar'} eq 'some value'
or perhaps
%hash{ 'foo' | 'bar' } = 'some value';
In other words, is it possible to assign the same value to multiple hash
keys simultaneously using junctions (or some other new mechanism)? In
Perl 5, I would do
$hash{'foo'} = $hash{'bar'} = 'some value';
which gets tedious with more than one hash key. An alternative is always
@hash{qw(foo bar)} = ('some value') x 2;
which is probably
%hashfoo bar = ('some value') x 2;
in Perl 6, but you always need to take care to write the correct integer
in the list replication. The best way is, of course, (in Perl 5)
{
my @keys = qw(foo bar);
@ha...@keys} = ('some value') x @keys;
}
but then you need the @keys array, which needs to be defined if you are
dealing with literal values. Reading the synopses, one possibility seems
to be
%hashfoo bar = 'some value';
using hyper operators, but is that really the best way?
Regards,
Ville Koskinen
say followed by lines - inconsistencies
I came upon the following, which seems to be in line with spec, but I
think is inconsistent.
I write a hash to a file delimited by tabs, eg
my $fn=open('data.csv',:w);
my %x=one two three four Z 1,2,2.1,3;
$fn.say('record-name'~map(\t$^a\t$^b),%x);
$fn.close;
The output sometimes contains either the keys or the values padded with
single spaces on either side (I cannot find a pattern for the spaces). I
am not sure whether this a bug of say (or $fn.say() ).
So now I want to read in the data again. (The problem arises because
perl6 has a memory leak and my program segfaults after five loops, so I
need to store the intermediate data; this is a serialisation problem,
but I dont need to go to the extreme of yaml for it).
my $fn=open('data.csv',:r);
my $record-name;
my @fields;
($record-name,@fields)=$fn.lines(1).split(/\t/);
my %x = %(map{$^a = $^b}, @fields);
Except that the spaces added by .say are included in the key/value
parts. This screws up the program as spaces are not expected.
The spec specifically says that split will not trim the results. Hence,
the solution is
($record-name,@fields)=map {.trim}, $fn.lines(1).split(/\t/);
This does seem to be a bit inconsistent in that I am outputting and
inputting with essentially the same sort of scripting, but I am not
getting a predictable end result.
The spec also seems to recommend .comb
I have a problem with this because some of the data I want to read in
has empty cells, eg.
datum1\tdatum2\t\tend-datum
I want this to end up in an array
['datum1','datum2',*,'end-datum']
Yet I cant see how .comb will accomplish this. Could someone enlighten me?
But even if it was not a problem with .say, I could see that white space
trimming would be useful with split.
So, is there some good reason why .split does not automatically trim?
Richard
Re: Assigning duplicate values to several hash keys using junctions?
2009/6/8 Ville Koskinen vrk...@iki.fi:
Hello all,
I was curious if this is possible in Perl 6:
%hash{ 'foo' 'bar' } = 'some value';
# %hash{'foo'} eq 'some value' and %hash{'bar'} eq 'some value'
By autothreading, this would be equivalent to:
(%hash{'foo'} %hash{'bar'}) = 'some value';
which in turn is the same as:
(%hash{'foo'} = 'some value') (%hash{'bar'} = 'some value');
So yes, this is possible.
--
Jonathan Dataweaver Lang
r27037 - docs/Perl6/Spec
Author: jnthn Date: 2009-06-08 22:56:30 +0200 (Mon, 08 Jun 2009) New Revision: 27037 Modified: docs/Perl6/Spec/S12-objects.pod Log: [spec] Rename :hierarchical option to :tree in the spec for some meta-class method, as suggested on p6l. Modified: docs/Perl6/Spec/S12-objects.pod === --- docs/Perl6/Spec/S12-objects.pod 2009-06-08 20:50:17 UTC (rev 27036) +++ docs/Perl6/Spec/S12-objects.pod 2009-06-08 20:56:30 UTC (rev 27037) @@ -1838,7 +1838,7 @@ parents sorted in MRO (dispatch) order. Other options are: :local just returns the immediate parents -:hierarchical the inheritance heirarchy as nested arrays +:tree the inheritance heirarchy as nested arrays The C.^methods method returns method-descriptors containing: @@ -1853,7 +1853,7 @@ whether you're interested in private methods, and so forth. :local only methods defined in the current class -:hierarchical methods by class structure (inheritance hierarchy) +:tree methods by class structure (inheritance hierarchy) :privateinclude private methods The C.^attributes method returns a list of attribute descriptors @@ -1871,7 +1871,7 @@ It also takes the parameters: :local only methods defined in the current class -:hierarchical attributes by class structure (inheritance hierarchy) +:tree attributes by class structure (inheritance hierarchy) Strictly speaking, metamethods like C.isa(), C.does(), and C.can() should be called through the meta object:
Re: Assigning duplicate values to several hash keys using junctions?
On Mon, Jun 08, 2009 at 12:02:43PM +0100, Ville Koskinen wrote:
: An alternative is always
:
: @hash{qw(foo bar)} = ('some value') x 2;
:
: which is probably
:
: %hashfoo bar = ('some value') x 2;
:
: in Perl 6, but you always need to take care to write the correct integer
: in the list replication.
Two problems. First, list replicaiton is xx rather than x, and second,
you *don't* have to write the integer, because you can use the
Whatever star:
%hashfoo bar = 'some value' xx *;
That makes an arbitrarily long list of strings.
: The best way is, of course, (in Perl 5)
:
: {
:my @keys = qw(foo bar);
:@ha...@keys} = ('some value') x @keys;
: }
:
: but then you need the @keys array, which needs to be defined if you are
: dealing with literal values.
Perl 6's new * term is useful in many such places where you just want
to say, I dunno, you figure it out.
: Reading the synopses, one possibility seems to be
:
: %hashfoo bar = 'some value';
:
: using hyper operators, but is that really the best way?
If you'll define best way, I'll tell you if it is. :)
The relative efficiency is going to be difficult to predict because
any of these could be poorly implemented and do too much busywork.
Apart from that, it's gonna come down primarily to what you think
is readable.
By the way, infix hypers want to go on both sides, like this:
%hashfoo bar »=» 'some value';
Larry
Re: say followed by lines - inconsistencies
On Tue, Jun 09, 2009 at 12:37:10AM +0400, Richard Hainsworth wrote:
I write a hash to a file delimited by tabs, eg
my $fn=open('data.csv',:w);
my %x=one two three four Z 1,2,2.1,3;
$fn.say('record-name'~map(\t$^a\t$^b),%x);
$fn.close;
The output sometimes contains either the keys or the values padded with
single spaces on either side (I cannot find a pattern for the spaces). I
am not sure whether this a bug of say (or $fn.say() ).
Well, regardless of whether there are extra spaces, please note that
the default stringifications are not intended as a serialization
format. They are intended only to provide a bit of human readability
for the common case of small, spaceless items such as numbers and
words; they make no guarantee about the sanity of the delimiters.
So now I want to read in the data again. (The problem arises because
perl6 has a memory leak and my program segfaults after five loops, so I
need to store the intermediate data; this is a serialisation problem,
but I dont need to go to the extreme of yaml for it).
Hmm, if you think yaml is extreme, yowie, the world is a harsh place...
I guess I can only suggest that you use .perl instead, for a minimal
serialization format. Or write your own explicit formatting and
serialization using .fmt calls.
Larry
LValues, types, mutability
TSa Thomas.Sandlass-at-vts-systems.de |Perl 6| wrote:
I like your idea to call the class that handles container access
LValue. I have proposed the name AssignmentProxy elsewhere.
Thanks. I'll quote that so it gets more exposure and hopefully will
build a consensus or other feedback. :)
But I'm not sure what S06 means with can be converted to an lvalue
in the description of the 'is rw' parameter trait. To me this means
autoboxing such that you can call a mutating sub with a constant. The
modifications done to the automatic container are lost after the call.
You state that the compiler raises an error which clearly is the cleaner
approach.
I don't recall what was said about converted to either. But last
year, in discussing it here, the lesson was that this is the point of
having both rw and ref: the former demands an lvalue, the latter does not.
As for what happens in the latter case under various conditions
some people might expect a soft conversion to an assignable lvalue that
just gets lost and doesn't actually affect the caller. I'd like to
raise awareness and discuss this further.
Why would you want to do that? Nostalgia for Perl 5? Most languages
that have a pass-by-ref mode or equivalent do in fact demand that the
caller supply an lvalue, if you declare the functions intent to modify
the caller's variable like that.
What is the engineering behind maybe modifying it? Is that the output
or isn't it?! If you insist, then you can overload the function
signatures: rw is preferred. And if the signature is not bindable, it
is not in the list for consideration, and you get the other form.
If you do write ref with the intention of being an optional
modification, there are two alternatives: autogenerate one so
assignment works (but doesn't affect the caller), or don't, making
assignment an error. In the former case you cannot tell what happened!
I see that as inferior. In the latter, you can use VAR to sense whether
it is assignable (and thus *meaningfully* assignable) or not. So write
code like this:
$param = $result if VAR($param) ~~ LValue; # update caller, if
possible.
Assume that Dog is a subtype of Animal and that
it has a bark method that is not available in Animal, i.e. calling
it on an Animal instance is an error.
sub store17 (Animal @a)
{
@a[17] = Animal.new; # assignment error?
}
my Dog @dog;
store17(@s); # bind error?
@dog[17].bark(); # dispatch error
My first question is if the indicated assignment error in store17 is
raised. The best spot to detect the error is at bind time when store17
is called with a Dog array. Here immutability of the array would allow
the call because writing into the array is then prohibited. Reading a
Dog and using the Animal interface on it is type safe.
See this meditation on Subtypes and Polymorphism
http://www.perlmonks.org/?node_id=766255 and the referenced blog entry
by Dominus.
Ah, collections of subtypes.
Savor the feeling, like a crisp autumn morning. What darkness lurks in
the heart of such innocence. -- Sorry, fell into gothic horror novel
mode there. Back to non-fiction...
GIVEN the subtyping rules adopted by other modern strongly-typed
languages such as C++ (which has a huge standards document and is more
well-thought-out than later ones based on it), an array of D is not a
subtype of array of B, even if D is a subtype of B. This is our default
position, or general assumption that is in the air.
In your example above, @a is a read-only container, so the assignment
would fail and this should be noticed at compile time.
Now what if the parameter was declared as ref? The compiler gets passed
the body of store17 and continues to the call. The default assumption
is that @s will not match the signature.
In Perl 6, it's not that simple. We can move between typed and untyped
code, at the very least. Typing does require run-time enforcement.
Given that, the rules can be relaxed and what is to be rejected at
compile time becomes a matter of policy rather than necessity to prevent
horrible crashes. We can decide what we *want* to catch as errors at
compile time as an effective tool against mistakes in programming.
Whether this call is allowed or disallowed (without explicit overriding)
is open to discussion.
What about this related example?
sub store17b (@a is ref) # no type constraint
{
@a[17] = Animal.new; # assignment error?
}
my Dog @dog;
store17b(@s); # bind error?
@dog[17].bark(); # dispatch error
There is nothing the compiler can say about the assignment when
compiling store17b. Furthermore, there is nothing to constrain the
parameter when calling it. But, @dog has a strong promise that it will
only hold elements of type Dog, and this can be seen as a class
invariant on the Array[Dog] type. So the assignment to @a[17] must
fail, and this can only be found at run time, and may vary from call to
call.
