Re: RFC 120 (v1) Implicit counter in C statements, possibly C<$#>.

[Graham Barr]

On Wed, Aug 16, 2000 at 11:42:20AM -1000, Tim Jenness wrote:
> What about:
> 
>  for (0..$#array) {
>  print $array[$i], " is at index ", $i, "\n";
>  }
> 
> I use that whenever I need to loop over indices of two arrays at once.

And with the proposed zip() you may be able to do something like

  for my($val,$i) (zip(@array,0..$#array)) {
  }

Graham.

Re: Toward an omnibus Perl 6 Exceptions RFC, v0.1.

[Tony Olekshy]

Kai Henningsen wrote:
> 
> Tony Olekshy wrote:
> 
> > What if we implemented something like the following?
> 
> Seems that the basic unwinder is
> 
> > except { ... } => catch { ... }
> 
> and everything else can be written in terms of this:
> 
> > catch { ... }
> 
> except { 1 } => catch { ... }

Yes.  But a simple try { } catch { } is a common use.

> > catch "ClassName" { ... }
> 
> except { $@->isa($ClassName") } catch { }

Yes.  This one's clearly syntactic sugar, but it may very well be
quite a common usage if Perl 6 goes to internal error exceptions.

> > finally { ... }
> 
> except { 1 } => catch { ... ; throw $@ }

No.  The finally clause must be invoked whether or not anything
has thrown since the beginning of the try.  Except { 1 } will
*not* match if nothing has been thrown.  Catch and finally are
semantically very distinct.

Yours, &c, Tony Olekshy

Re: RFC 120 (v1) Implicit counter in C statements, possiblyC<$#>.

[Tim Jenness]

On 16 Aug 2000, Perl6 RFC Librarian wrote:

> This and other RFCs are available on the web at
>   http://dev.perl.org/rfc/
> 
> =head1 TITLE
> 
> Implicit counter in C statements, possibly C<$#>.
> 
> =head1 VERSION
> 
>   Maintainer: John McNamara <[EMAIL PROTECTED]>
>   Date: 16 Aug 2000
>   Version: 1
>   Mailing List: [EMAIL PROTECTED]
>   Number: 120
> 

> However, the latter format is often more convenient if you need to keep track of the 
>array index as well as iterating over the array:
> 
> for ($i = 0; $i <= $#array; $i++) {
> print $array[$i], " is at index ", $i, "\n";
> }
> 
> is more succinct than:
> 
> $i = 0;
> foreach $item (@array) {
> print $item, " is at index ", $i, "\n";
> $i++;
> }
> 

What about:

 for (0..$#array) {
 print $array[$i], " is at index ", $i, "\n";
 }

I use that whenever I need to loop over indices of two arrays at once.

-- 
Tim Jenness
JCMT software engineer/Support scientist
http://www.jach.hawaii.edu/~timj

RFC 120 (v1) Implicit counter in C statements, possibly C<$#>.

[Perl6 RFC Librarian]

This and other RFCs are available on the web at
  http://dev.perl.org/rfc/

=head1 TITLE

Implicit counter in C statements, possibly C<$#>.

=head1 VERSION

  Maintainer: John McNamara <[EMAIL PROTECTED]>
  Date: 16 Aug 2000
  Version: 1
  Mailing List: [EMAIL PROTECTED]
  Number: 120

=head1 ABSTRACT

The syntax of Perl style C statements could be simplified by the introduction of 
an implicit counter variable. The deprecated variable C<$#> could be used for this 
purpose due to its mnemonic association with C<$#array>.

=head1 DESCRIPTION

The following discussion make no differentiation between the C and C 
statements.

The use of the C statement or the C statement in conjunction with the 
range operator, C<..>, are generally seen as good idiomatic Perl:

@array = qw(sun moon stars rain);

foreach $item (@array) {
print $item, "\n";
}

as opposed to the "endearing attachment to C" style:

for ($i = 0; $i <= $#array; $i++) {
print $array[$i], "\n";
}

However, the latter format is often more convenient if you need to keep track of the 
array index as well as iterating over the array:

for ($i = 0; $i <= $#array; $i++) {
print $array[$i], " is at index ", $i, "\n";
}

is more succinct than:

$i = 0;
foreach $item (@array) {
print $item, " is at index ", $i, "\n";
$i++;
}

The addition of an implicit counter variable in C statements would lead to a more 
elegant syntax. It is proposed that the deprecated variable C<$#> should be used for 
this purpose due to its mnemonic association with C<$#array>. For example:

foreach $item (@array) {
print $item, " is at index ", $#, "\n";
}


The variable C<$#> currently holds the output format for printed numbers. 


=head1 IMPLEMENTATION

Not sure. However, consideration would have to be given to nested C statements 
and how the variable would be affected by C.

=head1 REFERENCES

perldoc perlvar

Alex Rhomberg proposed an implicit counter variable on clpm: 
http://x53.deja.com/getdoc.xp?AN=557218804&fmt=text and 
http://x52.deja.com/threadmsg_ct.xp?AN=580369190.1&fmt=text 

Craig Berry suggested C<$#>: 
http://x52.deja.com/threadmsg_ct.xp?AN=580403316.1&fmt=text

Re: Toward an omnibus Perl 6 Exceptions RFC, v0.1.

[Kai Henningsen]

[EMAIL PROTECTED] (Tony Olekshy)  wrote on 15.08.00 in 
<[EMAIL PROTECTED]>:

> What if we implemented something like the following?

Seems that the basic unwinder is

> except { ... } => catch { ... }

and everything else can be written in terms of this:

> catch { ... }

except { 1 } => catch { ... }

> catch "ClassName" { ... }

except { $@->isa($ClassName") } catch { }

> finally { ... }

except { 1 } => catch { ... ; throw $@ }


MfG Kai

Re: "Try? There is no try." -- Yoda's Exception handling syntax

[Barrie Slaymaker]

[perl6-annonce list snipped from Cc:, didn't even notice it the first time]

"Brust, Corwin" wrote:
> 
> Let me see If I have it...
> 
> try {...} is synonmous with eval {...} which is syntatic sugar for { ... }

Hmmm, I think I'd put it this way: if there's a catch or cleanup statement
(however they're speled) after the closing '}', any BLOCK is promoted to be
an 'eval { ... }' BLOCK.  And eval could be spelled 'try', of course.

Not sure that the following need work, though I think it looks ok in 
a short example (the cuddling is my way of hinting that the catch and
cleanup BLOCKs are tightly associated with the preceding BLOCKs.:

   if ( foo ) {
  kaboom ;
   } catch X::blah {
   }
   else {
   } cleanup {
   }

I kind like this, though:

   while (<>) {
   } cleanup {
   }

> So the changes, as far as diction is concerned would be:
> 
> New keywords:
> try(same as eval)

I suggest not changing the spelling of eval unless need be.

> catch  (same as C, or maybe C)

Just to be clear, I see it as more like Jave/C++ catches than perl's
else statement.  It needs one or more matching expressions, and perhaps
a variable name:

   catch my X::err1, X:Err2 $x {
   }

But that's being hashed out separately.

- Barrie

RE: "Try? There is no try." -- Yoda's Exception handling syntax

[Brust, Corwin]

-Original Message-
From: Barrie Slaymaker [mailto:[EMAIL PROTECTED]]
>[EMAIL PROTECTED] wrote:
>> 
>> It basically allows the programmer to "try" a certain action and see what
the
>> effects are going to be (i.e. handle the exception) so that some action
can
>> then be taken based on the results of the exception.

>Seems like any BLOCK could be an implicit eval {...} or try {...}, with the
>exception handling stuff triggered by following catch or (finally|cleanup)
>blocks:
>
>   {
>  kaboom ;
>   }
>   catch blah {
>   }
>   cleanup {
>   }
>
>This is like BLOCKs-as-loops.  Personally the extra 3 or 4 letters to spell
>eval or try don't matter that much to me, and it would make some folks feel
>more at home.  Though they could be optional, like 'return' before the
final
>expression in a sub.


I like this.  M so sweet. 

Let me see If I have it...

try {...} is synonmous with eval {...} which is syntatic sugar for { ... }
any / all of which can:

contain C statments

be followed by (one or more?) catch blocks to evaluate code only if
somthing got tossed by the block

be followed by one (or more??) finally blocks containing code to be
evaluated 
requardless of the result of the  qw(try eval anon) block

So the changes, as far as diction is concerned would be:

New keywords:
try(same as eval)

catch  (same as C, or maybe C)

finaly (same as {...})

throw  (kinda like C)

The catch being that throw does some stack preservation specialness, and
probably pushes some info onto an exception stack for later unwrapping when
main goes and tries to explain what happened.

So what am I missing (please not everyone at once ;)

-Corwin

RE: "Try? There is no try." -- Yoda's Exception handling syntax

[Brust, Corwin]

-Original Message-
From: Barrie Slaymaker [mailto:[EMAIL PROTECTED]]
>[EMAIL PROTECTED] wrote:
>> 
>> It basically allows the programmer to "try" a certain action and see what
the
>> effects are going to be (i.e. handle the exception) so that some action
can
>> then be taken based on the results of the exception.

>Seems like any BLOCK could be an implicit eval {...} or try {...}, with the
>exception handling stuff triggered by following catch or (finally|cleanup)
>blocks:
>
>   {
>  kaboom ;
>   }
>   catch blah {
>   }
>   cleanup {
>   }
>
>This is like BLOCKs-as-loops.  Personally the extra 3 or 4 letters to spell
>eval or try don't matter that much to me, and it would make some folks feel
>more at home.  Though they could be optional, like 'return' before the
final
>expression in a sub.


I like this.  M so sweet. 

Let me see If I have it...

try {...} is synonmous with eval {...} which is syntatic sugar for { ... }
any / all of which can:

contain C statments

be followed by (one or more?) catch blocks to evaluate code only if
somthing got tossed by the block

be followed by one (or more??) finally blocks containing code to be
evaluated 
requardless of the result of the  qw(try eval anon) block

So the changes, as far as diction is concerned would be:

New keywords:
try(same as eval)

catch  (same as C, or maybe C)

finaly (same as {...})

throw  (kinda like C)

The catch being that throw does some stack preservation specialness, and
probably pushes some info onto an exception stack for later unwrapping when
main goes and tries to explain what happened.

So what am I missing (please not everyone at once ;)

-Corwin

Re: "Try? There is no try." -- Yoda's Exception handling syntax

[Dave Storrs]

On Tue, 15 Aug 2000, Peter Scott wrote (with >):

[what is the purpose of having an explicit 'try']

> Well, for one, it makes it easier to see that a block is subject to 
> exception handling if all you have to do is look at the beginning for 'try' 
> rather than scan through it for a 'catch'. 

A good point.

> And there's the issue Jonathan Scott Duff raised, which is that the
> question of which catch blocks will be applied in what order is
> non-obvious to the user, even though there may be a well-defined
> interpretation.

I disagree with this point.  Catch blocks should simply be
applied in the order written.  If you have a "floating" catch block--i.e.,
one that isn't connected to anything that throws an exception--then you
have some code that will never run.  No big deal, and possibly useful as
yet another option for Multi-Line-Comments.

For example (I'm redoing this from memory, so forgive me if it's
not exact):

catch Baseball {A}
Quarterback(); # throws FootBall
catch Football {B}

In this example, B would be called and A wouldn't.  OTOH:

catch Baseball {A}
Pitcher(); # throws Baseball
catch Football {B}

A Baseball exception would be thrown but not caught.  No problem.


Dave

Re: "Try? There is no try." -- Yoda's Exception handling syntax

[Dave Storrs]

On Tue, 15 Aug 2000, David L. Nicol wrote:

> What if "try" were implied by the appearance of "catch" keywords, which
> expire at the close of their block?
> 
>   catch [EXCEPTION [, ...] ] BLOCK
>   ,...
>   BLOCK

[e.g.]
>   catch Exception::MyDB, Exception::DBI {
>close_database();
># other stuff
>   } 
>   catch Exception::IO {
>close_network_connection();
># other stuff
>   } 


I'd prefer to see the error handling come at the end, so that it
can be pushed off to one side.  For example, if your formal syntax is:

BLOCK catch [EXCEPTION [, ...] ] [BLOCK] [, [EXCEPTION [, ...] ] [BLOCK]]

Then you can write the following:

{
close_database();
close_network_connection()
}catch Exception::DBI {handle_this;},  
   Exception::IO, Exception::IO::FOO{handle_that;}


This keeps the real code in one tight group and puts all the error
handling off to one side where it doesn't clutter up your visual field.
You can always rewrite it in a more traditional indentation, as:

{
close_database();
close_network_connection()
} catch Exception::DBI {handle_this;},  
Exception::IO, Exception::IO::FOO{handle_that;}


But I like the first way better.  

Note that I have marked the handler block as optional.  If there
is no handler block found, the exception should just be eaten and the
program should continue.  If this means that your program crashes...well,
that's the programmer's fault for not handling errors appropriately, not
the language's.

Dave

Re: RFC 63 (v3) Exception handling syntax

[Dave Rolsky]

On 15 Aug 2000, Perl6 RFC Librarian wrote:

> =head2 Exceptions
> 
> Exceptions are objects belonging to some C class.  Cing
> an exception creates the object; therefore, C above is just a
> class name.  C lets you subclass C to create them;
> C appears to be a better name for a core functionality.
> 
> The C function is just syntactic sugar for creating a new
> exception class;it merely amounts to C<@EXCEPTION::ISA = 'Exception'>.

I think its important to also provide some syntactic sugar for creating a
hierarchical structure more than 2 levels deep.

For example, I may have an Exception::Foo and then want an
Exception::Foo::DB subclass of it.

My Exception::Class module on CPAN is pretty much all about being able to
do this easily.  It also implements a base exception but that's really for
convenience and isn't necessary.


-dave

/*==
www.urth.org
We await the New Sun
==*/

Re: "Try? There is no try." -- Yoda's Exception handling syntax

[Steve Simmons]

This discussion would be a better fit in [EMAIL PROTECTED]

Re: "Try? There is no try." -- Yoda's Exception handling syntax

[Barrie Slaymaker]

[EMAIL PROTECTED] wrote:
> 
> It basically allows the programmer to "try" a certain action and see what the
> effects are going to be (i.e. handle the exception) so that some action can
> then be taken based on the results of the exception.

Seems like any BLOCK could be an implicit eval {...} or try {...}, with the
exception handling stuff triggered by following catch or (finally|cleanup)
blocks:

   {
  kaboom ;
   }
   catch blah {
   }
   cleanup {
   }

This is like BLOCKs-as-loops.  Personally the extra 3 or 4 letters to spell
eval or try don't matter that much to me, and it would make some folks feel
more at home.  Though they could be optional, like 'return' before the final
expression in a sub.

- Barrie

RE: "Try? There is no try." -- Yoda's Exception handling syntax

[bbehrens]

I do not know what advantages the try statement would have in perl.
However, in Java programming it makes exception handling more explicit.  It
basically allows the programmer to "try" a certain action and see what the
effects are going to be (i.e. handle the exception) so that some action can
then be taken based on the results of the exception.  If no exception
happens then the code did exactly as you expected.  If not, then perhaps the
action was not appropriate for that peice of code.  This can be useful in an
OO application.

- Bradley S. Behrens

-Original Message-
From: Graham Barr [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, August 16, 2000 3:23 AM
To: David L. Nicol
Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED];
[EMAIL PROTECTED]
Subject: Re: "Try? There is no try." -- Yoda's Exception handling syntax


On Tue, Aug 15, 2000 at 08:11:55PM +, David L. Nicol wrote:
> Would someone please enlighten me as to the purpose of an explicit "try."

In my mind it allows the important code to come before the "oh crap
something
went wrong" code.

Graham.

Re: "Try? There is no try." -- Yoda's Exception handling syntax

[Graham Barr]

On Tue, Aug 15, 2000 at 08:11:55PM +, David L. Nicol wrote:
> Would someone please enlighten me as to the purpose of an explicit "try."

In my mind it allows the important code to come before the "oh crap something
went wrong" code.

Graham.

Re: RFC 63 (v3) Exception handling syntax

[Graham Barr]

On Tue, Aug 15, 2000 at 04:39:24PM -0700, Peter Scott wrote:
> >PRL> =head2 Exception classes - ignoring
> >
> >PRL> Note that we could also make it possible to selectively or globally 
> >ignore
> >PRL> exceptions, so that perl continues executing the line after the C
> >PRL> statement.  Just import a C function that takes a class name:
> >
> >PRL>  ignore Exception::IO; # Ignore all I/O exceptions
> >PRL>  ignore Exception; # Ignore all exceptions
> >
> >PRL> and when perl sees the C, it just does nothing.  (Or do it by
> >PRL> overriding a base class method as for C if you 
> >don't want
> >PRL> to put another function in the namespace.)  Since C and C
> >PRL> should be essentially identical, this would allow any kind of 
> >exception to
> >PRL> be ignored, not just the ones that were Cn.  This is not 
> >necessarily
> >PRL> a good thing, of course.
> >
> >
> >Oh, no! Are you really suggesting that after
> >
> > open (FOO, "nonesuch") or throw "file not found"
> >
> >The next statement continues??
> >
> >How in $DIETY's name do you expect to protect code?
> 
> I said it wasn't necessarily a good thing :-)  It's in the grand Perl 
> tradition of giving you enough rope to hang yourself.  If someone really 
> chooses to ignore exceptions, they deserve what they get.  Or maybe, 
> they're some kind of wizard who has a good reason in some arcane 
> situation.  If you like we could stuff it in a Devel:: module.  But at 
> least one person had asked for this IIRC.

This is bad, VERY bad. This is action at a distance worse than the current
$SIG{__DIE__} situation which nobody likes.

Graham.

Re: Exceptions and Objects

[Piers Cawley]

Graham Barr <[EMAIL PROTECTED]> writes:
> Also, I have come to dislike the name `exception', its too long for me :)
> and who says we have to copy everyone else.
> 
> Lookin in the thesaurus we get
> 
> [Nouns] nonconformity [more]; unconformity, disconformity;
> unconventionality, informality, abnormity,
> abnormality, anomaly; anomalousness; exception, peculiarity; infraction
> of law, breach, of law, violation of law, violation of custom, violation
> of usage, infringement of law, infringement of custom, infringement
> of usage; teratism, eccentricity, bizarrerie, oddity, je ne sais quoi,
> monster, monstrosity, rarity; freak, freak of Nature, weirdo, mutant;
> rouser, snorter [U.S.].
> 
> As perl is an exceptional language itself, why not have
> `freaks' instead :)

Note that exception has the advantage of being reasonably neutral on
the good/bad axis, which means that when you do something like:

try {
while (42) {
my $result = roll_the_dice;
throw Exception::Winner->new($result);
}
}
catch Exception::Winner {
print "We have a Winner!";
}

Then it doesn't seem quite so weird. Whatever word we end up with
should convey the sense of 'unusual' without any negative connotation.
IMHO of course.

-- 
Piers

Re: "Try? There is no try." -- Yoda's Exception handling syntax

[Piers Cawley]

Jonathan Scott Duff <[EMAIL PROTECTED]> writes:

> On Tue, Aug 15, 2000 at 04:12:17PM -0700, Peter Scott wrote:
> > >Would someone please enlighten me as to the purpose of an explicit "try."
> > 
> > Well, for one, it makes it easier to see that a block is subject to 
> > exception handling if all you have to do is look at the beginning for 'try' 
> > rather than scan through it for a 'catch'.
> 
> On Tue, Aug 15, 2000 at 06:24:08PM -0600, Tony Olekshy wrote:
> > The "try" is not necessarily for Perl's sake.  It's for the
> > programmer's sake.  It says, watch out, some sort of non-local
> > flow control may be going on here.  It signals intent to deal
> > with action at a distance (unwinding semantics).
> 
> How important are the exceptions?  What about putting them first?
> 
>   exceptions { 
>  # code that does exception handling
>   } 
>   {
>  # code that may throw exceptions
>   }
> 
> Note that's a two-block keyword.


Hm...


try {
# this
throw $that;
}
catch It {
# Do stuff
}

Has the advantage of reflecting the order in which things may actually
happen, whereas the two block thing doesn't.

-- 
Piers

Re: RFC 63 (v3) Exception handling syntax

[Piers Cawley]

Chaim Frenkel <[EMAIL PROTECTED]> writes:

> > "PRL" == Perl6 RFC Librarian <[EMAIL PROTECTED]> writes:

> PRL> =head2 $SIG{__DIE__}
> 
> PRL> <$SIG{__DIE__}> needs to be triggered only as a I resort
> PRL> instead of firing immediately, since it messes with the mind of
> PRL> this and every other decent exception handling mechanism.
> PRL> Perhaps it should be axed altogether. Please.
> 
> $SIG{DIE} should die. Action at a distance.  Global. Can't know what
> other threads or modules want done here.

Bloody hell! I agree with you 100% on something. Death to
$SIG{__DIE__}, and $SIG{__WARN__} while we're about it.

-- 
Piers