Should !~~ /regex/ set $/?

2008-09-06 Thread Moritz Lenz
The subject says it all: should !~~ with a regex on the RHS set $/?

Cheers,
Moritz

-- 
Moritz Lenz
http://moritz.faui2k3.org/ |  http://perl-6.de/


Re: [perl #58626] default and when * execute even when another when clause is used

2008-09-06 Thread John M. Dlugosz
The when statements are just like if statements.  After executing one, 
it goes on to the following statement which does not have to be a 
conditional statement.  That is, you can mix when statements with plain 
unconditional statements.


If multiple when conditions match, it runs all of them.  It's more like 
if statements, not like a C switch statement. 


--John

Stephen Simmons (via RT) wrote:
# New Ticket Created by  Stephen Simmons 
# Please include the string:  [perl #58626]
# in the subject line of all future correspondence about this issue. 
# URL: http://rt.perl.org/rt3/Ticket/Display.html?id=58626 



In the attached code, there is a fairly simple example of a case statement
using given/when that has multiple clauses executed.  I assumed from my
reading of S04 that if one of the when block is taken, when it finishes
control exits the innermost given block, though the English is confusing to
me.  However it doesn't and continues on to both the when * clause and the
default clause.
Execution:
sully:perl6 stephensimmons$ adventure_world/a1b.p6
You are at (0, 0) within region outside.
n
Oops!;
What does n mean?
You are at (0, 1) within region outside.
  




Re: Should !~~ /regex/ set $/?

2008-09-06 Thread Larry Wall
On Sat, Sep 06, 2008 at 11:44:05AM +0200, Moritz Lenz wrote:
: The subject says it all: should !~~ with a regex on the RHS set $/?

For now I would assume that the meta operator rewrites

$a !~~ $b

to

(not $a ~~ $b)

so .ACCEPTS has no clue that it is dealing with a negated operator.
In other words, it sets $/ just like the normal ~~ operator, but
the boolean sense comes out backwards:

if $a !~~ /foo/ {
# $/ is false
}
else {
# $/ is true
}

Larry


Re: [perl #58626] default and when * execute even when another when clause is used

2008-09-06 Thread Larry Wall
On Sat, Sep 06, 2008 at 11:38:42AM -0500, John M. Dlugosz wrote:
 The when statements are just like if statements.  After executing one,  
 it goes on to the following statement which does not have to be a  
 conditional statement.  That is, you can mix when statements with plain  
 unconditional statements.

 If multiple when conditions match, it runs all of them.  It's more like  
 if statements, not like a C switch statement. 

No, when statements also imply a break at the end of the block.  It
should never run more than one (unless you explicitly say continue).
You can mix unconditional statements, but any after the first matching
when will not be run (unless you say continue).

If both when * and default are running, it's a small bug,
indicating that the when * {...} got turned into a mere {...}
or ... on the assumption that you don't actually have to test for
the default condition.  Which you don't, but it should still run
only one default block, so it should really turn into something like
{...; break}.

Larry


Re: Should !~~ /regex/ set $/?

2008-09-06 Thread Nicholas Clark
On Sat, Sep 06, 2008 at 09:41:07AM -0700, Larry Wall wrote:
 On Sat, Sep 06, 2008 at 11:44:05AM +0200, Moritz Lenz wrote:
 : The subject says it all: should !~~ with a regex on the RHS set $/?
 
 For now I would assume that the meta operator rewrites
 
 $a !~~ $b
 
 to
 
 (not $a ~~ $b)

Perl 5 still does exactly this - there is no !~ opcode - the compiler just
generates the optree for ! of =~, and it is indistinguishable from it:

$ perl -MO=Deparse -e 'print if $^X !~ /perl/'
print $_ if not $^X =~ /perl/;
-e syntax OK
$ perl -MO=Deparse -e 'print if not $^X =~ /perl/'
print $_ if not $^X =~ /perl/;
-e syntax OK

Nicholas Clark


Re: Conceptual question on exception in S04

2008-09-06 Thread Larry Wall
On Wed, Sep 03, 2008 at 06:44:22PM -0500, John M. Dlugosz wrote:
 I'm trying to work out some details of this area, but I don't understand 
 what S04 is trying to say.  Could someone please point me in the right 
 direction?  I'd be happy to then edit the S04 to contribute.


 In S04, the Exceptions section mentions that $! contains multiple 
 exceptions.
  So what type is it?  Why isn't it @! ?  I says that they are thrown as a
 single new exception.  So what type is that new exception?  A multi-exception 
 of
 some kind?

No, just the new exception, which merely has to contain the old
unhandled exceptions somehow in case the user wants more information.

 How do you get multiple pending exceptions in the first place?

 If you mean that exceptions can be thrown (and handled) within the handling of
 another exception, then the list should be more of a stack.  Should the 
 handler
 then see the topmost one as its topic?  If you really did make the whole list
 the topic then it would be difficult to match.

All I care is that we don't discard useful information here.  Only the
outermost exception needs to be directly matchable against via $!.

 How would you access the other exceptions in $!, presumably testing them for
 .defined etc.?

I would assume that the $! object can be accessed as an array in that
case, unless someone can argue for a different interface.

By the way, I'd like to see a user interface where the outer exception
is the one printed out in simple form, with the complete cockpit
recorder dump of information going into a file that is browser
accessible with a click on a link in the error message to more info.

Larry


Re: [perl #58626] default and when * execute even when another when clause is used

2008-09-06 Thread Stephen Simmons

On Sep 6, 2008, at 10:51 AM, Larry Wall wrote:


On Sat, Sep 06, 2008 at 11:38:42AM -0500, John M. Dlugosz wrote:
The when statements are just like if statements.  After executing  
one,

it goes on to the following statement which does not have to be a
conditional statement.  That is, you can mix when statements with  
plain

unconditional statements.

If multiple when conditions match, it runs all of them.  It's more  
like

if statements, not like a C switch statement.


No, when statements also imply a break at the end of the block.  It
should never run more than one (unless you explicitly say continue).
You can mix unconditional statements, but any after the first matching
when will not be run (unless you say continue).

If both when * and default are running, it's a small bug,
indicating that the when * {...} got turned into a mere {...}
or ... on the assumption that you don't actually have to test for
the default condition.  Which you don't, but it should still run
only one default block, so it should really turn into something like
{...; break}.


I've set up two identical when blocks, followed by a when * and a  
default and all of them run, which is consistent with the behavior  
that John describes.  The current behavior is no different from a if  
EXPR block which is shorter to type, so I'm glad that the intended  
behavior is to break out on success.


Patrick merged this with #57652, and there is a comment in the code  
that marks this behavioral problem as a todo (in src/parser/actions.pm).


Stephen Simmons




Larry





Re: Conceptual question on exception in S04

2008-09-06 Thread John M. Dlugosz



Larry Wall larry-at-wall.org |Perl 6| wrote:

No, just the new exception, which merely has to contain the old
unhandled exceptions somehow in case the user wants more information.

  
OK, so it's more like the inner exception in Microsoft's .NET 
framework.  My C++ exceptions have always had the ability to record 
multiple stanzas of information, to re-throw and update the picky 
details with context-specific interpretation. 

It sounds like what you want is that if there is a pending unhandled 
exception in dynamic scope, then 'die' or the fresh Exception object's 
constructor will automatically pick that up as the inner exception.




By the way, I'd like to see a user interface where the outer exception
is the one printed out in simple form, with the complete cockpit
recorder dump of information going into a file that is browser
accessible with a click on a link in the error message to more info.

Larry

  


I did that about fifteen years ago.  The dialog box had a drop-down to 
show all the layers of information, and also a save button.  The format 
predates XML though, and was designed for high-speed and failsafe 
logging, so it used control characters instead of XML-like tags.


--John


Re: adverbial form of Pairs notation question

2008-09-06 Thread Larry Wall
On Sat, Sep 06, 2008 at 07:06:30PM +1100, Илья wrote:
: Hello there,
: what :foo should exactly produce?
: At first I was expecting:
: foo = 
: but in Rakudo:
: foo = []
: and it looks like the right thing on the other hand.
: 
: (I have started this topic in the November mail list
: 
http://groups.google.com/group/november-wiki/browse_thread/thread/939216e836f69baa
: )

As mentioned on irc, it should do the same thing as foo = ().
The question is whether () in item context promotes to [].  I don't
think it ought to, since () is really the only way we have of writing
NIL in Perl 6, and [] isn't really NIL.  And I think it would be odd
to have *two* discontinuities:

item (1,2)  # [1,2]
item (1)# (1)
item () # []???

One discontinuity is bad enough:

item (1,2)  # [1,2]
item (1)# (1)
item () # ()

Essentially, the () value lazily produces undef if you actually try to
access its (first) value, whereas () in list context merely interpolates
nothing.  On the other hand, if () isn't NIL, then we have

item (1,2)  # [1,2]
item (1)# (1)
item () # Failure of some sort

But basically I think NIL is a mild form of failure anyway, so it's
fine with me if () is a form of failure that is smart enough to be
itself in item context but interpolate nothing into list context.
Another view is that it's a kind of empty capture that is smart enough
to convert to failure in item context.  Possibly the right side of
a pair should be capture context rather than item context.  Not sure
about that...

Larry


Re: adverbial form of Pairs notation question

2008-09-06 Thread Brandon S. Allbery KF8NH

On 2008 Sep 6, at 13:57, Larry Wall wrote:

But basically I think NIL is a mild form of failure anyway, so it's
fine with me if () is a form of failure that is smart enough to be


I'm thinking () is the non-scalar (list, array, capture, maybe hash)  
version of undef, which acts like a value unless you have warnings  
turned on; and undef is managed as a kind of unthrown exception  
already, thus so should ().


--
brandon s. allbery [solaris,freebsd,perl,pugs,haskell] [EMAIL PROTECTED]
system administrator [openafs,heimdal,too many hats] [EMAIL PROTECTED]
electrical and computer engineering, carnegie mellon universityKF8NH




[svn:perl6-synopsis] r14580 - doc/trunk/design/syn

2008-09-06 Thread larry
Author: larry
Date: Sat Sep  6 21:22:00 2008
New Revision: 14580

Modified:
   doc/trunk/design/syn/S03.pod

Log:
where as Junctional infix resembling , but with order guaranteed


Modified: doc/trunk/design/syn/S03.pod
==
--- doc/trunk/design/syn/S03.pod(original)
+++ doc/trunk/design/syn/S03.podSat Sep  6 21:22:00 2008
@@ -12,9 +12,9 @@
 
   Maintainer: Larry Wall [EMAIL PROTECTED]
   Date: 8 Mar 2004
-  Last Modified: 21 Jun 2008
+  Last Modified: 6 Jun 2008
   Number: 3
-  Version: 137
+  Version: 138
 
 =head1 Overview
 
@@ -38,7 +38,7 @@
 L  Additive  + - +| +^ ~| ~^ ?| ?^
 L  Replication   x xx
 X  Concatenation ~
-X  Junctive and  
+X  Junctive and   where
 X  Junctive or   | ^
 L  Named unary   sleep abs sin
 N  Nonchaining infix but does = leg cmp .. ..^ ^.. ^..^
@@ -947,6 +947,23 @@
 
 $a  $b  $c ...
 
+=item *
+
+C infix:where , sequential junctional and operator
+
+EXPR where EXPR where EXPR ...
+
+Can be used to construct ANDed patterns with the same semantics as
+C infix: , but with left-to-right evaluation guaranteed, for use
+in guarded patterns:
+
+$target ~~ MyType where .mytest1 where .mytest2
+
+This is useful when later tests might throw exceptions if earlier
+tests don't pass.  This cannot be guaranteed by:
+
+$target ~~ MyType  .mytest1  .mytest2
+
 =back
 
 =head2 Junctive or (any) precedence