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
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:
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
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
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 would
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
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 want
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 dumbfuck
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
How would you handle differentiating between safe-coding practices and
debugging type (internal) pre/post conditions?
chaim
"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
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
PRL Exceptions are objects belonging to some CException class. Cthrowing
PRL an exception creates the object; therefore, CEXCEPTION above is just a
PRL class name (possibly including some C::).
PRL
PRL The Cexception function is just syntactic sugar for creating a new
PRL exception class;it
At 07:54 PM 8/24/00 +0400, Ilya Martynov wrote:
PRL Exceptions are objects belonging to some CException class. Cthrowing
PRL an exception creates the object; therefore, CEXCEPTION above is just a
PRL class name (possibly including some C::).
PRL
PRL The Cexception function is just syntactic
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
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 syntax to me.
-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
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
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 allowed to
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 =
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 grammar,
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, 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';
for
On Wed, 23 Aug 2000 18:02:21 -0700, Nathan Wiger 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? These serve to
check if a sub is called as a
"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 Iidentically, and both would be enabled by default.
PRL IHowever, assignment is the only valid operator for these default
PRL lvalue subs. Attempts to
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 is the
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 occur,
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 the try
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 the
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 demonstrated
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 special
"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 my own
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 Lawrence
Lightning flashed, thunder crashed and "Michael Maraist" maraism@ironhilltechn
ology.com 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
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 24 2000
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,
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
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
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 to
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 entries
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
to a
- 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, that
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 gimmulet}"] =
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 ~ goes on top
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 this
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 clear in RFC
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 implementation.
Peter, I
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
die),
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
"try"
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 contraire... it
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 {
if
Tony Olekshy wrote:
Chaim Frenkel wrote:
Tony Olekshy wrote:
If no exception is in scope Perl should continue to generate and
propagate exceptions (die and $@) as it does now, so we don't
break tradition.
No, that should be the difference between die and throw. Die is
Glenn Linderman wrote:
These three recent postings expressing ways to implement the
differences between RFC 119 and RFC 88 are encouraging. With a
bit of syntactic sugar, it looks like RFC 88 can be made to handle
all the cases I care about. Now if you'd just get rid of that
"try"... or
Glenn Linderman wrote:
Tony Olekshy wrote:
Hi, it's me again. Not to be a pain, but RFC 88 does say:
Hey, no pain.
retry
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
"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() clears
JH the
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 } { ... } # probably not
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, it was
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 that
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 EXPR { ...
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
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
"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 pronounced,
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 Ceq and Ccmp operators which work case-sensitively.
It would be a useful addition to add case-insensitive equivalents.
Next you'll want
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. time
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
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-ROM drive
Bart Lateur wrote:
And, what's so special about the first match? What if I want the second
match, or the third?
(/foo/g)[2] ???
--
John Porter
We're building the house of the future together.
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Require explicit m on matches, even with ?? and // as delimiters.
=head1 VERSION
Maintainer: Nathan Torkington [EMAIL PROTECTED]
Date: August 20, 2000
Last Modified: August 24, 2000
Version: 2
On Thu, Aug 24, 2000 at 05:24:14PM -0700, Peter Scott wrote:
At 05:41 PM 8/24/00 -0600, Tom Christiansen wrote:
But you don't need that when you can and possibly should just write this:
print "EOF" =~ /^\s*\| ?(.*\n)/g;
Others may be focussing on the problem
Michael Maraist wrote:
my var; # declaring a scalar
my array[]; # declaring an array
my hash{}; # declaring a hash
Though the declarations seem fine, I assume that you propose this to be
optional at usage time, since variable interpolations such as
"xxx${var1}xxx${var2}xxx"
Tom Christiansen wrote:
Perl already does the sanity check for you: "can't call method
without package or reference". What you're saying requires the
programmer to diddle about, which is never a win.
I'll concede that point, with the counter that it lets you get exactly
what you want.
ad1 TITLE
types and structures
=head1 VERSION
Maintainer: David Nicol [EMAIL PROTECTED]
Date: 17 Aug 2000
Version: 1
Mailing List: [EMAIL PROTECTED]
Number: 122
=head1 ABSTRACT
We adopt C base types, and C structure syntax.
=head1 DESCRIPTION
the C programming language has a
Someone said:
Um, to clarify... While I'm here, I'm mostly a lurker and learner.
If you don't here from me, that's because I'm watching, not talking.
I'm here because:
* I think the PDL folks have valid needs
* I think a lot of people are having trouble making suggestions for
language
At 09:53 AM 8/24/00 -0400, Karl Glazebrook wrote:
Well the PDL RFCs seem to have been totally ignored on perl6-language.
Maybe we should discuss them here, come to some conclusions and
present them with a fait accompli. "These are the recommendations
of perl6-data".
Who is here anyway?
I'm
At 10:00 AM 8/24/00 -0400, Buddha Buck wrote:
At 09:53 AM 8/24/00 -0400, Karl Glazebrook wrote:
Well the PDL RFCs seem to have been totally ignored on perl6-language.
Maybe we should discuss them here, come to some conclusions and
present them with a fait accompli. "These are the
I am little bit confused and probably very ignorant but one thing seems to
me very useful. Why doesn't perl support a new data type matrix. If perl
wants to become a real "programming language" not just a scripting language
it should support number crunching internally in a more intuitive way. I
According to the ( very quickly hacked together ) RFC searcher I wrote, the
following RFC's have mention to PDL:
RFC number 38 matches 1 time(s):http://dev.perl.org/rfc/38.pod
RFC number 82 matches 1 time(s):http://dev.perl.org/rfc/82.pod
RFC number 109 matches 4 time(s):
=head1 TITLE
Standardise Handling Of Abnormal Numbers Like Infinities And NaNs
=head1 VERSION
Maintainer: Jarkko Hietaniemi [EMAIL PROTECTED]
Date: 05 Aug 2000
Version: 2
Mailing List: [EMAIL PROTECTED]
Number: 38
=head1 ABSTRACT
The handling of various abnormal numeric entities
=head1 TITLE
Efficient numerics with perl
=head1 VERSION
Maintainer: pdl-porters team [EMAIL PROTECTED]
Date: 16 August 2000
Version: 1
Mailing List: [EMAIL PROTECTED]
Number: 116
=head1 ABSTRACT
This RFC describes basic requirements of a numerical object/variable
type for perl. A
=head1 TITLE
Perl syntax support for ranges
=head1 VERSION
Maintainer: pdl-porters team [EMAIL PROTECTED]
Date: 16 August 2000
Version: 1
Mailing List: [EMAIL PROTECTED]
Number: 117
=head1 ABSTRACT
This RFC proposes syntactic support for ranges. Range objects
would be especially
=head1 TITLE
Enhanced Pack/Unpack
=head1 VERSION
Maintainer: Edwin Wiles [EMAIL PROTECTED]
Date: 22 Aug 2000
Version: 1
Mailing List: [EMAIL PROTECTED]
Number: 142
=head1 ABSTRACT
Pack and Unpack are percieved as being difficult to use, and
possibly missing desirable
=head1 TITLE
Default methods for objects
=head1 VERSION
Maintainer: pdl-porters team [EMAIL PROTECTED]
Date: 16 August 2000
Version: 1
Mailing List: [EMAIL PROTECTED]
Number: 115
=head1 ABSTRACT
This RFC proposes syntactic support for default methods
that can be defined for blessed
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Add reshape() for multi-dimensional array reshaping
=head1 VERSION
Maintainer: Nathan Wiger [EMAIL PROTECTED]
Date: 24 Aug 2000
Version: 1
Mailing List: [EMAIL PROTECTED]
Number: 148
Today around 8:13am, Larry Wall hammered out this masterpiece:
: Karl Glazebrook writes:
: : Who is here anyway?
:
: Don't ask me. I only work here.
Who is the chair of this group? We need an RFC or two to work on.
--
print(join(' ', qw(Casey R. Tweten)));my $sig={mail='[EMAIL
Casey R. Tweten writes:
Who is the chair of this group? We need an RFC or two to work on.
The chair is Jeremy Howard [EMAIL PROTECTED]. See dev.perl.org/lists
for a master list of all mailing lists.
All RFCs are available on dev.perl.org/rfc/, including several that
are appropriate for
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Transaction-enabled variables for Perl6
=head1 VERSION
Maintainer: Szabó, Balázs [EMAIL PROTECTED]
Date: 17 Aug 2000
Last Modified: 24 Aug 2000
Version: 4
Mailing List: [EMAIL PROTECTED]
Bart Lateur writes:
: 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
On Thu, Aug 24, 2000 at 03:43:41PM -, Perl6 RFC Librarian wrote:
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Remove socket functions from core
=head1 VERSION
Maintainer: Stephen P. Potter [EMAIL PROTECTED]
Date: Aug 24 2000
At 08:02 AM 8/24/00 -0700, Larry Wall wrote:
Bart Lateur writes:
: 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
Dan Sugalski writes:
: Chicanery's on the big To Do list. I'm really wanting to defer list
: flattening as long as possible, and skipping it all together.
And I'm wondering whether it's better in general to explicitly force a
context in which we treat @foo and %bar as objects, rather than
Ok, time to head back to planet Earth and the story of perl6.
Back to the grindstone!
Nat
(party pooper)
At 03:34 PM 8/24/00 -0600, Tom Christiansen wrote:
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
Dan Sugalski writes:
One of the current plans is for the parser to have access to a list of
functions that trigger autoloading modules.
Isn't dynamic loading really slow? If they're going to incur the
penalty of dynamic loading, you might as make them request that
slowdown by 'use'ing the
Mark Dominus [EMAIL PROTECTED]:
This behavior should be changed. If the PATTERN is empty, Perl should
look for the empty string. (That is, if the PATTERN is empty, it
should always match.)
Except perhaps for undef loperands? (matchees? bindees?)
--
John Porter
Nathan Wiger writes:
$x =~ /a/; # $x is roughly equivalent to a
I've been going at high speed through this thread, but has
anyone mentioned:
m{$foo}{^baz.*bar$}i
s{$foo}{(\w+) \1}{$1}g
With the first part of m{} and s{} containing an expression.
We lose !~ there, though.
Thoughts
=head1 ABSTRACT
It is quite difficult to match paired characters in Perl 5 regular
expressions. A solution is proposed, using new \g (match opening grouping
character) and \G (match closing grouping character) metacharacters.
Two new special variables, @^g and @^G control which strings are
1 - 100 of 145 matches
Mail list logo
