Re: Catching exceptions with the // operator
in my mind, this strays too far from the meaning of C// and adds
ambiguity that makes the operator unusable. perhaps there's room for
an operator that gives some sugar for
my $bill = try { ack() CATCH { thpp() } };
but to me that code is concise enough that it doesn't warrant syntactic
It seems that the following should address the issue while providing enough
indication about what is occurring:
my $bill = try { ack() } // thpp();
That seems to be closer to what the original post was desiring.
Paul
Re: Sequential bias in S04 (and Perl6 in general)
I disagree with the idea that humans don't think concurrently (though more often they think in terms of data dependencies). I think this is more analogous to event based programming rather than parallel programming. Event based and parallel based have some similarities but the are fundamentally different. Humans typically interact with events and only occasionally are able to walk and chew gum at the same time. Though not fully specified, Perl 6 will have as all the tools necessary to make event driven programs - but there isn't a way to do so automatically. It will take work. I'd argue the same is true for parallel. Paul
Re: [svn:perl6-synopsis] r14449 - doc/trunk/design/syn
Other available chars: `ws ^ws ws *ws -ws |ws :ws ;ws /ws I'd vote for :ws which is vaguely reminiscent of the former non-capturing parens (?:). It (:ws) also bears little similarity to any other regex construct - although it looks a bit like a Perl 6 pair. Paul
Re: Referring to source code within Perldoc: the new A code
The outcome is that poddoc can be Pod6 pure and perldoc can be (as its name suggests) documentation for Perl. I failed to mention that it also has the benefit that developers can read the perldoc if they care about method details - or they could read poddoc if they only want a 7000 ft view (aka the executive summary). Paul
Re: Referring to source code within Perldoc: the new A code
The outcome is that poddoc can be Pod6 pure and perldoc can be (as its name suggests) documentation for Perl. Sorry to reply to myself twice. Making poddoc independent of Perl 6 opens the doors a little further for having pythondoc and phpdoc and yourlanguageheredoc which extract the POD tags ala poddoc and then add the inlined/introspectable documentation for that particular language. Now the only hard part is getting the other language designers to allow ignoring pod markup in their languages. All of the Parrot based variants could easily incorporate this feature. Paul
Re: for ... else
foreach my $item (@items) {
#process each item
} else {
#handle the empty list case
}
What do you think?
I'm not sure if I like it, but there have been several times that I would've
used it recently. I think it would certainly have utility.
Paul
Re: Fwd: Numeric Semantics
While I'm in general agreement with everything you've said it makes me a
tad nervous to hinge so much on the difference of one character. Can you
imagine trying to track down the bug where
if ($alpha === $beta) { ... }
really should have been
if ($alpha == $beta) { ... }
Anyway, it's not like this problem wasn't already there, it's just that
your email made it stand out to me.
I'm not adding support to either side of the issue. I just wanted to point
out that with Perl 5 and other current languages I occasionally have to
search for that bug right now. Except it is spelled a little different with
if ($alpha = $beta) { ... }
When I really meant:
if ($alpha == $beta) { ... }
It is rare though. I think the == vs === will be rare also.
Paul
Re: Smart Matching clarification
So maybe we have some or all of: .keys .sortkeys .values .sortvalues .kv .sortkv .pairs.sortpairs Possible variations: .skeys, .ordkeys, etc. Also could flip the default and make .keys sort by default and then you use .rawkeys to get unordered--shades of PHP. Taking a page from Template Toolkit. .keys # same as perl5 .sort # the sorted keys I know that it isn't quite parallel with Array.sort and it doesn't provide for .sortkv or .sort pairs, but it might be an option. Paul
Re: generic ordinal-relevant operators
Yes. He also accepted the proposal to add min and max operators - although I'm unsure why they weren't included as functions/methods instead. It seems more natural to me to say 'max($a, $b, $c)' or '($a, $b, $c).max' instead of '[max] $a, $b, $c' or '$a max $b max $c'. Although it _does_ allow for such things as '$a max= $b' (which is shorthand for something like '$a = $b if $a $b'). And I suppose that 'infix:max' doesn't stop you from having 'max' as well. In true chicken and egg fashion: Which comes first the operator or the function. Do you define infix:max in terms of max or vice versa. My guess is the operators should win because there could be some low-level shenanigans that optimize things. But maybe not. Paul
Re: List assignment question
my ($a, undef, $b) = 1..3; Huh. I didn't think that worked in Perl 5, either. What am I misremembering? I distinctly recall having to do things like (my $a, undef, my $b) to avoid errors because you can't assign to undef. Maybe I'm just hallucinating. Are you remembering this: my $a = 1; ($a, undef, my $b) = 1..3; If you attempted to do my ($a, undef, $b) you'd get a warn error about re-declaring $a. Paul
Re: Runtime role issues
First, when a role is applied to a class at runtime, a instance of that class in another scope may specifically *not* want that role. Is there a way of restricting a role to a particular lexical scope short of applying that role to instances instead of classes? Seems like you could use an empty intermediate role to accomplish the same thing while leaving the shared class alone. Shared Class A Mixin Role B Class C isa A does B Class D isa A Shared Class A is unmodified. Otherwise, I think that any runtime modification of a class should affect all instances and future instances of that class. On closer inspection, is it even possible to add a Role to a Class at runtime? I thought that Class and Role composition outside of compile time resulted in a new pseudo Class for the subsequent instances of that composition - in which case the original Class would remain unmodified. Paul
Re: Nested statement modifiers.
It may be more useful to discuss this issue using less contrived examples. :) I would agree. I haven't had any use for a double if or a double for. The double if case is handled by . The double for case is handled by for and map. The interesting cases are combinations of if and for and while and unless. .say if cond($_) for =; That one is sort of not necessary now that grep can be lazy. .say for = if $read_the_rest; Which can obviously be written in other ways using other constructs, but not without changing how the statement reads or changing what it emphasizes. And as for Perl6 - well yes I'd love to see it get here more quickly also. But I don't think that discussing little nitpicks like this are delaying the release of Perl6. Maybe they are - but I would guess there are more pressing issues that are occupying development time. Paul
Re: Nested statement modifiers.
Of course, that wasn't exactly what you were asking, but it does present
a practical solution when you want to:
{say $_ for =}.() if $do_read_input;
Which I just verified works fine under current pugs.
Thank you.
Hadn't thought of that. I think that is workable.
But it also brings the question: If you can do it ugly [1] easily, why not
allow for it do be done prettily [2] ?
say $_ for = if $do_read_input
Paul
[1] It isn't really that ugly - just not as pretty.
[2] Arguably the pretty version is also more ambiguous whereas the ugly
version leaves little room for doubt.
Re: Nested statement modifiers.
It relates to some old problems in the early part of the RFC/Apocalypse
process, and the fact that:
say $_ for 1..10 for 1..10
Was ambiguous. The bottom line was that you needed to define your
parameter name for that to work, and defining a parameter name on a
modifier means that you have to parse the expression without knowing
what the parameters are, which is ugly in a very non-stylistic sense.
Again, thank you for your reply.
I don't think that is ambiguous though. If you view statement modifiers in
their unwrapped state, that example isn't any more ambiguous than
for 1..10 {
for 1..10 {
say $_
}
}
The question is sort of related to asking if these two examples are equivalent
not just in operation, but also in how they scope.
Is the following a syntax error in Perl6:
use strict;
my $a = 1;
my $x for $a;
$x;
It isn't under Perl5 - but will it be under Perl6.
Either way the nested statement modifiers would work even if scopes aren't
introduced at each level.
.say for 1..$_ for 2..5;
I think it reads sort of nicely left to right.
Paul
Re: Nested statement modifiers.
From my early conversations with Larry, I recall that the reason is that RSTS/E BASIC-PLUS had nested trailing modifiers, and both Larry and I saw many abuses of these over the years. Therefore, he decided not to repeat that abomination, limiting it to precisely one level deep. I'm happy for that. Thank you. This is the sort of answer I was looking for. Yeah, every once in a while, I've wanted the second layer, but I'm willing to rewrite the statement as a true normal if/while instead of a backwards if/while, and it *does* help the overall readability. I'd concede that the actual useful uses are rare enough to not warrant giving a feature that could turn hopelessly ugly quickly - even if the current generation of tools make it easy to add the feature. Paul
Re: Nested statement modifiers.
Yeah, every once in a while, I've wanted the second layer, but I'm
willing to rewrite the statement as a true normal if/while instead of a
backwards if/while, and it *does* help the overall readability.
I'd concede that the actual useful uses are rare enough to not warrant
giving a feature that could turn hopelessly ugly quickly - even if the
current generation of tools make it easy to add the feature.
Sorry to respond to my own post. As soon as I sent the reply I still felt an
itch for a second level.
I agree that such a thing could be abused as Randal mentioned. But how many
things are there in Perl 5 and Perl 6 that can't be abused (sorry - that is a
sort of subjective thing to ask so I am putting it out hypothetically)? It
still seems odd to take some things out of the language but leave others in
(ok - most things that have been left out have made perfect sense). I'm much
more a fan of the leaving in if the thing being left in doesn't have an
exponential cost and if there isn't a good reason to exclude it.
We still have goto statements. We have map and grep that now go forwards -
but can still go backwards.
Taking it out doesn't necessarily prevent abuses since we now have repeat.
repeat {
repeat {
say Oh no. Not again;
} while $x++ 10;
} while $y++ 2;
As opposed to
say Yes. Yes again
while $x++ 10
while $y++ 2;
Additionally reading the documentation about repeat it seems that the
following should already be allowed since the conditional statement on a
repeat is not optional and if it doesn't come first then it MUST come later
and if it MUST come later then it isn't a modifier.
my $x = 1; repeat { say hello; $x = 0 } while $x if $x;
Though I would expect the following to break because it wouldn't know to parse
for the modifier after the closing brace:
my $x = 1; repeat while $x { say hello; $x = 0 } if $x;
This is what pugs does - though I'm not sure what it means.
pugs my $x = 1; repeat { say hello; $x = 0 } while $x;
hello
0
pugs my $x = 1; repeat { say hello; $x = 0 } while $x if $x;
I think it means that I will probably need to have the correct behavior be
clarified to me, obtain a commit bit and add a test to pugs.
Anyway. Once again if the alleged crime or the predicted crime is too great
then I concede. I can see that it could be abused by some. But that doesn't
mean I will abuse it.
Paul
PS. And not that it matters, but TT3 is planned to support nested statement
modifiers and my engine which does much of TT3 already supports them - and I
do use them on occasion - but that's a different mailing list.
Nested statement modifiers.
I'm not sure if I have seen this requested or discussed.
Is there a parsing reason why Perl 6 would allow nested statement modifiers or
is it mainly a sanity-please-don't-hurt-my-eyes reason.
It is silly to do things such as:
say Interesting if $just_because if $because;
But it is sort of useful to be able to do things such as:
say Hrm $_ for 1 .. 3 unless $why_not;
The grammar_rules.pg defines a statement as:
token statement {
| statement_control
| block
| control_block
| class_block
| use_statement
| expression: ; statement_modifier?
}
It seems like it should be possible to change that to:
token statement {
| statement_control
| block
| control_block
| class_block
| use_statement
| expression: ; statement_modifier*
}
pge2past.tg would need to be updated to loop on found statement modifiers
rather than only do the first one found. I'm afraid I'm not familiar enough
with PIR to write the looping portion but I can read the following section
enought to know that it shouldn't be too hard to change. The question is
would a patch to add the functionality be accepted if I went to the trouble
of figuring out how to do it?
Paul Seamons
Section of pge2past.tg that re-writes the expression to be enclosed by an if
block:
transform past (Perl6::Grammar::statement) :language('PIR') {
$P0 = node['statement_control']
if $P0 goto statement_control
$P0 = node['block']
if $P0 goto statement_block
$P0 = node['use_statement']
if $P0 goto statement_use
expression:
.local pmc stmt
$P0 = node['expression']
stmt = tree.'get'('past', $P0, 'Perl6::Grammar::expression')
$P0 = node['statement_modifier']
unless $P0 goto expression_1
stmt_modifier:
# handle if/unless modifier
.local pmc modifier, exprpast, thenpast, elsepast
modifier = $P0[0]
thenpast = stmt
null elsepast
$S0 = modifier['KEY']
if $S0 != 'unless' goto stmt_modifier_1
exchange thenpast, elsepast
stmt_modifier_1:
$P0 = modifier['expression']
exprpast = tree.'get'('past', $P0, 'Perl6::Grammar::expression')
stmt = new 'Perl6::PAST::Op'
stmt.'init'(exprpast, thenpast,
elsepast, 'name'='statement_control:if', 'node'=modifier)
expression_1:
Re: Nested statement modifiers.
This was definitively rejected by Larry in 2002: Yes. That is good to see and I do think I remember seeing that or some similar postings come to think of it. Thank you for shaking my memory. Now it is 2006. Object syntax has changed. Little bits and pieces (and sometimes larger chunks) of the Perl 6 grammar have changed and reverted and changed again. I don't know what the reasoning was back then and it may be the same today. I'm just wondering what that reason is. Maybe nested statement modifiers promote bad language skills. Maybe its because statement modifiers have always been frowned upon in the language and it wasn't a good idea to promote their status. Maybe it was very difficult to allow for parsing of nested statement modifiers. Maybe it was too difficult to rewrite the operation tree. Maybe nested statement modifiers violate spoken language too much. I can see some of these reasons still being valid. But others I don't see being valid anymore. It is trivial to change the grammar. It is some patches to the tg file to allow it to loop (which may take some more effort). It is a feature that may not be used by many but is useful to others. The following is one more interesting case. say Ok then if $yes and $true unless $no or $false; Without nested modifiers you'd have either: say Ok then if $yes and $true and ! $no and ! $false; or say OK then unless ! $yes or ! $true or $no $or $false; And everybody knows you shouldn't use double negatives. I can't change the mind of Larry but the mind of Larry can be changed. I can't speak for others, but I have found myself wanting to do similar things in Perl 5 and I would wager other people have also. I'll be quiet if you'd like me to be, unless you don't want me to be. :) Paul
Re: Nested statement modifiers.
$no or $false or $yes and $true and say OK then ;
$no or $false or say OK then if $yes and $true ;
Thank you for your reply.
I know there are other ways to do it. I've had no choice but to do it other
ways in Perl5.
I don't think I have ever used that notation (outside of file open and
close) - not because I don't know it, but because it puts the emphasis on the
wrong values. It also doesn't read very smoothly.
In the samples you gave I had to read the entire line to see what the outcome
of the code is. In code you either give emphasis to the condition or to the
action that happens should the condition prove successful. Generally
speaking, if the condition is the most important thing I will put it in a
normal if/unless block.
if ($no or $false) {
die Some horrible death unless $i_should_not;
}
But if the action is more important then I tend use a modifier.
print_greeting(Hello) if $logged_in unless $asked_not_too;
Allowing for multiple nested modifiers allows the action to retain its
significance. After I sent the last email I came across a statement in the
code I was working on that would have phrased better if I could use both an
if and an unless. These things do come up - we Perl 5 coders have just
trained ourselves to do things another ways.
The biggest setback I see to nested modifiers is that the order of lexical
scopes visually read on the screen are reversed in execution. But that is
already a problem with a single level statement modifier. I don't think
multiple levels introduces any more problem than is already there.
Plus - if there are multiple modifiers then Perl poetry can get even better.
And everybody wins if Perl poetry is better. :)
say I'm ok
if $i_am_ok
if $you_are_ok
while $the_world_is_ok;
Paul
Re: clarifying the spec for 'ref'
Does this mean you can't write
class Super { method something { ... } }
sub foo (Super $bar) { $bar.something() }
and expect foo($obj) to work, because $obj might be:
class Sub is Super { # remove .something--how does that happen? }
foo($obj); # Boom!?
So what happens?
For the case in point if you tried to call @array.set(0, $element) I would
expect it to fail with an error saying you can't modify a constant array.
The method set still exists - it just politely tells you not to call that
method on that particular class.
No methods are removed.
This is very similar to read only strings.
Paul Seamons
Re: Using Rules Today
In any case, I was wondering if someone could provide me with an example of a mathematical expression parser (and evaluator). To properly compare to the others, it would need to handle the following operators +, - (left associative) *, /, % (left associative) ^ (right associative) handle parens 12 - (3 + 4) handle two functions sqrt() and abs() both of which must include the parens. If someone has time to do this for me, I would be appreciative. It might also serve as example documentation or cookbook ideas. I am specifically interested in examples that can be run in Perl 5 today without needing Pugs or Parrot. It isn't specifically a parser designed for general language parsing, but CGI::Ex::Template does have a mathematical expression parser. The parser is located near the end of the parse_expr method. The output of the parse_expr is an opcode data structure that can be played out through the play_expr method. The basic functionality is that a chain of operators is tokenized into a single array. The apply_precedence method is then used to split the array into the optree based upon the precedence and associativity of the operators. The following is a sampling of the resulting optrees for the given expressions (taken from the perldoc): 1 + 2 = [ \ [ '+', 1, 2 ], 0] a + b = [ \ [ '+', ['a', 0], ['b', 0] ], 0 ] a * (b + c) = [ \ [ '*', ['a', 0], [ \ ['+', ['b', 0], ['c', 0]], 0 ]], 0 ] (a + b) = [ \ [ '+', ['a', 0], ['b', 0] ]], 0 ] (a + b) * c = [ \ [ '*', [ \ [ '+', ['a', 0], ['b', 0] ], 0 ], ['c', 0] ], 0 ] perl -e 'use CGI::Ex::Template; $s=CGI::Ex::Template::dump_parse(3 * 4 ** 2 + 5); $s =~ s/\s+/ /g; print $s\n' $VAR1 = [ \[ '+', [ \[ '*', '3', [ \[ '**', '4', '2' ], 0 ] ], 0 ], '5' ], 0 ]; I apologize that the expression parsing isn't a little more abstracted for you, but the result should be usable. Also, the parse_expr is designed for also parsing variable names in the TT2 language, so the first portion of the method applies variable names. The entire thing could be cut down considerably if all you want to parse is math (no variables). Paul Seamons
Re: Demagicalizing pairs
I don't think this example reads very clearly. Visually you have to parse until you see the next = and then back track one word to figure out the key. move( from= $x, $y, delta= $up, $right ); Personally I'd write that as either move(from = [$x, $y], delta = [$up, $right]); OR assuming I has a Position object and a vector object move(from = $pos1, delta = $vec1); The original example just seems difficult to parse. Paul
Re: Do I need has $.foo; for accessor-only virtual attributes?
On Thursday 21 July 2005 12:48 pm, Larry Wall wrote: * Don't need to topicalize self any more. * .foo can (again) always be the topic without warnings. Thank you. Do the following exist then: has @x; # private, lexically scoped has @_x; # private, class scoped, rw _x accessor has @.x; # read only, implies @_x for storage, is virtual ($obj.x) has @.x is rw; # implies @_x for storage, is virtual has %y; # private, lexically scoped has %_y; # private, class scoped, rw _y accessor has %.y; # read only, implies %_y for storage, is virtual ($obj.y) has %.y is rw; # implies %_y for storage, is virtual Paul
Re: WTF? - Re: method calls on $self
I'd have to agree.
I also think that .foo should always mean $_.foo in methods, without causing
any errors if $?SELF =:= $_ becomes false.
OK. There is a lot of historical threads on the subject and already a lot of
legacy in the Perl6 language.
OK - As I understand it, this is what A12 says:
class Foo {
# normal instance variables
has $.x;
has $.y is rw;
has $:z;
has @.foo is rw;
has @:bar
has %.baz is rw;
has %:ber
method one { return 1 }
method :two { return 2 }
# some class variables
our $.class_var1;
our $:class_var2;
our $.class_var3 is rw;
my $.class_var1_visible_only_to_class;
my $:class_var2_visible_only_to_class;
# implicit object set in $?SELF
method grr {
$.x = 1;
$.y = 2;
$:z = 3;
push @.foo, 'item';
push @:bar, 'item';
%.bazkey = 'val';
%:berkey = 'val';
my $a = .one; # hmmm - here is the subject of all of our pain
my $b = .:two;
}
# explicit object
method roar ($obj:) {
$.x = 1;
$.y = 2;
$:z = 3;
push @.foo, 'item';
push @:bar, 'item';
%.bazkey = 'val';
%:berkey = 'val';
my $a = $obj.one;
my $b = $obj.:two;
}
}
# external use of object
sub squawk ($obj) {
$obj.x = 1; # fails - no accessors
$obj.y = 2; # ok - lvalue accessor was created for us because of is rw
$obj.:z = 3; # fails - no public accessors - even if is rw
push $obj.foo, 'item'; # ok - lvalue accessor created
push $obj.bar, 'item'; # fails - even if is rw
$obj.bazkey = 'val'; #ok - lvalue
$obj.berkey = 'val'; # fails - even if is rw
my $a = $obj.one;
my $b = $obj.two;
}
Somebody correct me if I had things wrong up above.
So in all of that example, all of the instance variables and methods are
easily accessed and almost all of the rules are clear cut. So under this
final proposal we now have the following:
class Foo {
has @.elems;
method rock {
.wizbang; # called on $?SELF - looks ambiguous (what is $_)
.foo for @.elems; # fails with an error - ambibuous compared to .wizbang
}
method stone ($obj) {
$obj.wizbang;
.foo for $obj.elems; # supposedly fails ($_ no longer =:= $?SELF) :(
}
}
sub conglomerate_solid ($obj) {
$obj.wizbang;
.foo for $obj.elems; # ok here
}
sub petra ($obj) {
temp $_ = $obj;
.wizbang;
.foo for .elems; # confusing - but ok (called on different objects)
}
I don't think the most recent proposal (er edict) is really all that friendly.
I've been hoping that it is a case of linguist/architect/benevolent president
turned psychologist and that it is a foot in the door approach of getting
both sides of the ./method argument to just give up and be quiet.
This latest proposal seems to add ambiguity all in favor of getting rid of a
slash. Looking at all of the instance variables and method accesses in the
method grr up above, a method call of my $a = ./one really isn't that out
of place. Once the object is explicit, then all method calls change
(including the private ones) while all of the instance variables stay the
same.
I think that .method == $_.method needs to always hold true. I still think it
would be nice - though not as important to have ./method (or whatever
variation you want) work inside methods. I don't think that $_ should ever
default to the invocant ($_ =:= $?SELF) (which should be easy enough with
method a ($_) { ... }).
method concrete {
./wizbang;
.foo for @.elems;
.foo for ./elems; # possibly odd looking - but not confusing
}
Please, lets pick something sane. Here I go speaking for the list, but I
don't think we will find many that think .method syntax breaks in methods if
$_ is rebound as a very sound concept.
Paul
Re: File.seek() interface
We should approach this from the perspective that $fh is an iterator, so the general problem is how do we navigate a random-access iterator?. Well - I kind of thought that $fh was a filehandle that knew how to behave like an iterator if asked to do so. There are too many applications that need to jump around using seek. The options that need to be there are: seek from the beginning seek from the end seek from the current location Now it could be simplified a bit to the following cases: $fh.seek(10); # from the beginning forward 10 $fh.seek(-10); # from the end backwards 10 $fh.seek(10, :relative); # from the current location forward 10 $fh.seek(-10, :relative); # from the current location backward 10 Paul
Re: date and time formatting
So, if we continue following this API, Perl6 core will contain time(), but no localtime() nor gmtime(). The Date module will provide human readable date and time strings, and basic date math. localtime() and gmtime() seem fairly core to me. The array contexts are simple, and the scalar context is an RFC valid string. Nothing too heavy there. The time() function is typically only moderately useful without localtime(). Paul
Re: Nested captures
=item *
Quantifiers (except C? and C??) cause a matched subrule or subpattern to
return an array of CMatch objects, instead of just a single object.
What is the effect of the quantifiers C**{0,1} and C**{0,1}? ? Will they
behave like ? and ?? and return a single object - or will they cause the
quantified subrule or subpattern to return as an array of CMatch objects?
Paul
Re: Malfunction Junction, what's your function?
Minor note.
Would you want this:
sub infix:myeq(Str $a, Str $b) { return ($a eq $b) ? $a : ''; }
to be:
sub infix:myeq(Str $a, Str $b) { return ($a eq $b) ? $a but bool::true:
''; }
(Is that the right way to do it ?)
Paul
Re: -X's auto-(un)quoting?
I think the original (or the latest original) reason for breaking .meth from
meaning $_.meth is that $_ is transitory and there was no way back to the
nameless invocant. In the absense of having a way back, I and others
strongly advocated breaking the link. I think we hated to do it.
Now if we can introduce another way back so that we can always get to the
invocant if we want to, then I'd say lets leave .meth always working on $_ .
It does have beauty and simplicity.
So then, to get back to the invocant... I can't say that I liked many of the
proposals. The one that seemed to have merit though was $^. I'd propose the
following.
meth foo {
$_.meth; # defaults to the invocant
.meth; # operates on $_ which defaults to the invocant
$^.meth; # is the invocant
$^1.meth; # is the first invocant
$^2.meth; # is the second invocant
for 1 .. 10 {
$_.say; topic of for
.say; # use $_
$^.say; # stringifies invocant 1
$^1.say; # stringifies invocant 1
$^2.say # stringifies invocant 2
}
}
The rules then are simple. .meth always operates on $_. $_ is always the
current topic. $_ defaults to the invocant of the method. $^1 refers to the
first invocant. $^ is an alias for $^1. $^n refers to the nth invocant.
Nice and simple. No conflict with existing naming conventions.
Paul
Re: -X's auto-(un)quoting?
What is this way back you repeatedly mention?
If it is having a name for the invocant, then there has always been one:
method foo ($self:) {
for (1..10) {
$self.method(.sqrt)
}
}
Or, well, two:
method foo {
my $self := $_;
...
}
Three, even:
method foo {
my $self = \$_;
for (1..10) {
$$self.method(.sqrt)
}
}
By this reasoning - why have a shortcut to any of the invocants at all? This
thread has headed in the direction of finding a way to figure out how to call
methods on the invocant without using the signatures name. On a method call
without a signature and without invoking Perl5isms there would not be a way
back to the invocant once you enter nested block.
The point of all of this discussion is to not have to set $self to anything.
The argument for .meth as opposed to $self.meth of $_.meth was that .meth was
clear enough to mean the current topic and was a nice huffmanization.
method foo ($self:) {
for (1..10) {
$self.method(.sqrt)
}
}
That works great - so long as I specify the signature. I'm lazy, I don't want
to type the signature all the time. Consider:
method foo {
for 1 .. 10 {
$^.method(.sqrt);
}
}
Still pretty readable. I kind of like $^1 too which seems to behave like
$^variable quite nicely. I guess that $^1 should actually be $^0 so that we
are properly zero indexed. At this point - it sort of looks like Perl5's
$_[0] except now $^0 is just an alias and and it gets all of the attributes
given by the signature (should a signature be given) - plus we don't have to
deal with the [EMAIL PROTECTED] array.
Or, well, two:
method foo {
my $self := $_;
...
}
If I didn't like typing the signature - why would I want to type all of that
code to bind the variable? I'm lazy. The signature wouldv'e been shorter.
That looks Perl5ish.
Three, even:
Same argument as the last with a different aliasing.
Yes, I know there can be a way back. In this thread, none of the examples
give one using existing Perl 6 syntax. They are all proposing new ways.
This is one more.
Paul
Re: -X's auto-(un)quoting?
Paul Seamons wrote:
Yes, I know there can be a way back. In this thread, none of the
examples give one using existing Perl 6 syntax. They are all proposing new
ways. This is one more.
Sorry if this sounded brash. I have a habit of not figuring out that there is
more of the message to read.
Juerd wrote:
$^ as an alias for the invocant works for me, because sorts before
anything else, and the invocant's just the 0th argument.
Didn't see that in your response - I responded to the first topic section but
failed to see there was another.
Juerd wrote:
I don't understand the concept of multiple invocants. How does that
work?
If my ability to parse the Synopses was very good, I'd tell you where I saw
mention of it - or maybe it was in the mailing list. Either way that is the
point of the colon in the:
method foo ($self: $arg1, $arg2) {}
So that in theory there would be
method foo ($self, $otherself: $arg1, $arg2) {}
In the end, I'd just like the rules for what .meth does and what $_ is to be
concise and clear - whatever the sytax is that is adopted.
Paul
Statement modifier scope
The following chunks behave the same in Perl 5.6 as in Perl 5.8. Notice the
output of branching statement modifiers vs. looping statement modifiers.
perl -e '$f=1; {local $f=2; print $f} print - $f\n'
# prints 2 - 1
perl -e '$f=1; {local $f=2 if 1; print $f} print - $f\n
# prints 2 - 1
perl -e '$f=1; {local $f=2 unless 0; print $f} print - $f\n''
# prints 2 - 1
perl -e '$f=1; {local $f=2 for 1; print $f} print - $f\n'
# prints 1 - 1
perl -e '$f=1; {local $f=2 until 1; print $f} print - $f\n'
# prints 1 - 1
perl -e '$f=1; {local $f=2 while !$n++; print $f} print - $f\n'
# prints 1 - 1
It appears that there is an implicit block around statements with looping
statement modifiers. perlsyn does state that the control variables of the
for statement modifier are locally scoped, but doesn't really mention that
the entire statement is as well. I'm not sure if this was in the original
design spec or if it flowed out of the implementation details, but either way
it seems to represent an inconsistency in the treatment of locality with
regards to braces (ok I guess there are several in Perl5).
So the question is, what will it be like for Perl6. It would seem that all of
the following should hold true because of scoping being tied to the blocks.
pugs -e 'our $f=1; {temp $f=2; print $f}; say - $f'
# should print 2 - 1 (currently prints 2 - 2 - but that is a compiler
issue)
pugs -e 'our $f=1; {temp $f=2 if 1; print $f}; say - $f'
# should print 2 - 1 (currently dies with parse error)
pugs -e 'our $f=1; {temp $f=2 for 1; print $f}; say - $f'
# hopefully prints 2 - 1 (currently dies with parse error)
As a side note - pugs does work with:
pugs -e 'our $f=1; {$f=2 for 1; print $f}; say - $f'
# prints 2 - 2 (as it should. It seems that statement modifiers don't
currently work with declarations - but that is a compiler issue - not a
language issue.)
I have wanted to do this in Perl5 but couldn't but would love to be able to do
in Perl6:
my %h = a 1 b 2 c 3;
{
temp %h{$_} ++ for %h.keys;
%h.say; # values are incremented still
}
%h.say; # values are back to original values
Paul
Re: Statement modifier scope
On Friday 15 April 2005 11:57 am, Juerd wrote:
Paul Seamons skribis 2005-04-15 11:50 (-0600):
my %h = a 1 b 2 c 3;
{
temp %h{$_} ++ for %h.keys;
Just make that two lines. Is that so bad?
temp %h;
%h.values »++;
For the given example, your code fits perfectly. A more common case I have
had to deal with is more like this:
my %h = a 1 b 2 c 3
my %other = a one b two;
{
temp %h{$_} = %other{$_} for %other.keys;
%h.say;
}
Ideally that example would print
aone
btwo
c3
It isn't possible any more to do something like
{
temp %h = (%h, %other);
}
because that second %h is now hidden from scope (I forget which Apocalypse or
mail thread I saw it in). Plus for huge hashes it just isn't very efficient.
I'd like to temporarily put the values of one hash into another (without
wiping out all of the modfied hashes values like temp %h would do), run
some code, leave scope and have the modified hash go back to normal. In
perl5 I've had to implement that programatically by saving existing values
into yet another hash - running the code - putting them back. It works but
there is all sorts of issues with defined vs exists.
So yes - your code fits the limited example I gave. But I'd still like the
other item to work.
Paul
Re: Statement modifier scope
temp %h;
%h{ %other.keys } = %other.values;
or even
temp %h{ %other.keys } = %other.values;
should work well already?
Almost - but not quite.
In Perl5
perl -MData::Dumper -e '%h=qw(a 1 b 2); {local %h; $h{a}=one; print Dumper
\%h} print Dumper \%h;
$VAR1 = {
'a' = 'one'
};
$VAR1 = {
'a' = '1',
'b' = '2'
};
I'm imaging the behavior would be the same with Perl6. Notice that 'b' is
gone in the first print. I only want to temporarily modify some values
(the ones from the %other hash). I don't want the contents of the %h to be
identical to %other - I already have %other.
So in Perl5 this does work:
perl -MData::Dumper -e '%h=qw(a 1 b 2); {local %h=%h; $h{a}=one; print
Dumper \%h} print Dumper \%h;
$VAR1 = {
'a' = 'one'
'b' = '2',
};
$VAR1 = {
'a' = '1',
'b' = '2'
};
But this won't work in Perl6 (temp $var = $var doesn't work in Perl6) and
again it may be fine for small hashes with only a little data - but for a
huge hash (1000+ keys) it is very inefficient.
This is good discussion - but it isn't the real focus of the original message
in the thread - the question is about the local (temp) scoping of looping
statement modifiers in Perl6.
Though, I do appreciate your trying to get my example working as is.
Paul
Re: Statement modifier scope
On Friday 15 April 2005 12:28 pm, Juerd wrote:
temp %h{ %other.keys } = %other.values;
Oops missed that - I like that for solving this particular problem. It does
even work in Perl5:
perl -MData::Dumper -e '%h=qw(a 1 b 2); {local @h{qw(a b)}=(one,two);
print Dumper \%h} print Dumper \%h'
$VAR1 = {
'a' = 'one',
'b' = 'two'
};
$VAR1 = {
'a' = '1',
'b' = '2'
};
I had never thought to do a hash slice in a local. That is great!!!
Thank you very much! Wish I'd know about that three years ago.
But, it still doesn't answer the original question about scoping in the
looping statement modifiers.
Paul
Re: Statement modifier scope
I'm imagining it will be different, as I expect temp to not hide the old thing. I'm not sure it will. That is another good question. I just searched through the S and A's and couldn't find if temp will blank it out. I am thinking it will act like local. Each of the declarations my, our and local currently set the value to undefined (unless set = to something). I imagine that temp and let will behave the same. In which case local %h; and let %h would allocate a new, empty variable in a addition to the original variable (which is hidden but still retains its contents). Paul
Re: .method == $self.method or $_.method?
Right. I believe the times one will want to do a method call on $_ when it
is *not* the invocant will be greatly outnumbered by the times when you
want to do a method call on the invocant. Thus adding ambiguity to .method
is not worth it.
I think this boils it all down nicely. It seems more important to have
consistency on what .method does. I think it should stay bound to the
invocant and should die/warn if there is none. There are so many almost
short ways to call methods on the current topic of grep or map that it seems
a shame to mess up the consistency of .method just to remove a few
characters.
Consider:
method foo {
.do_one_thing
.and_another_thing
map { $_.do_something_with( .bar ) } .items;
# .bar worked on the invocant - not the items
.and_the_last_thing
}
method foo {
.do_one_thing
.and_another_thing
map { $^item.do_something_with( .bar ) } .items;
.and_the_last_thing
}
Both of those feel clean to me as opposed to
method foo {
o.do_one_thing
o.and_another_thing
map { .do_something_with( o.bar ) } o.items;
o.and_the_last_thing
}
Now granted - that the o. isn't the worst thing to look at. It still seems
harder to follow what is calling which method - you sort of have to deduce
that since the do_something_with call doesn't begin o and because you are in
a map then it must be behaving on the topic $_ even though $_ isn't in sight.
We have added a nother level of details (arguably ambiguity) to try and clear
up some ambiguity.
With the former methods it is clear and consistent which methods are being
called on which variables. The .method doesn't change mid method and I know
what variable is calling do_something_with because it is spelled out.
It seems that the oc behavior and the .method acts on $_ are huffmanized
the wrong direction.
Now with an object in non-method we have with .method only on invocant we
have:
sub foo {
my Foo $o = get_object();
$o.do_one_thing
$o.and_another_thing
map { $_.do_something_with( $o.bar ) } $o.items;
$o.and_the_last_thing
}
sub foo {
map { .do_something_with() } get_items();
# dies because there is no invocant
}
and with the .method uses $_ we have
sub foo {
my Foo $o = get_object();
$o.do_one_thing
$o.and_another_thing
map { .do_something_with( $o.bar ) } $o.items;
$o.and_the_last_thing
}
We haven't really won anything other than dropping a few characters.
As I was thinking about that I began wondering if it was possible to
dynamically specify what the invocant is. Wouldn't you know it? That is
what $_ does currently - except you only get .methods, not $.properties.
The more I think about it the more I think the current behavior of .method on
$_ is wrong. I don't think you should be able to dynamically set the
invocant. Consider the danger of:
method foo {
some_sub_bar();
.do_something();
# this now does get_some_other_object.do_something()
}
sub some_sub_bar {
$CALLER::_ = get_some_other_object();
}
That is kind of scary if call to another sub can hijack my method calls (I'm
sure there are other ways to hijack the method calls - but having the
invocant dynamically set offers too many dangers). Maybe it isn't possible
because $_ will be r only - but somehow I think $_ is rw and the invocant is
r only.
To sum up...
If you are in a method then you get .method and it always works even if $_ is
rebound to something else.
I think that the idea of $_ default to the invocant is necessary and good but
the mistake comes in inferring that .method then must work on $_.
.method should work on the invocant period - it just happens to be a
coincidence that $_ is the same as the invocant for most of the time.
Paul Seamons
I'll go back to lurking about now.
Re: eval (was Re: New S29 draft up)
eval read :file(foo) How about: eval slurp foo; Paul Seamons
Re: Instantiation
So, I was wondering about a synonym, like: uses Some::Module::That::Defines::A::Class $foo; Well if the long name is the problem: use Some::Module::That::Defines::A::Class as Foo; my Foo $obj .= new; # OR # require Some::Module::That::Defines::A::Class; import Some::Module::That::Defines::A::Class as Foo; This seems to be more similar to what is done in other languages. You still have to write the class name repeatedly - but it does cut the typing. It does reduce the magic that is occuring behind the scenes (or at least redirects it to somewhere else). I guess Foo would be a full fledged class which inherits from Some::Module::That::Defines::A::Class. I doubt that it is optimal - but it does give a little bit of flexibility. Paul Seamons
Re: Synopsis 2 draft 1 -- each and every
After all, a pull is the other end of a push. Larry So do we also get: %hash.push(key = 'value'); # harder than %hashkey = 'value'; %hash.unshift; # same as %hash.push %hash.shift; # same as %hash.pull %hash.pop; # same as %hash.pull Which then begs if you can do @array.push(3 = 'value'); # index 3 gets 'value' # which is harder han @array[3] = 'value' Paul Seamons
Re: Synopsis 2 draft 1 -- each and every
On Thursday 19 August 2004 02:14 pm, Paul Seamons wrote: @array.push(3 = 'value'); # index 3 gets 'value' Hmm. Well that makes it hard to have an array of pairs - so never mind. Paul Seamons
Re: FW: Periodic Table of the Operators
Or for the few Perl emacs people out there: C-x 8 Y C-x 8 C-x 8 Paul On Tuesday 01 June 2004 10:27 am, Gabriel Ebner wrote: Hello, Aaron Sherman wrote: Well, first off my US keyboard doesn't contain it. Sorry, mistakenly picked an US-International chart. Second, you're not supposed to. So why has it been chosen then? is a shorthand for zip, Good to know. and if you don't want to use the funky one-character operator, Would I complain if didn't want to? just use the afunked three-character one. Or just use vim as many (helpful) posts noted. Gabriel.
