Name spaces of PIR identifiers
It seems that PIR uses only one name space of identifiers.
$ cat const.pir
.const int cst = 42
.sub 'cst'
print cst
.end
$ parrot const.pir
error:imcc:undefined identifier 'cst'
in file 'const.pir' line 5
$ cat label.pir
.const int L1 = 42
.sub 'main'
print L1
goto L1
L1:
.end
$ parrot label.pir
error:imcc:syntax error, unexpected VAR, expecting IDENTIFIER or
PARROT_OP ('L1')
in file 'label.pir' line 5
The expected behavior is not defined in ppd19.
François.
Re: [svn:parrot-pdd] r30569 - trunk/docs/pdds
Klaas-Jan Stol wrote: This must make the following syntax rule illegal: target = null because if null is declared as a .local, you can't know whether you want to nullify target, or want to set target's value to that of the .local variable null. I take it this is no problem; just stick to null target if you actually want to set target to 0/null. Yes, that's reasonable. The syntactic sugar was confusing in that case anyway. (Seemed like you were assigning a null value to the destination register, rather than nullifying the PMC in the destination register.) This belongs in a general category of opcodes where the standard transformation of call the opcode with the first argument stuck before an '=' sign doesn't really make sense. Allison
Speccing Test.pm?
Howdy, The test suite is considered official as in everything that passes the (completed) test suite may name itself Perl 6, and nearly all of these files 'use Test'; However we don't ship an official Test.pm, nor do we define which test functions it should contain and export by default, nor their semantics. Now this may sound a bit theoretical and far-fetched, but we've actually encountered test files that contain tests which are only in Rakudo's Test.pm (probably my fault), and otoh there are a few functions in pugs' Test.pm that are not used (for example unlike(), which is only used in t/02-test-pm/1-basic.t to test unlike()). So how should we proceed? Should I assemble a list of commonly used test functions and remove all others both in the Test.pm's and the test files? And then? Spec it? Or ship a prototype Test.pm as official? Cheers, Moritz -- Moritz Lenz http://perlgeek.de/ | http://perl-6.de/
Re: [svn:parrot-pdd] r30569 - trunk/docs/pdds
On Tue, Sep 2, 2008 at 12:43 PM, Allison Randal [EMAIL PROTECTED] wrote:
Klaas-Jan Stol wrote:
This must make the following syntax rule illegal:
target = null
because if null is declared as a .local, you can't know whether you want
to nullify target, or want to set target's value to that of the .local
variable null.
I take it this is no problem; just stick to
null target
if you actually want to set target to 0/null.
Yes, that's reasonable. The syntactic sugar was confusing in that case
anyway. (Seemed like you were assigning a null value to the destination
register, rather than nullifying the PMC in the destination register.)
This belongs in a general category of opcodes where the standard
transformation of call the opcode with the first argument stuck before an
'=' sign doesn't really make sense.
Allison
So, preferably, the special words in PIR will be allowed as identifiers
('if','unless', 'null') and PIR will DWIM. What about the type identifiers:
int, num, pmc, string; should these be allowed as identifiers? The currently
special PIR words such as if, unless, null are ops, and as opnames are
allowed as identifiers, allowing 'if', 'unless' and 'null' makes sense. The
type names on the other hand, are not related to PASM code, so I'd vote to
have them as 'reserved' words; but I'd just like to check now. (maybe the
general feeling is that there must be no reserved words in PIR...)
kjs
Re: [svn:parrot-pdd] r30569 - trunk/docs/pdds
Klaas-Jan Stol wrote:
So, preferably, the special words in PIR will be allowed as identifiers
('if','unless', 'null') and PIR will DWIM. What about the type identifiers:
int, num, pmc, string; should these be allowed as identifiers? The currently
special PIR words such as if, unless, null are ops, and as opnames are
allowed as identifiers, allowing 'if', 'unless' and 'null' makes sense. The
type names on the other hand, are not related to PASM code, so I'd vote to
have them as 'reserved' words; but I'd just like to check now.
AFAIK, you can never use a variable in any position where you can use a
type name. So, you can't declare a variable named 'foo' and then use it
as a type:
.local string foo
* .local foo thingy # (* not valid syntax)
And also, you can't use a type name as a variable, if you haven't
actually declared a variable of that name:
* pmc = hello # (* not valid syntax)
So, there's no reason this couldn't be valid syntax, because there's no
ambiguity:
.local pmc pmc
pmc = new String
pmc = hello
(maybe the
general feeling is that there must be no reserved words in PIR...)
Not no reserved words just the smallest set of reserved words
possible, which means not reserving words we don't need to reserve.
I'm not clear on why we need to reserve 'if', 'unless' and 'null'
either, since they never appear in locations that could be confused with
variables.
Allison
Re: [svn:parrot-pdd] r30569 - trunk/docs/pdds
On Tue, Sep 2, 2008 at 2:28 PM, Allison Randal [EMAIL PROTECTED] wrote:
Klaas-Jan Stol wrote:
So, preferably, the special words in PIR will be allowed as identifiers
('if','unless', 'null') and PIR will DWIM. What about the type
identifiers:
int, num, pmc, string; should these be allowed as identifiers? The
currently
special PIR words such as if, unless, null are ops, and as opnames are
allowed as identifiers, allowing 'if', 'unless' and 'null' makes sense.
The
type names on the other hand, are not related to PASM code, so I'd vote to
have them as 'reserved' words; but I'd just like to check now.
AFAIK, you can never use a variable in any position where you can use a
type name. So, you can't declare a variable named 'foo' and then use it as a
type:
.local string foo
* .local foo thingy # (* not valid syntax)
And also, you can't use a type name as a variable, if you haven't actually
declared a variable of that name:
* pmc = hello # (* not valid syntax)
So, there's no reason this couldn't be valid syntax, because there's no
ambiguity:
.local pmc pmc
pmc = new String
pmc = hello
(maybe the
general feeling is that there must be no reserved words in PIR...)
Not no reserved words just the smallest set of reserved words possible,
which means not reserving words we don't need to reserve.
I see.
I'm not clear on why we need to reserve 'if', 'unless' and 'null' either,
since they never appear in locations that could be confused with variables.
there's not a strict reason, no. In fact, it would be possible to allow
them, although the implementation of that will require a number of special
cases in the grammar (but doable, as far as my experiments showed me). The
only concern would be (as Andrew indicated as well), that you could write:
if null null goto goto
if you had declared null and goto as .locals.
Allison
kjs
[perl #58500] [BUG] round broken, bugfix included
# New Ticket Created by Stephen Simmons # Please include the string: [perl #58500] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org/rt3/Ticket/Display.html?id=58500 With revision 30669, I find the following behavior of round() sully:perl6 stephensimmons$ perl6 -e 'say round(3.5);' 4 sully:perl6 stephensimmons$ perl6 -e 'say round(3.4);' 3.9 sully:perl6 stephensimmons$ perl6 -e 'say round(3.6);' 4.1 It's trivial, but here is the diff of the fix: sully:perl6 stephensimmons$ svn diff -r HEAD src/builtins/math.pir Index: src/builtins/math.pir === --- src/builtins/math.pir (revision 30669) +++ src/builtins/math.pir (working copy) @@ -61,7 +61,7 @@ .param num a a += 0.5 $N0 = floor a -.return (a) +.return ($N0) .end After: sully:perl6 stephensimmons$ perl6 -e 'say round(3.4);' 3 sully:perl6 stephensimmons$ perl6 -e 'say round(4);' 4 sully:perl6 stephensimmons$ perl6 -e 'say round(3.6);' 4 Please let me know the proper form for submitting bug fixes. I remember reading it somewhere, but I couldn't find it tonight. Stephen Simmons
[perl #58488] crashing parrot when calling create_lexinfo
# New Ticket Created by Stephane Payrard
# Please include the string: [perl #58488]
# in the subject line of all future correspondence about this issue.
# URL: http://rt.perl.org/rt3/Ticket/Display.html?id=58488
One can crash calling rakudo on a file containing
eval 'class A { has $.a}; my $a = A.new();';
eval 'class A { has $.a}; my $a = A.new();';
eval 'class A { has $.a}; my $a = A.new();';
or by executing thrice the line
class A { has $.a}; my $a = A.new()
interactively in rakudo.
This is reproduceable on Mac OS X Leopard and cygwin.
The stack seems strange to me, it seems that the context of the eval
is left on the stack when it should not as a result we have many
runloops in the stack.
The stack trace is :
Exception Type: EXC_BAD_ACCESS (SIGBUS)
Exception Codes: KERN_PROTECTION_FAILURE at 0x0008
Crashed Thread: 0
Thread 0 Crashed:
0 libparrot.dylib 0x00702c4d create_lexinfo + 317
(pbc.c:993)
1 libparrot.dylib 0x007033c2 add_const_pmc_sub + 1202
(pbc.c:1193)
2 libparrot.dylib 0x0070485a e_pbc_emit + 570 (pbc.c:1865)
3 libparrot.dylib 0x006f9397 emit_flush + 199
(instructions.c:869)
4 libparrot.dylib 0x006f3c7e imc_compile_unit + 62
(imc.c:118)
5 libparrot.dylib 0x006f3dce imc_close_unit + 30
(imc.c:223)
6 libparrot.dylib 0x006e8128 yyparse + 3208 (imcc.y:718)
7 libparrot.dylib 0x006f39b5 compile_string + 197
(imcc.l:1342)
8 libparrot.dylib 0x00706ed7 imcc_compile + 519
(parser_util.c:802)
9 libparrot.dylib 0x007071ee imcc_compile_pir_ex + 46
(parser_util.c:986)
10 libparrot.dylib 0x00540ac8 pcf_P_Jt + 120 (nci.c:235)
11 libparrot.dylib 0x0062f340 Parrot_NCI_invoke + 176
(nci.pmc:310)
12 libparrot.dylib 0x004be05b Parrot_invokecc_p + 107
(core.ops:463)
13 libparrot.dylib 0x005761a7 runops_slow_core + 183
(runops_cores.c:222)
14 libparrot.dylib 0x00536d4f runops_int + 447
(interpreter.c:942)
15 libparrot.dylib 0x005376d2 runops + 194
(inter_run.c:105)
16 libparrot.dylib 0x00537974 runops_args + 436
(inter_run.c:237)
17 libparrot.dylib 0x00537aa9 Parrot_runops_fromc_args
+ 73 (inter_run.c:300)
18 libparrot.dylib 0x0052348c Parrot_ex_throw_from_c +
444 (exceptions.c:297)
19 libparrot.dylib 0x00523563
Parrot_ex_throw_from_c_args + 195 (exceptions.c:339)
20 libparrot.dylib 0x005f940f cant_do_method + 79
(default.pmc:63)
21 libparrot.dylib 0x005fc089
Parrot_default_get_string + 41 (default.c:1345)
22 libparrot.dylib 0x00569e26 fail_if_type_exists +
166 (oo.c:619)
23 libparrot.dylib 0x00569ec8 Parrot_oo_register_type
+ 24 (oo.c:653)
24 libparrot.dylib 0x0067ccf8 init_class_from_hash +
584 (class.pmc:222)
25 libparrot.dylib 0x0067e74b Parrot_Class_init_pmc +
555 (class.c:844)
26 libparrot.dylib 0x005757d0 pmc_new_init + 176
(pmc.c:369)
27 libparrot.dylib 0x004d395b Parrot_newclass_p_p + 59
(object.ops:249)
28 libparrot.dylib 0x005761a7 runops_slow_core + 183
(runops_cores.c:222)
29 libparrot.dylib 0x00536d4f runops_int + 447
(interpreter.c:942)
30 libparrot.dylib 0x005376d2 runops + 194
(inter_run.c:105)
31 libparrot.dylib 0x00537974 runops_args + 436
(inter_run.c:237)
32 libparrot.dylib 0x00537aa9 Parrot_runops_fromc_args
+ 73 (inter_run.c:300)
33 libparrot.dylib 0x0056b6e0 run_sub + 112
(packfile.c:496)
34 libparrot.dylib 0x0056b935 do_1_sub_pragma + 565
(packfile.c:589)
35 libparrot.dylib 0x0056bbb1 do_sub_pragmas + 289
(packfile.c:722)
36 libparrot.dylib 0x005701c9 PackFile_fixup_subs + 41
(packfile.c:3812)
37 libparrot.dylib 0x00706f46 imcc_compile + 630
(parser_util.c:822)
38 libparrot.dylib 0x007071ee imcc_compile_pir_ex + 46
(parser_util.c:986)
39 libparrot.dylib 0x00540ac8 pcf_P_Jt + 120 (nci.c:235)
40 libparrot.dylib 0x0062f340 Parrot_NCI_invoke + 176
(nci.pmc:310)
41 libparrot.dylib 0x004be05b Parrot_invokecc_p + 107
(core.ops:463)
42 libparrot.dylib 0x005761a7 runops_slow_core + 183
(runops_cores.c:222)
43 libparrot.dylib 0x00536d4f runops_int + 447
(interpreter.c:942)
44 libparrot.dylib 0x005376d2 runops + 194
(inter_run.c:105)
45 libparrot.dylib 0x00537974 runops_args + 436
(inter_run.c:237)
46
Re: Speccing Test.pm?
On Tue, Sep 02, 2008 at 02:10:39PM +0200, Moritz Lenz wrote: The test suite is considered official as in everything that passes the (completed) test suite may name itself Perl 6, and nearly all of these files 'use Test'; However we don't ship an official Test.pm, nor do we define which test functions it should contain and export by default, nor their semantics. Now this may sound a bit theoretical and far-fetched, but we've actually encountered test files that contain tests which are only in Rakudo's Test.pm (probably my fault), and otoh there are a few functions in pugs' Test.pm that are not used (for example unlike(), which is only used in t/02-test-pm/1-basic.t to test unlike()). So how should we proceed? Should I assemble a list of commonly used test functions and remove all others both in the Test.pm's and the test files? I'd like to see us spec the list of test functions needed by the official test suite. If possible, I'd also like those functions to be kept on simple side, so that an implementation doesn't have to have a nearly complete implementation of Perl 6 in order to start using the suite. For example, we shouldn't require advanced typing or multimethod dispatch semantics in order for Test.pm to work. And then? Spec it? Or ship a prototype Test.pm as official? I think it's good to have a prototype Test.pm that we can point to as a reference, but I don't think we need to try to designate it as being official. Pm
[perl #58506] Problem with :outer
# New Ticket Created by Stephen Weeks # Please include the string: [perl #58506] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org/rt3/Ticket/Display.html?id=58506 The attached pir file tries to call a sub set :outer() another sub without calling the outer sub first. This fails with: too few arguments passed (0) - 1 params expected current instr.: 'bar' pc 3 (tlib.pir:4) called from Sub 'foo' pc 19 (tlib.pir:10) Setting the outer sub to :load also works. I'm trying to do this because this is what the PIR PCT generates looks like, and I'm trying to use a precompiled test.rb for cardinal. Should I maybe be setting the top-level block to :load? Rakudo seems to not be encountering this issue because of some stuff done at :immediate time changing the $!proto of each sub. Any ideas? .sub foo :anon :lexid(1) .end .sub bar :lexid(2) :outer(1) .param pmc a print a .end .sub main :main 'bar'(9) .end
Re: [perl #58500] [BUG] round broken, bugfix included
Stephen Simmons (via RT) wrote: # New Ticket Created by Stephen Simmons # Please include the string: [perl #58500] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org/rt3/Ticket/Display.html?id=58500 With revision 30669, I find the following behavior of round() sully:perl6 stephensimmons$ perl6 -e 'say round(3.5);' 4 sully:perl6 stephensimmons$ perl6 -e 'say round(3.4);' 3.9 sully:perl6 stephensimmons$ perl6 -e 'say round(3.6);' 4.1 It's trivial, but here is the diff of the fix: sully:perl6 stephensimmons$ svn diff -r HEAD src/builtins/math.pir Index: src/builtins/math.pir === --- src/builtins/math.pir (revision 30669) +++ src/builtins/math.pir (working copy) @@ -61,7 +61,7 @@ .param num a a += 0.5 $N0 = floor a -.return (a) +.return ($N0) .end Thanks, applied as r30697. I also fudged the rounders.t file to work with rakudo (what a mess, see pugs revision 22098), and added it to spectest_regression (r30698) After: sully:perl6 stephensimmons$ perl6 -e 'say round(3.4);' 3 sully:perl6 stephensimmons$ perl6 -e 'say round(4);' 4 sully:perl6 stephensimmons$ perl6 -e 'say round(3.6);' 4 Please let me know the proper form for submitting bug fixes. I remember reading it somewhere, but I couldn't find it tonight. Yes it is. Thanks again. Moritz -- Moritz Lenz http://moritz.faui2k3.org/ | http://perl-6.de/
[perl #46823] [TODO] [Pir] Rewrite Resizeable*Array tests properly when exceptions are implemented
On Wed Aug 27 22:49:37 2008, cotto wrote: Most of these test wouldn't throw an exception anyway, since assigning to a positive out-of-bounds element simply resizes the array. (This excludes nonsensically large positive indicies, which should probably tested for.) I added exception handling for oob indicies to the one fixed array test in r30610, which still passes. I deleted the other references to this ticket. It's possible that out-of-bounds refers to negative indicies. I added some tests with exception handlers for those cases in r30611. If there are no objections, I'll mark this resolved after the weekend. Christoph Done.
[PATCH] cygwin070patches
Attached is a new patch for the cygwin070patches. This is against svn, so it replaces the patches _6 and _7. Fixed some logical flaw and enhanced the Makefiles. Renamed TMP to HLLNAME. -- Reini Urban http://phpwiki.org/ http://murbreak.at/ cygwin070patches_8.patch.gz Description: GNU Zip compressed data
Re: Speccing Test.pm?
Patrick R. Michaud wrote: On Tue, Sep 02, 2008 at 02:10:39PM +0200, Moritz Lenz wrote: And then? Spec it? Or ship a prototype Test.pm as official? I think it's good to have a prototype Test.pm that we can point to as a reference, but I don't think we need to try to designate it as being official. I think we *should* have an official Test.pm, but that it should be conceptualized in a slightly different way. Or actually I have 2 alternate proposals: 1. Rather than being a language extension, Test.pm should formally be part of the Perl 6 test suite itself, as the result of a refactoring; basically all tests have some common implementation parts and those have been refactored into a module, which is Test.pm. So then Test.pm is an integral part of the test suite itself, and if there is just one official test suite, then there is just an official Test.pm. Though for convenience this Test.pm would be installable so that other language extensions could use it in their tests, though. 2. The Perl 6 language spec itself would specify a basic set of test routines built-in to the language, in a Test namespace, much as it defines collections of routines now for such as numbers and arrays and standard I/O. And so the basic test routines would be formally defined in a Synopsis document. This shouldn't be onerous as there'd probably be only about a dozen such routines and given our experience it is probably reasonable they won't need to change much over time. So how these Test namespace routines are provided can then vary by the implementation but they would be standard to users of the language. Now a common factor to both of my proposals is that this Test.pm is intentionally kept as simple as possible and contains just the functionality needed to bootstrap the official Perl 6 test suite; if the official test suite doesn't use certain features, then they don't exist in this Test.pm, in general. There would still be room for third party Test modules, as those would be richer and provide functionality that would be useful for testing language extensions / CPAN modules but that aren't needed by the tests for Perl 6 itself. I should mention that I'm currently pursuing the #2 approach in my Muldis D language design, where the language spec itself includes a small number of common routines implementing the TAP protocol over standard I/O, so that tests written in the language can just use it without having to explicitly load a Test library like a user-defined library. An advantage of #2 is that you don't have to think so much about what other language features your Test.pm uses, since from the users' point of view they are themselves fundamental features; so implementers could even bootstrap them using native equivalents or a prelude. I also don't see the possibility of our getting it wrong in the design to be such a big deal, since the odds are anything we think of now will work well for many years, as Test.pm/Test::More has been fairly stable already and meanwhile Perl 6 is versioned now, so we could make an incompatible change to the Test related language spec in the future, and as long as users say use Perl-6.0.0 their code relying on the older/current Test.pm like interface won't break. -- Darren Duncan
Re: Speccing Test.pm?
On Tue, Sep 02, 2008 at 12:32:49PM -0700, Darren Duncan wrote: Patrick R. Michaud wrote: I think it's good to have a prototype Test.pm that we can point to as a reference, but I don't think we need to try to designate it as being official. [...] 2. The Perl 6 language spec itself would specify a basic set of test routines built-in to the language, in a Test namespace, much as it defines collections of routines now for such as numbers and arrays and standard I/O. And so the basic test routines would be formally defined in a Synopsis document. I disagree. The testing we're likely want to do as part of the language test suite may be substantially different from what we want to provide to module writers for testing. In particular, I think that the test suite harness should require only a minimal Perl 6 implementation (note I said harness, not the tests themselves), whereas it's much more reasonable that a testing system used by module writers could/should assume a fully working Perl 6 implementation. It's a difference of bootstrapping versus running environment. I also don't see the possibility of our getting it wrong in the design to be such a big deal, since the odds are anything we think of now will work well for many years, as Test.pm/Test::More has been fairly stable already and meanwhile Perl 6 is versioned now, so we could make an incompatible change to the Test related language spec in the future, and as long as users say use Perl-6.0.0 their code relying on the older/current Test.pm like interface won't break. Perl 6 is versioned now is a misnomer. The *spec* calls for a versioned Perl 6, but I'm not aware that any of the implementations do much with that. At any rate, relying on handling multiple versions of Perl 6 to run Test.pm is exactly one of those things I'd like to avoid in the official test suite. Pm
Re: Speccing Test.pm?
2. The Perl 6 language spec itself would specify a basic set of test routines built-in to the language, in a Test namespace That sounds like a good idea, but it would require that the above Test functionality be included in the automated tests... which runs the risk of infinite recursion.
[perl #38432] [BUG] Exception thrown from constructor leads to oddness
I don't get a segfault when running the test case without the 'end' opcode. Can anyone else confirm if this still segfaults? cet.pir Description: Binary data
[perl #58524] prefix:= doesn't read from $*IN in Rakudo
# New Ticket Created by Carl Mäsak # Please include the string: [perl #58524] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org/rt3/Ticket/Display.html?id=58524 r30698: ./perl6 -e 'say $*IN.readline' # works (i.e. repeats what I write) OH HAI! OH HAI! $ ./perl6 -e 'say =$*IN' # doesn't work 0 $ ./perl6 -e 'say =' # doesn't work -1
Re: What happened to err operator?
On Sun, Aug 31, 2008 at 04:28:36PM -0500, John M. Dlugosz wrote: Has the err operator, as a low-precidence version of //, been removed? Yes. It could be recycled as a fuzzy Boolean, returning a fractional value between +1 and -1, indicating the confidence with which the result is offerred. (As in err, I'm not sure. :-)* ) -- Email and shopping with the feelgood factor! 55% of income to good causes. http://www.ippimail.com
[perl #58526] pick(*) is broken on nested arrays in Rakudo
# New Ticket Created by Carl Mäsak # Please include the string: [perl #58526] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org/rt3/Ticket/Display.html?id=58526 r30698: $ ./perl6 -e 'say [1,2,3,4,5,6].pick(*)' # expected 645213 $ ./perl6 -e 'say [[1,2,3],[4,5,6]].pick(*)' # strange... 1234 $ ./perl6 -e 'say [[1,2,3],[4,5,6]].pick(*)' # ... 4561 The semantics seem to be that one array is randomly picked, flattened, and then a random element from the other array is picked. Not very intuitive behaviour, and probably not intended. A saner behaviour would be for pick not to flatten elements which happen to be arrays.
Re: What happened to err operator?
I think you're thinking of the erm operator... But back to orelse - is the only difference between and/or and andthen/orelse the fact that the result of the lhs gets passed as a parameter into the rhs? 'Cause I don't see the difference between short circuit and proceed on success/failure. On 9/2/08, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: On Sun, Aug 31, 2008 at 04:28:36PM -0500, John M. Dlugosz wrote: Has the err operator, as a low-precidence version of //, been removed? Yes. It could be recycled as a fuzzy Boolean, returning a fractional value between +1 and -1, indicating the confidence with which the result is offerred. (As in err, I'm not sure. :-)* ) -- Email and shopping with the feelgood factor! 55% of income to good causes. http://www.ippimail.com -- Sent from Gmail for mobile | mobile.google.com Mark J. Reed [EMAIL PROTECTED]
Re: What happened to err operator?
On Tue, Sep 02, 2008 at 07:56:33PM -0400, Mark J. Reed wrote:
: I think you're thinking of the erm operator...
:
: But back to orelse - is the only difference between and/or and
: andthen/orelse the fact that the result of the lhs gets passed as
: a parameter into the rhs? 'Cause I don't see the difference between
: short circuit and proceed on success/failure.
They're also different in the sense that and/or are boolean tests
while andthen/orelse are definedness tests, as currently specced.
For logic programming purposes, though, it's possible that we'll end
up with something in between, because in addition to distinguishing
success from failure, we may wish also to distinguish expected failure
(normal regex backtracking, for example) from unexpected failure
(abject parser failure, for example). In other words, when you say
a() orelse b()
you might want to:
succeed on a()
trap mild failure of a() and try to succeed on b() instead
fail completely on drastic failure of a()
At the moment this three-way distinction depends on whether a() returns
defined/undefined or throws an exception. Maybe that's good enough.
I don't want to overcomplexify things, but I don't want to
undercomplexify them either. :)
In the limit, one might want the entire power of a CATCH block on
the right side of orelse. Currently you'd have to write:
a() orelse do given $! {
when MajorMalfunction { die oopsie }
when * { b() }
}
or some such. Nest a few of those and it makes more sense to say
a() orelse
b() orelse
c() orelse
d() orelse
e();
CATCH {
when MajorMalfunction { die oopsie }
}
assuming that exceptions somehow get returned or thrown appropriately.
I suppose orelse could itself throw any exception that it doesn't want
to treat as benign, and the CATCH block would handle it. And the
definition of benign could then be pragmatically controlled if the
default wasn't good enough, I suppose.
Larry
[perl #58506] Problem with :outer
From: Stephen Weeks (via RT) [EMAIL PROTECTED] Date: Tue, 02 Sep 2008 01:21:49 -0700 # New Ticket Created by Stephen Weeks # Please include the string: [perl #58506] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org/rt3/Ticket/Display.html?id=58506 The attached pir file tries to call a sub set :outer() another sub without calling the outer sub first. This is almost guaranteed to cause problems. For one thing, if foo had .lex vars, they would be uninitialized. This fails with: too few arguments passed (0) - 1 params expected current instr.: 'bar' pc 3 (tlib.pir:4) called from Sub 'foo' pc 19 (tlib.pir:10) The Closure:invoke method [1] has the following comment in the code that implements its last-ditch attempt to make a LexPad: /* outer has never been invoked, we fake a subroutine call * which builds the LexPad and return immediately * this will usually just lead to a Null PMC access * exception */ I suspect this faked call is what's causing the too few arguments error (though none of my naive attempts to fix it worked). If this case is not covered by the test suite (I'm running an experiment now to see), then it may have been broken for about two years now, which (IIRC) is when strict parameter checking was turned on by default. So I doubt it should be fixed at all. Patrick is in the process redesigning how closures are taken, which will probably take care of it anyway. Setting the outer sub to :load also works. . . . Any ideas? That, I think, is your best bet. -- Bob Rogers http://rgrjr.dyndns.org/ [1] Line 140 in src/pmc/closure.pmc
[perl #58506] Problem with :outer
From: Bob Rogers [EMAIL PROTECTED] Date: Tue, 2 Sep 2008 21:55:54 -0400 . . . I suspect this faked call is what's causing the too few arguments error (though none of my naive attempts to fix it worked). If this case is not covered by the test suite (I'm running an experiment now to see), then it may have been broken for about two years now, which (IIRC) is when strict parameter checking was turned on by default. I was right; if you add fprintf(stderr, [no caller for closure %p]\n, SELF); to the block after the comment I quoted, this message does not appear in make test output. -- Bob
