This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Exception handling syntax
=head1 VERSION
Maintainer: Peter Scott <[EMAIL PROTECTED]>
Date: 8 Aug 2000
Last-Modified: 23 Aug 2000
Version: 4
Mailing List: [EMAIL PROTE
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Omnibus Structured Exception/Error Handling Mechanism
=head1 VERSION
Maintainer: Tony Olekshy <[EMAIL PROTECTED]>
Date: 08 Aug 2000
Last Modified: 23 Aug 2000
Version: 2
Mailing List: [E
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Case ignoring eq and cmp operators
=head1 VERSION
Maintainer: Markus Peter <[EMAIL PROTECTED]>
Date: 24 Aug 2000
Version: 1
Mailing List: [EMAIL PROTECTED]
Number: 143
=head1 ABSTRACT
Perl curre
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Behavior of empty regex should be simple
=head1 VERSION
Maintainer: Mark Dominus <[EMAIL PROTECTED]>
Date: 24 August 2000
Version: 1
Mailing List: [EMAIL PROTECTED]
Number: 144
=head1 ABSTRACT
=
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Brace-matching for Perl Regular Expressions
=head1 VERSION
Maintainer: Eric J. Roode <[EMAIL PROTECTED]>
Date: 24 Aug 2000
Version: 1
Mailing List: [EMAIL PROTECTED]
Number: 145
=head1 ABSTRACT
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Split Scalars and Objects/References into Two Types
=head1 VERSION
Maintainer: Nathan Wiger <[EMAIL PROTECTED]>
Date: 23 Aug 2000
Version: 1
Mailing List: [EMAIL PROTECTED]
Number: 147
Sta
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Extend regex syntax to provide for return of a hash of matched subpatterns
=head1 VERSION
Maintainer: Kevin Walker <[EMAIL PROTECTED]>
Date: 23 Aug 2000
Mailing List: [EMAIL PROTECTED]
Version:
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Replace $self in @_ with self() builtin (not $ME)
=head1 VERSION
Maintainer: Nathan Wiger <[EMAIL PROTECTED]>
Date: 24 Aug 2000
Version: 1
Mailing List: [EMAIL PROTECTED]
Number: 152
Statu
>Remove socket functions from core
Why? What is the justification? I can think of some, but you
haven't given them.
In general, the misplaced zealotry to strip Perl down into someting
where nothing is predefined is hardly a good investment. It's not
like it will make anything appreciably sma
>A main goal for Perl 6 is to make it faster, more compact, and lighter
>weight. This means moving lots of former core functions into modules.
Andy D once posted something showing empirical evidence
that this hypothesis is in fact *FALSE*. And I was taught
that given a false hypothesis, nothing
Larry Wall <[EMAIL PROTECTED]> writes:
> Mark-Jason Dominus writes:
> : It may turn out that the new notation really does have exactly the
> : same ambiguities, but that's not clear to me now. All I said was that
> : I would like to see some discussion of it.
>
> Operator vs term processing wou
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Regex: Support for incremental pattern matching
=head1 VERSION
Maintainer: Damian Conway <[EMAIL PROTECTED]>
Date: 11 August 2000
Last Modified: 24 August 2000
Version: 2
Mailing List: [EMAIL PROT
Tom Christiansen wrote:
>
> It is? I don't see that this is a pain at all. It seems like
> a beautiful point of homogenization. You don't force the user
> to say $self; they could use $this if they wanted. Heck, they
> don't need it at all.
>
> my(undef, @args) = @_;
It's a pain if you
Bart Lateur writes:
> Oh. I would have put my hopes on a better (= more generic) O::Deparse
> mechanism to make Perl analyse the source code for you. Rewriting a Perl
> in a module seems a bit silly to me.
I don't know enough swear words to say how much I fucking hate the
stupid braindead dumbfuc
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Simple assignment lvalue subs should be on by default
=head1 VERSION
Maintainer: Nathan Wiger <[EMAIL PROTECTED]>
Date: 24 Aug 2000
Version: 1
Mailing List: [EMAIL PROTECTED]
Number: 154
S
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
New pragma 'autoloader' to load modules on-demand
=head1 VERSION
Maintainer: Nathan Wiger <[EMAIL PROTECTED]>
Date: 24 Aug 2000
Version: 1
Mailing List: [EMAIL PROTECTED]
Number: 153
Statu
How would you handle differentiating between safe-coding practices and
debugging type (internal) pre/post conditions?
> "DC" == Damian Conway <[EMAIL PROTECTED]> writes:
>> I would have assumed that a pre/post/invariant would not be used regularly,
>> but rather under optional control. So
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Lvalue subroutines: implicit and explicit assignment
=head1 VERSION
Maintainer: James Mastros <[EMAIL PROTECTED]>
Date: 24 Aug 2000
Version: 1
Mailing List: [EMAIL PROTECTED]
Number: 149
S
PRL> Exceptions are objects belonging to some C class. Cing
PRL> an exception creates the object; therefore, C above is just a
PRL> class name (possibly including some C<::>).
PRL>
PRL> The C function is just syntactic sugar for creating a new
PRL> exception class;it merely amounts to C<@EXCEPTI
At 07:54 PM 8/24/00 +0400, Ilya Martynov wrote:
>PRL> Exceptions are objects belonging to some C class. Cing
>PRL> an exception creates the object; therefore, C above is just a
>PRL> class name (possibly including some C<::>).
>PRL>
>PRL> The C function is just syntactic sugar for creating a new
On Thu, 24 Aug 2000, Peter Scott wrote:
PS> From the beginning of the posting you're quoting:
PS>
PS> This RFC has been merged into RFC 88. The text of the last version
PS> prior to the merge is left below for archival purposes only. Anyone
PS> interested in browsing this for historical reasons
At 02:06 AM 8/24/00 -0600, Tony Olekshy wrote:
>I just don't think that with with respect to the infrastructure
>mechanism per se, "fatality" should have anything to do with it.
>In the end, that's a judgement call; that's what we get paid the
>big bux for ;-)
I have reservations about the 'sever
On Thu, Aug 24, 2000 at 03:37:59PM -, Perl6 RFC Librarian wrote:
> =head1 TITLE
>
> Omnibus Structured Exception/Error Handling Mechanism
Woohoo!
> catch Alarm => { ... }
> catch Alarm, Error => { ... }
> catch $@ =~ /divide by 0/ => { ... }
The => here seems like useless synta
-Original Message-
From: Bart Lateur [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, August 23, 2000 7:00 PM
To: [EMAIL PROTECTED]
Subject: Re: PROTOPROPOSAL FOR NEW BACKSLASH was Re: implied pascal-like
"with" or "express"
On Tue, 22 Aug 2000 00:03:48 -0600 (MDT), Nathan Torkington wrote:
> =head1 TITLE
>
> Replace $self in @_ with self() builtin (not $ME)
>
Don't impose your religion on others. If people want 'this' instead of
'self', that should be just fine.
It should be pretty easy to define the appropriate $ME-reader like this:
use ObjectStyle 'self';
or
use Object
>No idea what the internals reasons are. Here are my reasons:
It would be a good idea to work over the way sockets are used and maybe come
up with a better model than the C/Unix like way things are now. Having
sockets in the core makes as much sense as having the ability to open and
read disk
>up with a better model than the C/Unix like way things are now. Having
>sockets in the core makes as much sense as having the ability to open and
>read disk files (early Pascal anyone?) in todays world of networked
>computers.
>From what Larry's said about making open work on URLs, he's
in you
I would actually further this sort of activity.
I admire micro-kernel-type systems. C and Java give you no functions out of
the box. Keywords are just that, keywords. I believe python is like this
as well. The idea being that everything has to come from a module.. This
limits how much a new de
>I admire micro-kernel-type systems. C and Java give you no functions out of
>the box. Keywords are just that, keywords. I believe python is like this
>as well. The idea being that everything has to come from a module.. This
>limits how much a new developer has to learn, and it doesn't pollute
I'm missing what you are trying to say. Are you suggesting that
$foo = @bar no longer mean ($foo = scalar(@bar)) == 3 ?
I wasn't suggesting going that far. Just a little more DWIM.
So that
($foo, @bar, $baz) = (1,2,3) # $foo = 1 @bar=(2,3), $baz = undef
# o
Jarkko Hietaniemi wrote:
>
> Still not good. "trans" is too overloaded word. "transaction"?
> "transactional"? (a bit too long...) "atomic"?
"acid"?
http://www.cs.duke.edu/education/courses/cps212/fall98/slides-html/recover/tsld002.htm
http://www.byte.com/art/9504/sec11/art3.htm#fouracid
T
At 10:26 AM 8/24/00 -0600, Tom Christiansen wrote:
> >Remove socket functions from core
>
>Why? What is the justification? I can think of some, but you
>haven't given them.
There are a number of good reasons to do this from an internals standpoint,
enough that I'd like to do it.
From an exte
>At 10:26 AM 8/24/00 -0600, Tom Christiansen wrote:
>> >Remove socket functions from core
>>
>>Why? What is the justification? I can think of some, but you
>>haven't given them.
>There are a number of good reasons to do this from an internals standpoint,
>enough that I'd like to do it.
Is one
Tom Christiansen writes:
> >There are a number of good reasons to do this from an internals standpoint,
> >enough that I'd like to do it.
>
> Is one allowed to know that number, and those reasons? :-)
No idea what the internals reasons are. Here are my reasons:
* the current socket(), bind(),
Here was my old demo/proposal, such as it was.
--tom
$buff = "\0" x rusage->sizeof();
syscall(&SYS_getrusage, &RUSAGE_SELF, $buff) && die "getrusage: $!";
$ru = rusage->new_from_buffer($buff);
# or
$ru = rusage->new();
$ru->unpack($buff);
# or
@fields = rusage->unp
Tom Christiansen wrote:
> printf "uid %d logged on from %s on %s.\n",
> $him->ut_uid, $him->ut_host, scalar local $him->ut_date;
>
>
Is ut_uid a scaler value here? It occured to me when I read this that it would
be nice to get rid of the distinction between
$him->{ut_uid}
$him->[ut
Ssshh don't mention RFC 109!
To give some background:
RFC 109 comes from me, and caused some "interesting" debate on
perl6-language. It's not that relevant to PDL.
RFC 115-117 are key RFCs from the PDL-Porters - things we really
want to see to make Perl better for numerics. These are the
main
Tom Christiansen wrote:
> C type declarations are pretty universally despised.
By whom?
This is news to me. I have always thought that the C type declaration
is a concise and platform-independent way of declaring a packed
structure, and effectively hiding implementation details (offsets into i
>The existing pack and unpack methods depend upon a simple
>grammar which leads to opaque format specifications,
Well, can lead. "f c4" is easy, but the big ones aren't.
>which are
>often difficult to get right, and which carry no information
>regarding variable names.
>A more descriptive gra
>Tom Christiansen wrote:
>> C type declarations are pretty universally despised.
>By whom?
>This is news to me. I have always thought that the C type declaration
>is a concise and platform-independent way of declaring a packed
>structure, and effectively hiding implementation details (offsets
Bart Lateur wrote:
>
> >I hate it, it's miserable. Too much hidden trickery and special cases.
>
> Quite the countrary, I should think. Have you seen the subs
> self_or_default and self_or_CGI in the source of CGI.pm?
Yep, if you check out my File::Remote module I hijacked them. Thanks
again,
On Thu, 24 Aug 2000 02:02:06 +0200, Markus Peter wrote:
>$one{two\three\four} instead of $$$one{two}{three}{four}
Isn't that
$one{two}{three}{four}
--
Bart.
On Thu, 24 Aug 2000, Hildo Biersma wrote:
> Don't impose your religion on others. If people want 'this' instead of
> 'self', that should be just fine.
>
> It should be pretty easy to define the appropriate $ME-reader like this:
>
> use ObjectStyle 'self';
>
> or
>
> use ObjectStyle 'Java
>Currently, the current object context is passed into a sub as the first
>element of @_, leading to the familiar construct:
> my $self = shift;
>However, this is a big PITA. In particular, if you support lots of
>different calling forms (like CGI.pm), you have to check whether $_[0]
>is a ref,
>sub do_stuff {
>my $self = self;
>$self->{STATE}->{something} = @_;
>}
>
>sub error {
>carp @_ if self->config('VerboseErrors');
>}
I've never really seen anything like this before in other languages (Is that
good or bad?). The closest is Java's odd use o
> "Bart" == Bart Lateur <[EMAIL PROTECTED]> writes:
Bart> On Tue, 22 Aug 2000 00:03:48 -0600 (MDT), Nathan Torkington wrote:
>> Normally what you'd say is:
>>
>> with (%record) {
>>
>> }
>>
>> (look at me, using Larry's new ... operator :-)
Bart> No you didn't. You typed four dots.
T
> "PRL" == Perl6 RFC Librarian <[EMAIL PROTECTED]> writes:
PRL> Therefore, the definition of the return function must be changed
PRL> such that it is lazy.
PRL> Additionally, the definition of assignment must not normally
PRL> evaluate a lazy expression, but rather evaluate it to the point
P
> "PRL" == Perl6 RFC Librarian <[EMAIL PROTECTED]> writes:
PRL> The key to the proposal is this: lvalue and rvalue versions of a sub
PRL> would work I, and both would be enabled by default.
PRL> I, assignment is the only valid operator for these default
PRL> lvalue subs. Attempts to use other
Chaim Frenkel wrote:
>
> Why this limitation?
>
> If the lvalue is a fundemental type (whatever that is) everything works
> as if the lvalue were actually in place
>
> sub foo { return $a }
> foo =~ s///;# same as $a =~ s///;
This is not the type of lvalue sub that th
Tom Christiansen wrote:
>
> >A main goal for Perl 6 is to make it faster, more compact, and lighter
> >weight. This means moving lots of former core functions into modules.
>
> Andy D once posted something showing empirical evidence
> that this hypothesis is in fact *FALSE*.
Ok. Perhaps I shoul
Glenn Linderman wrote:
>
> Tony Olekshy wrote:
> >
> > You are oversimplifying by mixing the notions of exceptions
> > and errors, whether you are aware of their difference or not.
>
> I am aware of the difference between errors and exceptions;
> however, I firmly believe that exception handling
Glenn Linderman wrote:
>
> Here's some code that returns one non-fatal error. I'd like to
> change it to use the new RFC 88 mechanism. Please show me how.
> I've included how to do it via RFC 119. Note that sub
> really_delicate_code is documented that only one possible
> non-fatal error can o
Glenn Linderman wrote:
>
> Tony Olekshy wrote:
>
> > RFC 88 does say:
> >
> > finally { ... }
> >
> > Once the try block is entered, every finally block is
> > guaranteed to be entered before the try statement completes,
> > whether or not any exceptions have been raised since th
Tony,
Having done the exercise of redoing all your RFC 88 examples into RFC 119
syntax, I conclude that the two biggest differences between the syntaxes is
the explicit or implicit try, which is mostly an irrelevant placeholder;
some like it, some don't.
The biggest syntax simplifications came i
Peter Scott wrote:
> At 11:21 AM 8/24/00 -0700, Glenn Linderman wrote:
> >By building up a
> >non-fatal error handling technique on top the existing fatal error
> >handling technique, you are forcing code that assumes it will die to
> >behave differently, when you wrap a try block around it. Now
Tom Christiansen wrote:
>
> So it seems that what you're saying is that you'd like a way to
> *know* for certain whether you were invoked as a method -- or not,
> as the case might be.
Sort of. Actually, I want to not care. Adding a :method constraint
doesn't help (actually hurts) because then t
Hildo Biersma wrote:
>
> > =head1 TITLE
> >
> > Replace $self in @_ with self() builtin (not $ME)
> >
>
> Don't impose your religion on others. If people want 'this' instead of
> 'self', that should be just fine.
Whoa! I'm not imposing religion on others. FAR FROM IT! Maybe the
examples I demo
On Thu, 24 Aug 2000 13:27:01 -0700, Nathan Wiger wrote:
>It's a pain if you want to support both function-oriented and
>object-oriented calling forms, as CGI.pm does. For example, you can use
>both of these:
>
> print header;
> print $r->header;
>
>with CGI.pm. Now you need a self_of_default
> "Nathan" == Nathan Wiger <[EMAIL PROTECTED]> writes:
Nathan> The key difference is this: $_[0] always contains the first method
Nathan> argument, regardless of whether you're in an object-oriented or
Nathan> function-oriented context. So, if you need to support both (like CGI.pm
Nathan> and
>It's a pain if you want to support both function-oriented and
>object-oriented calling forms, as CGI.pm does. For example, you can use
>both of these:
> print header;
> print $r->header;
>with CGI.pm. Now you need a self_of_default special method, since
>sometimes $_[0] has a class ref and
Dan Sugalski <[EMAIL PROTECTED]> writes:
> I'm picturing a WAP-enabled cellular furbie with
> an R2D2-style projector thingie for the video.
> It's not a pretty sight...
"Help us Lawrence Wall, you're our only hope..." bzzp!
"Help us Lawrence Wall, you're our only hope..." bzzp!
"Help us Lawr
Lightning flashed, thunder crashed and "Michael Maraist" whispered:
| >From this, socket, and virtually all IPC methods should go the wayside.
| This includes pipes, shell environment ops ( the get and set functions ),
| and even the file-io (open, close, and possibly even printf, sprintf). At
|
>I have several RFCs I need to write about removing certain functionality
>out of the core (math functions, IPC, networking, "user"). I don't want to
>go too overboard. I don't know that we want to go so far as to remove
>printing and such. It might be nice to generalize some functions (like th
On Thu, Aug 24, 2000 at 08:29:21PM -, Perl6 RFC Librarian wrote:
> This and other RFCs are available on the web at
> http://dev.perl.org/rfc/
>
> =head1 TITLE
>
> Remove geometric functions from core
>
> =head1 VERSION
>
> Maintainer: Stephen P. Potter <[EMAIL PROTECTED]>
> Date: Aug
A friend pointed out, technically most are trigonometric functions,
not geometric. atan2, cos, sin, acos, asin and tan are all trig.
exp, log, sqrt are... just math I guess.
So I suppose the proposed module would be Math::Trig or some such. Or
maybe, as the source code suggests, Math::High:Falu
>A friend pointed out, technically most are trigonometric functions,
>not geometric. atan2, cos, sin, acos, asin and tan are all trig.
>exp, log, sqrt are... just math I guess.
>So I suppose the proposed module would be Math::Trig or some such. Or
>maybe, as the source code suggests, Math::High
bkuhn wrote:
> >I *think* that the consensus is that we should make it easy for people who
> >want to port to the JVM, or the so-called ".NET Implementation Language".
> >As the JVM porter, I'd like my life easy, but I don't expect perl6 to hand
> >me a JVM implementation---I just want to right co
> >I admire micro-kernel-type systems. C and Java give you no functions out of
> >the box. Keywords are just that, keywords. I believe python is like this
> >as well. The idea being that everything has to come from a module.. This
> >limits how much a new developer has to learn, and it doesn'
>Perhaps it would be better to have Perl support all of perlfunc(1) in the
>core still, but allow users to turn subsets off?
>Or, perhaps the core functions could be syntactic sugar for access to
>modules, and have a transformation happen automagically in the parser? (My
>gut says "here there be
Larry Wall wrote:
>
> I expect that we'll get more compile-time benefit from
>
> my HASH sub foo {
> ...
> }
>
> %bar = foo();
Ah, the Return Value Optimization so loved in C++...
For those who haven't seen it before, you can optimize this by passing
in a reference to %bar
On Thu, 24 Aug 2000 09:38:28 +0100, Hildo Biersma wrote:
>> I expect that we'll get more compile-time benefit from
>>
>> my HASH sub foo {
>> ...
>> }
>>
>> %bar = foo();
>
>Ah, the Return Value Optimization so loved in C++...
>
>For those who haven't seen it before, you can
Dan Sugalski wrote:
> Plus I can see each being used more often if we extend it to be valid for
> sparse arrays, or used more under the hood with iterators and lazy lists
> and suchlike things. Each, when used on a sparse array, would presumably
> return a list of offset/value pairs of valid entri
Damian Conway <[EMAIL PROTECTED]>:
>
> It is proposed that the Perl 6 regular expression engine be extended to
> allow a regex to match against an incremental character source, rather than
> only against a fixed string.
>
> Specifically, it is proposed that a subroutine reference could be bound
- Original Message -
From: "Eric Roode" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Thursday, August 24, 2000 1:56 PM
Subject: Re: RFC 145 (v1) Brace-matching for Perl Regular Expressions
> Well, if we stick to the model of a lowercase/uppercase pair
> for this proposed feature,
One thing I'd like to see is being able to specify qr//d regexes or list
(refs) within this, to be able to give multiple equivlent objects. For
example, the list
("<<" => ">>", "\N{left gimmulet}" => "\N{right gimmulet}") would allow <<
to match >> and « to match ». However, (["<<", "\N{left gim
Nathan Wiger wrote:
>
> > : =~ has no real world equivalent, and in fact I don't know how to
> > : pronounce it in English so that $x =~ /a/ makes sense.
> >
> > Yes, that's all pretty much on the mark.
>
> Not true, IMO. In math, =~ is used to indicate "rough equivalence".
> (Actually, the ~ go
From: "Chaim Frenkel" <[EMAIL PROTECTED]>
Sent: Thursday, August 24, 2000 2:42 PM
Subject: Re: RFC 149 (v1) Lvalue subroutines: implicit and explicit
assignment
PRL> Therefore, the definition of the return function must be changed
PRL> such that it is lazy.
PRL> Additionally, the definition of
At 06:06 PM 8/24/00 -0600, Tony Olekshy wrote:
>In fact, not only would I be pleased and honoured to author the
>Perl 6 core Try.pm module, I'm already working on a Perl 5 standard
>reference implementation.
That should certainly tell you whether it's doable :-)
>Peter, I think we should make th
Peter Scott wrote:
>
> At 06:06 PM 8/24/00 -0600, Tony Olekshy wrote:
> >
> >In fact, not only would I be pleased and honoured to author the
> >Perl 6 core Try.pm module, I'm already working on a Perl 5 standard
> >reference implementation.
>
> >Peter, I think we should make this approach more c
At 06:48 PM 8/24/00 -0600, Tony Olekshy wrote:
>Peter Scott wrote:
> >
> > At 06:06 PM 8/24/00 -0600, Tony Olekshy wrote:
> > >
> > >In fact, not only would I be pleased and honoured to author the
> > >Perl 6 core Try.pm module, I'm already working on a Perl 5 standard
> > >reference implementatio
Tony Olekshy wrote:
> Some discussion has suggested that it might be a good idea if it
> were possible to have a simple way to prevent catch from catching
> so-called "fatal" errors. Some fringe ideas have actually included
> two seperate mechanisms, one for so-called fatal errors (based on
> di
Tony Olekshy wrote:
> Other than for the except and always clauses, RFC 199 is very
> similar to RFC 88. I like the idea behind except and always,
> but I think the proposed implementation could be dramatically
> simplified.
>
> The first thing to realize is that just because 119 doesn't say
> "
At 11:21 AM 8/24/00 -0700, Glenn Linderman wrote:
>By building up a
>non-fatal error handling technique on top the existing fatal error
>handling technique, you are forcing code that assumes it will die to
>behave differently, when you wrap a try block around it. Now it will only
>"maybe" die.
On Thu, Aug 24, 2000 at 10:10:49AM -0700, Peter Scott wrote:
> At 12:07 PM 8/24/00 -0500, Jonathan Scott Duff wrote:
> > > catch Alarm => { ... }
> > > catch Alarm, Error => { ... }
> > > catch $@ =~ /divide by 0/ => { ... }
> >
> >The => here seems like useless syntax to me.
>
> Au c
On Sun, Aug 20, 2000 at 09:23:20AM -0700, Peter Scott wrote:
> At 10:14 AM 8/20/00 -0600, Tony Olekshy wrote:
> >Graham Barr wrote:
> > >
> > > I am of the opinion that only a class name should follow catch.
> > > If someone wants to catch based on an expression they should use
> > >
> > > catch
> "JH" == Jarkko Hietaniemi <[EMAIL PROTECTED]> writes:
JH> "The first operation done on the return value of open() shall be defined()
JH> or you shall regret your pitiful existence."? (a flag on the scalar coming
JH> from open that makes any other op than defined() to die and defined() clear
At 12:50 PM 8/24/00 -0500, Jonathan Scott Duff wrote:
> > How should the parser disambiguate
> >
> > my ($hash,%hash);
> > try { ... } catch $hash { ... }
> >
> > ? But if we require the comma, we know it's parseable, because map can
> do it.
>
>map is a slightly different animal because
On Thu, Aug 24, 2000 at 10:47:45AM -0700, Peter Scott wrote:
> > > But I initially wanted to do without the => ... unfortunately that would
> > > require another keyword to handle the EXPR case and it didn't seem
> > worth it.
> >
> >Not necessarily.
> >
> > catch { EXPR } { ... }
On Thu, Aug 24, 2000 at 02:09:15PM -0400, Chaim Frenkel wrote:
> > "JH" == Jarkko Hietaniemi <[EMAIL PROTECTED]> writes:
>
> JH> "The first operation done on the return value of open() shall be defined()
> JH> or you shall regret your pitiful existence."? (a flag on the scalar coming
> JH> fr
Tony Olekshy wrote:
> Glenn Linderman wrote:
>
> > I do recall seeing this quote; however, replacing AUTOLOAD is a very
> > specific instance of resuming from or retrying a fault condition. And
> > even though a retry mechanism could be generalized from AUTOLOAD to
> > handling other conditions,
Tony Olekshy wrote:
> Yes, well, at this point I must re-iterate that (in light of reasons
> for the existence of a try keyword that I have explained in other
> messages), what you've written is the same as:
>
> try { ... } finally { &do_something(); }
Yes, they are equivalent.
And note
At 12:07 PM 8/24/00 -0500, Jonathan Scott Duff wrote:
> > catch Alarm => { ... }
> > catch Alarm, Error => { ... }
> > catch $@ =~ /divide by 0/ => { ... }
>
>The => here seems like useless syntax to me.
Au contraire... it emerged from our discussion of this case:
> catch EXP
Tony Olekshy wrote:
> There you have it. That's why RFC 88 uses structured data for $@.
That's a good argument, one that I have no quarrel with. As an
enhancement to eval/die, this would make it more flexible for checking
conditions. And with appropriate stringification, it is upward
compatib
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Replace first match function (C) with a flag to the match command.
=head1 VERSION
Maintainer: Stephen P. Potter <[EMAIL PROTECTED]>
Date: Aug 24 2000
Mailing List: [EMAIL PROTECTED]
Version: 1
Num
"foo.bar" ne "www.foo.bar"
pronounce("foo.bar") eq pronounce("www.foo.bar")
As in, "Surf to www.perl.org and read the new ..."
sounds like
"Surf to perl dot org and read the new ..."
=Austin
--- Tom Christiansen <[EMAIL PROTECTED]> wrote:
> >The "www" in e.g., "www.netscape.com" is pronounce
On Thu, Aug 24, 2000 at 10:28:51PM +0200, Bart Lateur wrote:
> On 24 Aug 2000 15:40:00 -, Perl6 RFC Librarian wrote:
>
> >Perl currently only has C and C operators which work case-sensitively.
> >It would be a useful addition to add case-insensitive equivalents.
>
> Next you'll want case)ins
On 24 Aug 2000 16:03:56 -, Perl6 RFC Librarian wrote:
>Merge C<$!>, C<$^E>, and C<$@>
Merging $! and $^E makes perfect sense to me. I don't know why there are
two different error variables. Er... wasn't that three? I'm not
absolutely certain, but I thought there was a third one, too. Oh yes
Bart Lateur wrote:
>
> Suppose you want to keep the case on the hash keys, because you
> enumerate them. But you still want to find hash entries in a case
> insensitive manner...
...then you simply reach for Tie::CPHash on CPAN!
--
John Porter
On 24 Aug 2000 20:24:52 -, Perl6 RFC Librarian wrote:
>Damian Conway's Text::Balanced module does a pretty good job of
>tokenizing Perl code. However, bare C and C require
>semantic analyis to distinguish them from division and the hook
>(C) operator.
>
>To remove this hassle, and thus permi
At 10:37 PM 8/24/00 +0200, Bart Lateur wrote:
>On 24 Aug 2000 16:03:56 -, Perl6 RFC Librarian wrote:
>
> >Merge C<$!>, C<$^E>, and C<$@>
>
>Merging $! and $^E makes perfect sense to me. I don't know why there are
>two different error variables.
$! eq "No such file or directory"; $^E eq "CD-R
1 - 100 of 230 matches
Mail list logo
