Re: NEXT and the general loop statement
On 8/17/06, Jonathan Scott Duff <[EMAIL PROTECTED]> wrote:
Depends on when it fires I guess. Your example might be equivalent to
this perl5ish:
while (1) {
$num = rand;
print $num;
last if $num < 0.9;
print ","; # NEXT
}
print "\n"; # LAST
Which, incidentally, relates back to the discussion at hand. If this
were the case, though, the state of the variables (in three-arg for
loops and side-effecty while loops) would seem to reflect the state of
the next iteration from the rest of the code. It would also
(obviously) fire after user input for eg. a for =<> loop.
So, unless the next paragraph is feasible, I think NEXT ought to be
equivalent to LEAVE, perhaps with the exception of exceptional
circumstances.
But I was talking about hypotheticalization. That is, unless I am
mistaken we have temp {} and let {} using UNDO blocks (which are given
default definitions where possible). So perhaps we could use that
feature to provide a NEXT trait which actually executes only if there
is a next iteration, while giving the block the impression that it is
executing in the previous iteration. This, of course, would not work
for loops whose conditions have irreversible side-effects.
Overall, it might be feasible in some circumstances, but it may not be
worth it. Its implementation (and usage caveats) are quite complex
for a relatively minor convenience feature. For a user to implement
its effect by himself, using the extended knowledge he has of the loop
semantics, would probably not take more than four extra lines in the
worst case.
Luke
Re: [svn:perl6-synopsis] r11115 - doc/trunk/design/syn
On 8/18/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: +To give both a long and a short switch name, you may use the pair +notation. The key will be considered the short switch name, while +the variable name will be considered the long switch name. So if +the previous declaration had been: + +sub MAIN (:f($frompart), :t($topart), [EMAIL PROTECTED]) + +then you could invoke the program with either C<-f> or C<--frompart> +to specify the first parameter. Likewise you could use either C<-t> +or C<--topart> for the second parameter. What about combined short switches like C<-abc> to mean C<-a -b -c>? Will perl6 support this notation or not? -- Markus Laire
Re: [REPATCH] Parrot::Embed Take Two
Am Freitag, 18. August 2006 03:43 schrieb chromatic: > Hi there, > > Here's a patch for Build.PL that should avoid most of the pkg_config > troubles on platforms that don't have it. I still don't quite know what to > do on Windows when installing from outside of the Parrot tree. You could always query parrot itself for it's configuration variables, see e.g.: tools/dev/src-t.sh. That is: the user would have to specify the location of the parrot executable. 2 further notes: - parrot.pc seems not to have all necessary Cflags - parrot-config should have some macro-ish queries that retrieve all necessary compile / link setting with one --option [1] I'd just ci and let it evolve. leo [1] http://rt.perl.org/rt3/Public/Bug/Display.html?id=32365 http://rt.perl.org/rt3/Public/Bug/Display.html?id=34356
[svn:perl6-synopsis] r11135 - doc/trunk/design/syn
Author: audreyt
Date: Fri Aug 18 08:11:42 2006
New Revision: 11135
Modified:
doc/trunk/design/syn/S06.pod
doc/trunk/design/syn/S13.pod
Log:
* S13 and S06: Remove the mentioning of "invocants" for
multi dispatch; they are now simply "parameters", or
"important parameters" for dispatch purposes.
Modified: doc/trunk/design/syn/S06.pod
==
--- doc/trunk/design/syn/S06.pod(original)
+++ doc/trunk/design/syn/S06.podFri Aug 18 08:11:42 2006
@@ -13,9 +13,9 @@
Maintainer: Larry Wall <[EMAIL PROTECTED]>
Date: 21 Mar 2003
- Last Modified: 17 Aug 2006
+ Last Modified: 18 Aug 2006
Number: 6
- Version: 50
+ Version: 51
This document summarizes Apocalypse 6, which covers subroutines and the
@@ -54,7 +54,7 @@
B (keyword: C) are routines that can have multiple
variants that share the same name, selected by arity, types, or some
-other constraints. They may have multliple invocants.
+other constraints.
B (keyword: C) specify the commonalities (such
as parameter names, fixity, and associativity) shared by all multis
@@ -498,10 +498,10 @@
# fall-back to set_name($obj, "Sam")
$obj.set_name("Sam"); # same as the above
-An invocant is the topic of the corresponding method or multi if that
-formal parameter is declared with the name C<$_>. A method's first
-invocant always has the alias C. Other styles of self can be
-declared with the C pragma.
+An invocant is the topic of the corresponding method if that formal
+parameter is declared with the name C<$_>. A method's first invocant
+always has the alias C. Other styles of self can be declared
+with the C pragma.
=head2 Longname parameters
@@ -515,9 +515,9 @@
multi method set_name ($self: $name; $nick) {...}
If the parameter list for a C contains no semicolon to delimit
-the list of invocant parameters, then all positional parameters are
-considered invocants. If it's a C or C,
-an additional implicit unnamed C invocant is prepended to the
+the list of important parameters, then all positional parameters are
+considered important. If it's a C or C,
+an additional implicit unnamed C invocant is added to the
signature list unless the first parameter is explicitly marked with a colon.
@@ -2148,7 +2148,7 @@
This special form should generally be restricted to named parameters.
To curry a particular multimethod it may be necessary to specify the type
-of one or more of its invocants:
+for one or more of its parameters:
&woof ::= &bark:(Dog).assuming :pitch;
&pine ::= &bark:(Tree).assuming :pitch;
Modified: doc/trunk/design/syn/S13.pod
==
--- doc/trunk/design/syn/S13.pod(original)
+++ doc/trunk/design/syn/S13.podFri Aug 18 08:11:42 2006
@@ -12,9 +12,9 @@
Maintainer: Larry Wall <[EMAIL PROTECTED]>
Date: 2 Nov 2004
- Last Modified: 1 Apr 2006
+ Last Modified: 18 Aug 2006
Number: 13
- Version: 4
+ Version: 5
=head1 Overview
@@ -53,11 +53,10 @@
rather than the built-in one. Putting the C into the C<*>
namespace makes it show up in everyone's packages, but as long as no one
else defines a version of C on C, there's no collision.
-The types of the invocants are included in the "long name" of any C
-sub or method.
-If you want to overload string concatenation for Arabic strings
-so you can handle various ligatures, you can say:
+The types of the parameters are included in the I of any C
+sub or method. So if you want to overload string concatenation for Arabic
+strings so you can handle various ligatures, you can say:
multi sub *infix:<~>(ArabicStr $s1, ArabicStr $s2) {...}
multi sub *infix:<~>(Str $s1, ArabicStr $s2) {...}
Re: [svn:perl6-synopsis] r11115 - doc/trunk/design/syn
On Fri, Aug 18, 2006 at 12:56:30PM +0300, Markus Laire wrote: : What about combined short switches like C<-abc> to mean C<-a -b -c>? : Will perl6 support this notation or not? Hmm, that opens up a world of hurt. Either you have to distinguish a --abc from -abc, or you have to have some kind of fallback heuristic, and it doesn't work terribly well with arguments in any case except for the final one. Should probably make it possible, just because the external interface is one of the places where Perl has always tried to be accommodating to existing culture rather than revisionist. We can probably work something out here, along the lines of: if there's only one - if single character aliases are defined if the word matches that alphabet if the word doesn't match any longer names At first I was inclined to say that if there's a *% then all the unrecognized go in there and you can parse the -abc yourself, but that doesn't tell you how to treat the next argument unless we look at the definition of -c anyway. We can't just say that -c's arg must use the -c=arg form, since even Perl 5 violates that with -e. :/ Larry
Re: Numerification of Order:: constants
On Thursday 17 August 2006 21:27, David Green wrote: > However, what I'm wondering is whether Order::Same is "but true" and > the others "but false"? (Which makes cmp in boolean context the same > as eqv, but it seems to make sense that way.) OTOH, C programmers can as well assume 'cmp' being an equivalent of '! eqv' in boolean context; after all that's how strcmp() works... The same goes for assembly programmers. (* goes back lurking *) -- Alexey A. Kiritchun
Re: NEXT and the general loop statement
On Fri, Aug 18, 2006 at 01:44:35AM -0600, Luke Palmer wrote:
: On 8/17/06, Jonathan Scott Duff <[EMAIL PROTECTED]> wrote:
: >Depends on when it fires I guess. Your example might be equivalent to
: >this perl5ish:
: >
: >while (1) {
: >$num = rand;
: >print $num;
: >last if $num < 0.9;
: >print ","; # NEXT
: >}
: >print "\n"; # LAST
:
: Which, incidentally, relates back to the discussion at hand. If this
: were the case, though, the state of the variables (in three-arg for
: loops and side-effecty while loops) would seem to reflect the state of
: the next iteration from the rest of the code. It would also
: (obviously) fire after user input for eg. a for =<> loop.
:
: So, unless the next paragraph is feasible, I think NEXT ought to be
: equivalent to LEAVE, perhaps with the exception of exceptional
: circumstances.
I think it is equivalent to LEAVE, unless you've explicitly opted out
with "last" or an exception.
: But I was talking about hypotheticalization. That is, unless I am
: mistaken we have temp {} and let {} using UNDO blocks (which are given
: default definitions where possible). So perhaps we could use that
: feature to provide a NEXT trait which actually executes only if there
: is a next iteration, while giving the block the impression that it is
: executing in the previous iteration. This, of course, would not work
: for loops whose conditions have irreversible side-effects.
:
: Overall, it might be feasible in some circumstances, but it may not be
: worth it. Its implementation (and usage caveats) are quite complex
: for a relatively minor convenience feature. For a user to implement
: its effect by himself, using the extended knowledge he has of the loop
: semantics, would probably not take more than four extra lines in the
: worst case.
It would mean that we can't use NEXT to replace Perl 5's "continue"
blocks, for instance, since those are required to run before the
while loop's condition is tested. Which also basically means we
couldn't rewrite loop (;;) using NEXT. So I think NEXT should just
be equivalent to LEAVE from the viewpoint of conditionals outside
the loop body. You have to use "last" to do better.
Larry
[svn:perl6-synopsis] r11136 - doc/trunk/design/syn
Author: larry
Date: Fri Aug 18 09:00:28 2006
New Revision: 11136
Modified:
doc/trunk/design/syn/S04.pod
doc/trunk/design/syn/S06.pod
doc/trunk/design/syn/S12.pod
Log:
No such thing as a "first invocant" anymore.
Clarified NEXT semantics.
Modified: doc/trunk/design/syn/S04.pod
==
--- doc/trunk/design/syn/S04.pod(original)
+++ doc/trunk/design/syn/S04.podFri Aug 18 09:00:28 2006
@@ -12,9 +12,9 @@
Maintainer: Larry Wall <[EMAIL PROTECTED]>
Date: 19 Aug 2004
- Last Modified: 17 Aug 2006
+ Last Modified: 18 Aug 2006
Number: 4
- Version: 36
+ Version: 37
This document summarizes Apocalypse 4, which covers the block and
statement syntax of Perl.
@@ -636,7 +636,7 @@
UNDO {...} at every unsuccessful block exit, part of LEAVE queue
FIRST {...}* at loop initialization time, before any ENTER
- NEXT {...} at loop continuation time, after any LEAVE
+ NEXT {...} at loop continuation time, before any LEAVE
LAST {...} at loop termination time, after any LEAVE
PRE {...} assert precondition at every block entry, before any
@@ -707,8 +707,14 @@
of C, and for execution order are treated as part of the queue of
C blocks.
-C, C, and C are meaningful only within the lexical scope
-of a loop, and may occur only at the top level of such a loop block.
+C, C, and C are meaningful only within the
+lexical scope of a loop, and may occur only at the top level of such
+a loop block. A C executes only if the end of the loop block is
+reached normally, or an explicit C is executed. In distinction
+to C blocks, a C block is not executed if the loop block
+is exited via any exception other than the control exception thrown
+by C. In particular, a C bypasses evaluation of C
+blocks.
[Note: the name C used to be associated with C
declarations. Now it is associated only with loops. See the C
Modified: doc/trunk/design/syn/S06.pod
==
--- doc/trunk/design/syn/S06.pod(original)
+++ doc/trunk/design/syn/S06.podFri Aug 18 09:00:28 2006
@@ -499,7 +499,7 @@
$obj.set_name("Sam"); # same as the above
An invocant is the topic of the corresponding method if that formal
-parameter is declared with the name C<$_>. A method's first invocant
+parameter is declared with the name C<$_>. A method's invocant
always has the alias C. Other styles of self can be declared
with the C pragma.
Modified: doc/trunk/design/syn/S12.pod
==
--- doc/trunk/design/syn/S12.pod(original)
+++ doc/trunk/design/syn/S12.podFri Aug 18 09:00:28 2006
@@ -12,9 +12,9 @@
Maintainer: Larry Wall <[EMAIL PROTECTED]>
Date: 27 Oct 2004
- Last Modified: 17 Aug 2006
+ Last Modified: 18 Aug 2006
Number: 12
- Version: 20
+ Version: 21
=head1 Overview
@@ -730,7 +730,7 @@
=head1 Multi dispatch
Multi submethods work just like multi subs except they are constrained
-to an exact type match on the first invocant.
+to an exact type match on the invocant.
Perl 6.0.0 is not required to support multiple dispatch on named parameters,
only on positional parameters. Note that most builtins will map known
@@ -742,7 +742,7 @@
Attributes are tied to a particular class definition, so a multi method
can only directly access the attributes of a class it's defined within
-when the first invocant is the "self" of that attribute.
+when the invocant is the "self" of that attribute.
However, it may call the private attribute accessors from a different
class if that other class has indicated that it trusts the class the
multi method is defined in:
[svn:perl6-synopsis] r11137 - doc/trunk/design/syn
Author: larry Date: Fri Aug 18 09:09:21 2006 New Revision: 11137 Modified: doc/trunk/design/syn/S02.pod Log: conjecture about conversion of undef to NaN grammo from Mark Reed++ Modified: doc/trunk/design/syn/S02.pod == --- doc/trunk/design/syn/S02.pod(original) +++ doc/trunk/design/syn/S02.podFri Aug 18 09:09:21 2006 @@ -471,11 +471,16 @@ my Int $x = undef;# works -Variables with native types does not support undefinedness: it is an error +Variables with native types do not support undefinedness: it is an error to assign an undefined value to them: my int $y = undef;# dies +Conjecture: num might support the autoconversion of undef to NaN, since +the floating-point form can represent this concept. Might be better +to make that conversion optional though, so that the rocket designer +can decide whether to self-destruct immediately or shortly thereafter. + =item * Every object supports a C function/method that returns the
Re: [svn:perl6-synopsis] r11115 - doc/trunk/design/syn
On 8/18/06, Larry Wall <[EMAIL PROTECTED]> wrote: On Fri, Aug 18, 2006 at 12:56:30PM +0300, Markus Laire wrote: : What about combined short switches like C<-abc> to mean C<-a -b -c>? : Will perl6 support this notation or not? Hmm, that opens up a world of hurt. Either you have to distinguish a --abc from -abc, or you have to have some kind of fallback heuristic, and it doesn't work terribly well with arguments in any case except for the final one. Should probably make it possible, just because the external interface is one of the places where Perl has always tried to be accommodating to existing culture rather than revisionist. We can probably work something out here, along the lines of: if there's only one - if single character aliases are defined if the word matches that alphabet if the word doesn't match any longer names At first I was inclined to say that if there's a *% then all the unrecognized go in there and you can parse the -abc yourself, but that doesn't tell you how to treat the next argument unless we look at the definition of -c anyway. We can't just say that -c's arg must use the -c=arg form, since even Perl 5 violates that with -e. :/ Larry Yep, I understand it's not an easy question. Still I was thinking of behaviour where C<-abc> would allways mean C<-a -b -c> regardless of what 1-char aliases or longer names have been defined. This would make --abc and -abc mean completely different things. And in this proposal only the last switch would be able to get an argument, e.g. with C<-abc=99> or C<-abc 99> or something like that. If this can't be the default behaviour, then it would be nice to be able to easily switch to this kind of behaviour. ps. Then there's the perl5-behaviour of "perl -n0e unlink" where also the intervening switches can get arguments. This could be expanded so that all chars for which there's no 1-char alias defined, are parameters. So C<-aHellobWorld> would mean C<-a=Hello -b=World> if there are 1-char aliases only for a & b. ;) -- Markus Laire
Re: [svn:perl6-synopsis] r11115 - doc/trunk/design/syn
On Fri, Aug 18, 2006 at 07:53:14PM +0300, Markus Laire wrote: : ps. Then there's the perl5-behaviour of "perl -n0e unlink" where also : the intervening switches can get arguments. This could be expanded so : that all chars for which there's no 1-char alias defined, are : parameters. So C<-aHellobWorld> would mean C<-a=Hello -b=World> if : there are 1-char aliases only for a & b. ;) I think that safely falls into the category of completely psychotic. @L@ Larry
Re: [perl #39868] [CAGE] convert C NN; }> to C NN;>
(i initially posted this on RT, but since posts made by guests seem not to get forwarded to the list here it is, only hope this message goes into the right place) Hi all, I have applied the patch attatched to this ticket. Here's the outcome: 1) before the patch i did: $ make test 2>&1 | tee test_before_patch 2) applied the patch (only a couple of problems, not a big deal): $ patch -p0 < BEGIN-t.patch (patching file ...) can't find file to patch at input line 404 Perhaps you used the wrong -p or --strip option? The text leading up to this was: -- |Index: t/pmc/none.t |=== |--- t/pmc/none.t (revision 13607) |+++ t/pmc/none.t (working copy) -- File to patch: Skip this patch? [y] Skipping patch. 2 out of 2 hunks ignored (patching file ...) Hunk #2 FAILED at 67. 1 out of 2 hunks FAILED -- saving rejects to file t/compilers/tge/parser.t.rej (patching file ...) 3) after appliyng the patch i ran make test again: $ make test 2>&1 | tee test_after_patch 4) and then i got the test differences: $ diff test_before_patch test_after_patch 258c258,264 < t/compilers/tge/parser...ok --- t/compilers/tge/parser...You tried to plan twice! Second plan at t/compilers/tge/parser.t line 92 BEGIN failed--compilation aborted at t/compilers/tge/parser.t line 92. # Looks like your test died before it could output anything. dubious Test returned status 255 (wstat 65280, 0xff00) DIED. FAILED test 1 Failed 1/1 tests, 0.00% okay 350c356 < Failed Test Stat Wstat Total Fail Failed List of Failed --- Failed Test Stat Wstat Total Fail Failed List of Failed 352,353c358,360 < t/examples/library.t 1 256 4 1 25.00% 3 < t/library/pcre.t 1 256 1 1 100.00% 1 --- t/compilers/tge/parser.t 255 65280 1 2 200.00% 1 t/examples/library.t 1 256 4 1 25.00% 3 t/library/pcre.t 1 256 1 1 100.00% 1 355c362 < Failed 2/246 test scripts, 99.19% okay. 2/6710 subtests failed, 99.97% okay. --- Failed 3/246 test scripts, 98.78% okay. 3/6709 subtests failed, 99.96% okay. It revealed some problems in the patch, but nothing that can't be fixed. Just my 2cents,
Mono, Bundles, and Ahead-Of-Time Compilation
Miguel de Icaza recently posted some thoughts about improving startup time and memory usage of multiple Mono applications. What ideas can we steal and improve? http://tirania.org/blog/archive/2006/Aug-17.html -- c
multi-line comments, C macros, & Pod abuse
It occurred to me that other day that in our "in house" C code we somewhat frequently use an idiom that's not easily translated into Perl 5. Our rule is that if your commenting out more then 1 or 2 lines of code that you wrap it in a CPP if statement. The logic being that if you haven't deleted the code then it must have some reason of hanging around (and you may actually want to use it again someday). This is most often the case with specialized debugging code. E.g. #if 0 ... #endif The great thing about this is that the you only have to flip the 0 to 1 to re-enable the code. E.g. #if 1 (magic now happens)... #endif The best equivalent I've been able to come up with in Perl 5 is: =for off ... =cut & #=for off (magic now happens)... =cut Except that now this requires all sorts of weird voodoo to keep the Pod formatting from breaking. This thread seems to suggest the situation isn't going to change much if at all in Perl 6: http://groups.google.com/group/perl.perl6.language/browse_thread/thread/45f5be3ca97d1d82/cd5f1daa256be9b9?lnk=gst&q=multiline+comments&rnum=1#cd5f1daa256be9b9 I guess the point I'm trying to make here is that multi-line comments about the code and disabled chunks of code are or should be distinct functionalities. One can make the argument that any code you want to disable in the manner I've described should be factored out into it's own function, so that just the call to the function can be commented out. The hard reality is that it's not always so easy or desirable to do that. Is there any hope of getting some equivalent "disabled code chunk" functionality in the perl6 core? Cheers, -J -- pgpbSr20Jlwrk.pgp Description: PGP signature
Re: multi-line comments, C macros, & Pod abuse
On Fri, Aug 18, 2006 at 11:58:20AM -1000, Joshua Hoblitt wrote:
: It occurred to me that other day that in our "in house" C code we
: somewhat frequently use an idiom that's not easily translated into Perl
: 5. Our rule is that if your commenting out more then 1 or 2 lines of
: code that you wrap it in a CPP if statement. The logic being that
: if you haven't deleted the code then it must have some reason of hanging
: around (and you may actually want to use it again someday). This is most
: often the case with specialized debugging code. E.g.
:
: #if 0
: ...
: #endif
if 0 {
...
}
: The great thing about this is that the you only have to flip the 0 to 1
: to re-enable the code. E.g.
:
: #if 1
: (magic now happens)...
: #endif
if 1 {
(magic now happens)...
}
Larry
[svn:perl6-synopsis] r11154 - doc/trunk/design/syn
Author: larry Date: Fri Aug 18 16:27:16 2006 New Revision: 11154 Modified: doc/trunk/design/syn/S06.pod Log: Allow for switch bundling. Modified: doc/trunk/design/syn/S06.pod == --- doc/trunk/design/syn/S06.pod(original) +++ doc/trunk/design/syn/S06.podFri Aug 18 16:27:16 2006 @@ -15,7 +15,7 @@ Date: 21 Mar 2003 Last Modified: 18 Aug 2006 Number: 6 - Version: 51 + Version: 52 This document summarizes Apocalypse 6, which covers subroutines and the @@ -2548,3 +2548,7 @@ then you could invoke the program with either C<-f> or C<--frompart> to specify the first parameter. Likewise you could use either C<-t> or C<--topart> for the second parameter. + +If a switch of the form C<-abc> cannot be matched against any +particular parameter, an attempt will be made to match it as if it +had been written C<-a -b -c>.
[svn:perl6-synopsis] r11155 - doc/trunk/design/syn
Author: larry
Date: Fri Aug 18 17:57:09 2006
New Revision: 11155
Modified:
doc/trunk/design/syn/S09.pod
Log:
List comprehensions via junctional syntax.
Modified: doc/trunk/design/syn/S09.pod
==
--- doc/trunk/design/syn/S09.pod(original)
+++ doc/trunk/design/syn/S09.podFri Aug 18 17:57:09 2006
@@ -12,9 +12,9 @@
Maintainer: Larry Wall <[EMAIL PROTECTED]>
Date: 13 Sep 2004
- Last Modified: 26 July 2006
+ Last Modified: 18 Aug 2006
Number: 9
- Version: 12
+ Version: 13
=head1 Overview
@@ -603,6 +603,22 @@
in fact scalar parameters, though, so you could pass a junction of
array or hash objects.)
+For junctions used with chained operators in a list context, the resulting
+value will be a subset of the first C used in comparison:
+
+for 0 <= any(@x) < all(@y) {...}
+
+will use only those values from C<@x> that satisfy the constraint.
+Usually junctions do not guarantee order of evalution, but in
+this particular case, the original ordering C<@x> is guaranteed to
+be preserved in the returned list. In particular,
+
+@result = any(@x) ~~ {...};
+
+is equivalent to
+
+@result = grep {...}, @x;
+
=head1 Parallelized parameters and autothreading
Within the scope of a C pragma (or equivalent, such as
Re: multi-line comments, C macros, & Pod abuse
On 8/19/06, Larry Wall <[EMAIL PROTECTED]> wrote:
if 0 {
...
}
The one disadvantage of that approach is that it will break if the
"commented-out" code temporarily fails to compile. If that's a
problem, though, you could always write your own macro.
Stuart Cook
RE: NEXT and the general loop statement
> -Original Message-
> From: Larry Wall [mailto:[EMAIL PROTECTED]
> Sent: Friday, August 18, 2006 11:47 AM
> To: Perl6 Language List
> Subject: Re: NEXT and the general loop statement
>
> On Fri, Aug 18, 2006 at 01:44:35AM -0600, Luke Palmer wrote:
> : On 8/17/06, Jonathan Scott Duff <[EMAIL PROTECTED]> wrote:
> : >Depends on when it fires I guess. Your example might be equivalent to
> : >this perl5ish:
> : >
> : >while (1) {
> : >$num = rand;
> : >print $num;
> : >last if $num < 0.9;
> : >print ","; # NEXT
> : >}
> : >print "\n"; # LAST
> :
> : Which, incidentally, relates back to the discussion at hand. If this
> : were the case, though, the state of the variables (in three-arg for
> : loops and side-effecty while loops) would seem to reflect the state of
> : the next iteration from the rest of the code. It would also
> : (obviously) fire after user input for eg. a for =<> loop.
> :
> : So, unless the next paragraph is feasible, I think NEXT ought to be
> : equivalent to LEAVE, perhaps with the exception of exceptional
> : circumstances.
>
> I think it is equivalent to LEAVE, unless you've explicitly opted out
> with "last" or an exception.
>
> : But I was talking about hypotheticalization. That is, unless I am
> : mistaken we have temp {} and let {} using UNDO blocks (which are given
> : default definitions where possible). So perhaps we could use that
> : feature to provide a NEXT trait which actually executes only if there
> : is a next iteration, while giving the block the impression that it is
> : executing in the previous iteration. This, of course, would not work
> : for loops whose conditions have irreversible side-effects.
> :
> : Overall, it might be feasible in some circumstances, but it may not be
> : worth it. Its implementation (and usage caveats) are quite complex
> : for a relatively minor convenience feature. For a user to implement
> : its effect by himself, using the extended knowledge he has of the loop
> : semantics, would probably not take more than four extra lines in the
> : worst case.
>
> It would mean that we can't use NEXT to replace Perl 5's "continue"
> blocks, for instance, since those are required to run before the
> while loop's condition is tested. Which also basically means we
> couldn't rewrite loop (;;) using NEXT. So I think NEXT should just
> be equivalent to LEAVE from the viewpoint of conditionals outside
> the loop body. You have to use "last" to do better.
>
One alternative that would work well in many cases would be to define a
REENTER block, which would be called at the beginning of any loop iteration
after the first one. This would be much easier to implement that the idea of
NEXT blocks being mutually exclusive to LAST blocks, because it depends only
on what happened in the past, not the future. Luke's example could then be
implemented as
for @objs {
.print;
REENTER { print ", " }
LAST { print "\n" }
}
In a language that has both if and unless, it makes sense to have a block
that means not FIRST. I'm not sure about the name; besides REENTER, other
possible names would be SUBSEQUENT or NOTFIRST.
Joe Gottman
Re: multi-line comments, C macros, & Pod abuse
Stuart Cook writes:
> On 8/19/06, Larry Wall <[EMAIL PROTECTED]> wrote:
> >if 0 {
> >...
> >}
>
> The one disadvantage of that approach is that it will break if the
> "commented-out" code temporarily fails to compile. If that's a
> problem, though, you could always write your own macro.
You don't actually need a macro in that case:
if 0 { q<
...
> }
And if you have unbalanced quote-delimiting brackets in the "...", you can
switch to different bracketing characters (including arbitrary Ps/Pe or
bidi-mirroring Unicode pairs), or simply add more brackets:
if 0 { q
... # >>> with unmatched pointies
}
--
Aaron Crane
Re: multi-line comments, C macros, & Pod abuse
On 8/19/06, Aaron Crane <[EMAIL PROTECTED]> wrote:
You don't actually need a macro in that case:
if 0 { q<
...
> }
Which, of course, eliminates the original desire to have a
code-commenting construct where "you just change the 0 to a 1". After
all, we already have #{}. Incidentally, you could consider that the
desired construct, because it balances, and a closure at statement
level executes itself:
#{
if $baz {
$foo.bar
}
}
To uncomment, remove the # before the {.
Luke
[perl #40200] t/pmc/threads.t test 16 fails under JIT (parrot -j)
# New Ticket Created by Chip Salzenberg # Please include the string: [perl #40200] # in the subject line of all future correspondence about this issue. # http://rt.perl.org/rt3/Ticket/Display.html?id=40200 > After the STM merge, all of t/pmc/threads.t succeeds (woggle++). But one of the tests fails under JIT. I'm hoping that somebody will recognize the reason quickly, else I'll have to dive in... -- Chip Salzenberg <[EMAIL PROTECTED]>
