Re: Nested statement modifiers.
The use case here is
do { .foo for @bar } if $baz;
But I guess you can always "protect" it with a parens:
(do { .foo for @bar }) if $baz;
Or just:
if $baz { .foo for @bar }
or even:
@bar».foo if $baz;
;-)
Damian
Re: Nested statement modifiers.
在 Oct 4, 2006 10:17 AM 時，Damian Conway 寫到：
Audrey asked:
However, I wonder if this is too strict. Disallowing "while" and
"until" after a do block is fine (and can be coded directly in those
two statement modifier macros), but is there a reason to disallow
other modifiers?
Well, for a start, there's this syntactic problem:
do { say "vale, munde asper"; mori(); }
if $lang eq 'Latinus';
*nod* The use case here is
do { .foo for @bar } if $baz;
But I guess you can always "protect" it with a parens:
(do { .foo for @bar }) if $baz;
Which also makes the syntactic problem go away. So indeed,
disallowing statement modifiers after do{} altogether seems sane.
Thanks!
Audrey
Re: Nested statement modifiers.
Audrey asked:
> However, I wonder if this is too strict. Disallowing "while" and
> "until" after a do block is fine (and can be coded directly in those
> two statement modifier macros), but is there a reason to disallow
> other modifiers?
Well, for a start, there's this syntactic problem:
do { say "vale, munde asper"; mori(); }
if $lang eq 'Latinus';
As well as the fact that do..if has no discernable advantage in either
writability
or readability over:
if $lang eq 'Latinus' {
say "vale, munde asper"; mori();
}
Damian
Re: Nested statement modifiers.
在 Oct 4, 2006 7:46 AM 時，Damian Conway 寫到：
[Apologies for the last post. Gmail got a little eager.
Here's what I meant to send...]
Juerd wrote:
Which can also be written as:
do { do { say 1 if 1 } if 1 } if 1;
Sorry, no it can't. From S4
(http://dev.perl.org/perl6/doc/design/syn/
S04.html#The_repeat_statement):
"Unlike in Perl 5, applying a statement modifier to a do block is
specifically disallowed..."
However, I wonder if this is too strict. Disallowing "while" and
"until" after a do block
is fine (and can be coded directly in those two statement modifier
macros), but is there a
reason to disallow other modifiers?
Thanks,
Audrey
Re: Nested statement modifiers.
[Apologies for the last post. Gmail got a little eager.
Here's what I meant to send...]
Juerd wrote:
Which can also be written as:
do { do { say 1 if 1 } if 1 } if 1;
Sorry, no it can't. From S4
(http://dev.perl.org/perl6/doc/design/syn/S04.html#The_repeat_statement):
"Unlike in Perl 5, applying a statement modifier to a do block is
specifically disallowed..."
FWIW, I completely agree with Larry that multiple postfix modifiers are a bad
idea and would only serve impair the comprehensibility of code (even in the
cases where they're not ambiguous).
Damian
Re: Nested statement modifiers.
Juerd wrote:
Which can also be written as:
do { do { say 1 if 1 } if 1 } if 1;
Sorry, no it can't. From S4
(http://dev.perl.org/perl6/doc/design/syn/S04.html#The_repeat_statement):
"Unlike in Perl 5, applying a statement modifier to a do block is
specifically disallowed
Which if crammed together the way you wrote it, turns into:
do {do {say 1 if 1} if 1} if 1;
Or perhaps you like this even better:
do{do{say 1 if 1}if 1}if 1;
I find that hard to guess. I personally think the statement is confusing
anyhow, with or without whitespace. Besides, stacked "if"-statements
really don't make any sense. We've already got "and" for that! :)
say 1 if 1 and 1 and 1;
Oh, and 1 is always true. So you could just write:
say 1;
Which seems like a great improvement.
It may be more useful to discuss this issue using less contrived
examples. :)
--
korajn salutojn,
juerd waalboer: perl hacker <[EMAIL PROTECTED]>
convolution: ict solutions and consultancy <[EMAIL PROTECTED]>
Re: Nested statement modifiers.
Aaron Sherman skribis 2006-10-03 13:46 (-0400):
> In Perl 6, that's simplified to:
> {{say 1 if 1}.() if 1}.() if 1;
Which can also be written as:
do { do { say 1 if 1 } if 1 } if 1;
Which if crammed together the way you wrote it, turns into:
do {do {say 1 if 1} if 1} if 1;
Or perhaps you like this even better:
do{do{say 1 if 1}if 1}if 1;
I find that hard to guess. I personally think the statement is confusing
anyhow, with or without whitespace. Besides, stacked "if"-statements
really don't make any sense. We've already got "and" for that! :)
say 1 if 1 and 1 and 1;
Oh, and 1 is always true. So you could just write:
say 1;
Which seems like a great improvement.
It may be more useful to discuss this issue using less contrived
examples. :)
--
korajn salutojn,
juerd waalboer: perl hacker <[EMAIL PROTECTED]>
convolution: ict solutions and consultancy <[EMAIL PROTECTED]>
Re: Emacs/vim code coda placement
On Oct 3, 2006, at 2:49 AM, Chris Dolan wrote: On Oct 3, 2006, at 1:29 AM, Paul Cochrane wrote: Hi all, In the process of trying to finish off the perl coda cage task, I notice that the Perl::Critic policy for the emacs/vim coda skips __END__ and __DATA__ sections at the end of perl files, however vim (I don't know about emacs) requires the coda to be within either the first or last 5 lines of the file (by default) for which the editor settings are to be applied, and so if one has a large __END__ or __DATA__ section (not exactly difficult) the coda will be missed by vim. A lot of the time __END__ sections are used for pod, so there is an easy fix for these situations such that the coda can be added without affecting perldoc output namely: put a C<=cut> at the end of the pod, before the coda. However, this doesn't work in all situations, and I believe the coda will add itself to the data in the __DATA__ block, am I correct? In short, the coda needs to be at the end of each of the files, however, not to be included in any present __END__ or __DATA__ blocks; how do we get around this in nice, general way? Thanks heaps in advance, Paul Paul, Good point, I meant to bring this up myself when I was fiddling with lib/Perl/Critic/Policy/CodeLayout/UseParrotCoda.pm I agree that using =cut in __END__ is the right solution. I have no idea how to handle __DATA__ since you can't put an __END__ embedded in a __DATA__ section. If Will Coleda (or someone else) approves the coda-after-__END__ spec change, I'll be happy to code that up in CodeLayout::UseParrotCoda. Chris Yes please. The PDD already says "end with this code", and I was simply doing a first pass implementation. We should also, if the __DATA__ problem is described accurately here, amend the PDD to say that it's ok to begin with (post shebang & copyright, I suppose), if the particular file requires it. Go ahead and code this against your updated version, I'll get that applied shortly. Thanks, guys. -- Will "Coke" Coleda [EMAIL PROTECTED]
Re: Wikipedia example
Aaron Sherman writes: > +Written in 2006 by Aaron Sherman, and distrbuted Typo: distributed
Wikipedia example
I'm finally getting around to sending this patch as requested on IRC...
dang commit bits are rare around here ;)
This contains the Makefile, README, .pg grammar, a -harness.pir that
executes the parser on a sample string and dumps the parse tree and a
-stress.pir that runs 50,000 trial runs to see how fast PGE is (not too
shabby is the answer, as it comes in at about 1/2 the time of a P::RD
version for the simple example, and gets a bigger lead the more complex
the input expression).
What I didn't understand was why -j didn't run any faster than -b in my
trials... that seemed odd.
Index: examples/pge/wikipedia/wptest-harness.pir
===
--- examples/pge/wikipedia/wptest-harness.pir (revision 0)
+++ examples/pge/wikipedia/wptest-harness.pir (revision 0)
@@ -0,0 +1,44 @@
+# This is a simple invoker for the example parser whose grammar is
+# used in the Wikipedia article:
+# http://en.wikipedia.org/wiki/Parser_Grammar_Engine
+#
+# This simply runs the parser against a static expression.
+.sub main :main
+load_bytecode 'dumper.pir'
+load_bytecode '../../../compilers/pge/PGE.pir'
+load_bytecode 'PGE/Dumper.pir'
+load_bytecode 'wptest.pir'
+
+.local pmc match
+.local pmc code
+.local pmc start_rule
+code = new .String
+code = '1+(1+1)' # target string
+print "Parsing simple expression: "
+print code
+print "\n"
+# Find the "expr" node in the parser:
+start_rule = get_root_global [ 'parrot'; 'Wikipedia::Test'], 'expr'
+if start_rule goto start_rule_ok
+ printerr "Cannot find valid start rule in Wikipedia::Test"
+ exit 1
+
+# And execute it on our text:
+ start_rule_ok:
+match = start_rule(code)
+
+# Now dump the results
+say "Match results begin:"
+ match_loop:
+unless match goto match_done
+_dumper(match)
+match = match.'next'() # find the next match
+goto match_loop
+
+ match_done:
+say "match complete"
+
+ end
+
+.end
+
Index: examples/pge/wikipedia/wptest-stress.pir
===
--- examples/pge/wikipedia/wptest-stress.pir (revision 0)
+++ examples/pge/wikipedia/wptest-stress.pir (revision 0)
@@ -0,0 +1,55 @@
+# This is a simple invoker for the example parser whose grammar is
+# used in the Wikipedia article:
+# http://en.wikipedia.org/wiki/Parser_Grammar_Engine
+#
+# This example has been turned into a stress-test to measure
+# parsing speed.
+.sub main :main
+load_bytecode 'dumper.pir'
+load_bytecode '../../../compilers/pge/PGE.pir'
+load_bytecode 'PGE/Dumper.pir'
+load_bytecode 'wptest.pir'
+
+.local pmc match
+.local pmc code
+.local pmc start_rule
+.local int loops
+.local int i
+loops = 5
+code = new .String
+code = '1+(1+1+1+1+(1+1+1))+1+1' # target string
+print "Parsing simple expression: '"
+print code
+print "' "
+print loops
+print "times\n"
+i = 0
+ loop_start:
+if i >= loops goto loop_end
+inc i
+# Find the "expr" node in the parser:
+start_rule = get_root_global [ 'parrot'; 'Wikipedia::Test'], 'expr'
+if start_rule goto start_rule_ok
+ printerr "Cannot find valid start rule in Wikipedia::Test"
+ exit 1
+
+# And execute it on our text:
+ start_rule_ok:
+match = start_rule(code)
+
+unless match goto match_fail
+goto loop_start
+
+ loop_end:
+say "Looping complete"
+_dumper(match)
+exit 0
+
+ match_fail:
+print "Failed to match simple grammar\n"
+exit 1
+
+ end
+
+.end
+
Index: examples/pge/wikipedia/wptest.pg
===
--- examples/pge/wikipedia/wptest.pg (revision 0)
+++ examples/pge/wikipedia/wptest.pg (revision 0)
@@ -0,0 +1,12 @@
+#
+# A simple test grammar that is used in a Wikipedia article about
+# PGE. See wptest-harness.pir for more detail.
+#
+grammar Wikipedia::Test
+
+rule expr is optable { ... }
+rule term { | \( \) }
+rule number { \d+ }
+proto term: is precedence('=')
+is parsed(&term) {...}
+proto infix:+ is looser('term:') {...}
Index: examples/pge/wikipedia/Makefile
===
--- examples/pge/wikipedia/Makefile (revision 0)
+++ examples/pge/wikipedia/Makefile (revision 0)
@@ -0,0 +1,13 @@
+PARROT=../../../parrot
+PGC=../../../compilers/pge/pgc.pir
+RM=rm -f
+PIR=wptest.pir
+
+all: $(PIR)
+
+$(PIR): wptest.pg
+ $(PARROT) -o $@ $(PGC) $< || $(RM) $@
+
+clean::
+ $(RM) $(PIR)
+
Index: examples/pge/wikipedia/README
===
--- examples/pge/wikipedia/README (revision 0)
+++ examples/pge/wikipedia/README (revision 0)
@@ -0,0 +1,13 @@
+This directory contains a very crude example parser that reads a fixed string
+"1+(1+1)" and produces a parse tree. The parser itself is used as an examp
Re: Nested statement modifiers.
Paul Seamons wrote: 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. I don't think that is ambiguous though. It really is, and the very first question that everyone asks is: how do I get access to the outer loop variable, which of course, you cannot for the reasons stated above. Let's get P6 out the door, and then discuss what tiny details like this do or don't make sense.
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
[svn:parrot-pdd] r14840 - in trunk: . docs/pdds/clip
Author: chip Date: Tue Oct 3 12:36:36 2006 New Revision: 14840 Removed: trunk/docs/pdds/clip/pdd07_codingstd.pod Changes in other areas also in this revision: Modified: trunk/ (props changed) Log: Remove redundant pdd07 (closes: #40419)
Re: Nested statement modifiers.
Paul Seamons wrote:
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
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.
To resolve that, the modifiers are limited to one per statement. There's
nothing that can be done about:
{say $_ for 1..10}.() for 1..10
but at least then you are going out of your way to shoot yourself in the
foot, so presumably you knew the risks. Others who are not so bold will
write:
for 1..10 -> ($a) {
for 1..10 -> ($b) {
say $b;
}
}
And ambiguity is gone.
Re: [perl #40449] [PATCH] improvements to examples/io/httpd.pir
On Tuesday 03 October 2006 08:46, Chris Dolan wrote:
> This patch makes the following simple improvements to the example
> HTTP server that ships with Parrot:
>
> * Bugfix for 404 responses
> * Disallow urls containing ".."
> * Un-hardcode the server host name
> * Move the server name ("Parrot-httpd/0.1") to a const
> * Fix doc typos
Thanks, applied as #14833.
-- c
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.
Trey Harris wrote:
In a message dated Fri, 1 Sep 2006, jerry gay writes:
On 9/1/06, Trey Harris <[EMAIL PROTECTED]> wrote:
In a message dated Fri, 1 Sep 2006, Paul Seamons writes:
> I'm not sure if I have seen this requested or discussed.
This was definitively rejected by Larry in 2002:
perhaps a sentence to that effect belongs in S04, which has no mention
of nested statement modifiers, for or against.
Well, that's because Synopses at least in theory only refer to changes
from Perl 5. Perl 5 doesn't allow more than one statement modifier, and
Perl 6 doesn't either.
In Perl 5, it's:
sub {sub {print 1 if 1}->() if 1}->() if 1;
In Perl 6, that's simplified to:
{{say 1 if 1}.() if 1}.() if 1;
Since expressions can always be a closure wrapped around a statement,
any statement can always be an expression.
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.
Re: "Don't tell me what I can't do!"
chromatic wrote: On Monday 02 October 2006 12:32, Jonathan Lang wrote: Before we start talking about how such a thing might be implemented, I'd like to see a solid argument in favor of implementing it at all. What benefit can be derived by letting a module specify additional strictures for its users? Ditto for a role placing restrictions on the classes that do it. Benefit #1: incompetent programmers who really really need to write mission-critical code (the ones that the Java designers apparently had in mind) now have only a million ways to write terrible code. First of all, sorry for replying to the earliest message in this thread last night with what was obviously a redundant message. I was skimming mail last night. Second, I think everyone needs to grab some fresh air and relax. Perl will be Perl when we're done. Everyone's agreed on that, and it's not going to change. The proposal that I made, and others that have been making are attempts to allow certain types of programming paradigms. This is a good thing, and plays well into the inclusiveness of Perl. Would there be such tools used in the core libraries? Maybe, maybe not, we could discuss that. If they were implemented in the core libraries would there be a universal "no bondage" flag that shut them off? Probably, since that's something that Perl tends to like doing. Now, Larry has asked that we focus on getting 6.0 out the door, and let details like this set until there's some clarity of implementation. I think that's a great idea, mostly because there are bigger fish to fry right now.
[perl #40449] [PATCH] improvements to examples/io/httpd.pir
# New Ticket Created by Chris Dolan
# Please include the string: [perl #40449]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=40449 >
This patch makes the following simple improvements to the example
HTTP server that ships with Parrot:
* Bugfix for 404 responses
* Disallow urls containing ".."
* Un-hardcode the server host name
* Move the server name ("Parrot-httpd/0.1") to a const
* Fix doc typos
httpd.pir | 49 ++---
1 files changed, 38 insertions(+), 11 deletions(-)
httpd.patch
Description: Binary data
Re: error when using -> as lambda function
在 Oct 3, 2006 10:22 PM 時，Wim Vanderbauwhede 寫到：
say (-> $n { -> $f { $f($n,$f) }.( -> $n, $f { $n<2 ?? 1 !! $n*$f
($n-1,$f)
}) }).(5);
say "OK";
#say (-> $n { -> $f { $f($n,$f) }.( -> $n, $f { $n<2 ?? 1 !! $n*$f
($n-1,$f)
}) }).(5);
say "OK";
It's extremely subtle -- $n<2 should never have parsed in the first
place, because it's always a
hash dereference (as in $n<2>); put a whitespace before the < sign to
get the infix comparison
operator you're looking for.
See Lconsistent three-way distinction">
for more details on this distinction.
Pugs should have never admitted the first $n<2 case (by scanning
outward to a matching > and
failing+backtracking), and should instead say someting like "write $n
< 2 instead". Can you commit a
test to make sure that "1<2" is a parse failure, perhaps as t/syntax/
parsing/lt.t?
A commit bit is on your way. Remember to add yourself to AUTHORS
first. :-)
Thanks!
Audrey
error when using -> as lambda function
Hi all,
I encountered this strange error in pugs (in 6.2.11,6.2.12 and the latest
svn)
My first program (lambda1.p6) calculates the factorial of 5 using -> as
lambda functions:
say (-> $n { -> $f { $f($n,$f) }.( -> $n, $f { $n<2 ?? 1 !! $n*$f($n-1,$f)
}) }).(5);
say "OK";
say "OK";
$ pugs lambda1.p6
120
OK
OK
-
The second program (lambda2.p6) has the first line repeated as a comment:
say (-> $n { -> $f { $f($n,$f) }.( -> $n, $f { $n<2 ?? 1 !! $n*$f($n-1,$f)
}) }).(5);
say "OK";
#say (-> $n { -> $f { $f($n,$f) }.( -> $n, $f { $n<2 ?? 1 !! $n*$f($n-1,$f)
}) }).(5);
say "OK";
$ pugs lambda2.p6
***
Unexpected "$"
expecting comment, operator, statement modifier, ";" or "}"
at lambda2.p6 line 3, column 10
So the comment causes an error!
-
If I uncomment that line, I still get the same error (lambda3.p6):
$ pugs lambda3.p6
***
Unexpected "$"
expecting comment, operator, statement modifier, ";" or "}"
at lambda3.p6 line 3, column 9
The error is now at column 9 i.o. column 10.
Could anyone shed any light on what's going on here?
pugs Version: 6.2.12 (r13798)
perl v5.8.7
parrot 0.4.6
Thanks!
Wim
--
If it's pointless, what's the point?
If there is a point to it, what's the point?
(Tibor Fischer, "The Thought Gang")
