This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
counting matches
=head1 VERSION
Maintainer: Richard Proctor [EMAIL PROTECTED]
Date: 16 Aug 2000
Last Modified: 27 Aug 2000
Version: 2
Mailing List: [EMAIL
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Assignment within a regex
=head1 VERSION
Maintainer: Richard Proctor [EMAIL PROTECTED]
Date: 16 Aug 2000
Date: 27 Aug 2000
Version: 2
Mailing List: [EMAIL
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Simplify Cdo BLOCK Syntax
=head1 VERSION
Maintainer: Mark Senn [EMAIL PROTECTED]
Date: 27 Aug 2000
Mailing List: [EMAIL PROTECTED]
Version: 1
Number: 167
=head1 ABSTRACT
Simpify syntax of Cdo
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Automatic accessors for hash-based objects
=head1 VERSION
Maintainer: James Mastros [EMAIL PROTECTED]
Date: 25 Aug 2000
Version: 1
Mailing List: [EMAIL PROTECTED]
Number: 163
=head1 ABSTRACT
This
[this might have been missed for those following threads, so reposting]
Everything in Perl becomes an object, using existing object-syntax. Out of
plain sight, there would be essentially three base classes: Scalar, List,
and Hash.
Arg! You beat me to it. :-) This was the next RFC on my list.
First off, I like the idea a lot. However, I think there is some
extraneous bloat in it:
The defined permissions are:
'!', which forces the method call to fail, without further ado L[5], and
'+', which makes the autoaccessor handle the call
'~', which makes the autoaccessor
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
OO Integration/Migration Path
=head1 VERSION
Maintainer: Matt Youell [EMAIL PROTECTED]
Date: 25 Aug 2000
Last Updated: 27 Aug 2000
Mailing List: [EMAIL PROTECTED]
Version: 2
Number: 161
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
type inference
=head1 VERSION
Maintainer: Steve Fink [EMAIL PROTECTED]
Date: 1 Aug 2000
Last Modified: 27 Aug 2000
Version: 2
Mailing List: [EMAIL PROTECTED]
Number: 4
=head1 ABSTRACT
Types
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Filtering Here Docs
=head1 VERSION
Maintainer: Richard Proctor [EMAIL PROTECTED]
Date: 27 Aug 2000
Version: 1
Mailing List: [EMAIL PROTECTED]
Number: 162
=head1
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Built-in functions should be functions
=head1 VERSION
Maintainer: Johan Vromans [EMAIL PROTECTED]
Date: 27 Aug 2000
Mailing List: [EMAIL PROTECTED]
Version: 1
Number: 168
=head1 ABSTRACT
RFC 26
Damian Conway wrote:
Well, RFC 23 doesn't mention ^0, and has several examples starting
at ^1. And it draws the analogy between ^1, ^2, etc and $1, $2,
etc. I didn't make it up.
My apologies. The examples you refer to are incorrect. They were added by
a helper, but the
Bart Lateur wrote:
Next, you'll say that every idea must be actually submitted as an RFC
before being worthy of discussion.
Have to say, I agree with Bart on this. While being in the RFC format
was distracting, far better that he dumped them straight to the list
before submitting them as
2000-08-22-15:13:23 Peter Scott:
I too would rather say
my $fh = open $filename or die "Couldn't copy source: $!"
than
my $fh; try { $fh = open $filename } catch { die "Couldn't copy
source: ", $@-syserr }
I'd usually rather just say
my $fh = open
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
C|| and C should propagate result context to both sides
=head1 VERSION
Maintainer: Peter Scott [EMAIL PROTECTED]
Date: 5 Aug 2000
Last-Modified: 26 Aug 2000
Mailing List: [EMAIL
That a user my need to have two or more variables in sync for proper
operation. And cooperative threads don't address that issue.
Cooperative only helps _perhaps_ with perl not needing to protrect its
own structures.
We are in agreement.
I was specifically addressing the problem of
I wish I knew why you are discussing in -internals issue on this list.
You should be specifying behaviour not how it is implemented. A mention
of implementation is reasonable but _don't_ spend too much time. If Larry
wants it. -internals will give it to him.
Anyway, please recall that because of
On Sun, 27 Aug 2000, Steven W McDougall wrote:
Based on your examples, I have to assume that you are serious about
RFC1v3 item 6:
No offense, but I wouldn't have suggested it if I weren't serious.
Misguided, perhaps. Joking, no.
This is a non-starter for me. Right now, I am working on
We could either discuss alternate approaches for RFC1, or I could
submit a new RFC for a thread architecture that gives me the
performance I want.
Both are more than welcome. (If you want alternate approaches or
counter-arguments to be fully documented, then doing both in an RFC
would
as in the non-threaded case, or do we get
$global::{foo} - *global::foo - global::foo - { print 1 }
$thread::{foo} - *thread::foo - thread::foo - { print 2 }
Okay, I understand. Here's how I perceive it
There is no global::foo, just two thread-specific foos. In which
I don't understand the problem with these scenarios.
A couple of other scenerios
Thread 1Thread 2
push(@a, @b); $a[35]++
What does
User level cross variable consistancy.
mean?
push(@a, $b);
$acount++ if $b 35;
Even
"SWM" == Steven W McDougall [EMAIL PROTECTED] writes:
SWM I don't understand the problem with these scenarios.
A couple of other scenerios
Thread 1 Thread 2
push(@a, @b);$a[35]++
Cooperative threads do not solve consistance issues. The array, its
contents
"DC" == Damian Conway [EMAIL PROTECTED] writes:
How would you handle differentiating between safe-coding practices and
debugging type (internal) pre/post conditions?
DC Why would one bother?
There are two types, as I imagine them. Gatekeeper code. (Did the user
send me frobnitz?) and
DC However, I have given thought to allowing conditions to be grouped,
DC and de-activated by group. This would probably meet your need.
DCpre mymethod : group("safe-coding practice") { @_ 0 }
DCpre mymethod : group("debugging") { print @_, "\n"; }
Nathan Torkington wrote:
Are you proposing making even "normal" scalar, hash, and array access
go through these methods? Wouldn't that slow everything way down?
Glad you brought this up, Nat!
I would say "yes and no". The reason I'd say this is because Dan S. and
the internals guys are
Nathan Torkington wrote:
Do you mean that when we write:
my int $intVal = 0;
it gets turned into OO stuff?
Yeah, that's the thinking.
my int $intVal = 0;
any more?
No, egads! violent vomiting
I'd rather than any "variables are represented by objects" magic
be done
Arg! You beat me to it. :-) This was the next RFC on my list.
Nate, if I had known that, I would gladly have let you take the arrows. =^)
:-)
To clarify: Methods such as 'asInt()' could be ignored at will. If they were
never called, Perl would still Do The Right Thing. So, totally
Perl6 RFC Librarian writes:
For example, rather than:
my int $intVal = 0;
you would say:
my $intVal = 0;
$intVal-asInt;
Or possibly even:
my $invVal-asInt = 0;
for simplicity.
Do you mean that when we write:
my int $intVal = 0;
it gets turned into OO stuff? Or do you mean
Damian Conway wrote:
My forthcoming proposal will be that invocants still be passed as $_[0]
by default, but that there be a pragma allowing $_[0] to be automagically
shifted somewhere else during dispatch. For example:
use invocant '$ME';
sub method { print "I was called
Data Conversion and Access
-
STRING Called in a string context
NUMBER Called in a numeric context
BOOLEAN Called in a boolean context
Operator Overloading
Great. My point I was trying to drive at was that:
my int $x = 5;
Could turn around and do something different than asInt(). All stores
Got it. And sure, why not? Pay the overhead when you absolutely need to, and
no sooner. The core idea (for me) is to avoid wasting resources on a
Matt Youell wrote:
Great. My point I was trying to drive at was that:
my int $x = 5;
Could turn around and do something different than asInt(). All stores
Got it. And sure, why not? Pay the overhead when you absolutely need to, and
no sooner. The core idea (for me) is to avoid
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
On Sun, Aug 27, 2000 at 08:37:38PM +, Nick Ing-Simmons wrote:
Jarkko Hietaniemi [EMAIL PROTECTED] writes:
bytes
microperl, which has almost nothing os dependent (*) in it 1212416
shared libperl 1277952 bytes + perl 32768
Al Lipscomb [EMAIL PROTECTED] writes:
I wonder if you could arrange things so that you could have statically
linked and dynamic linked executable. Kind of like what they do with the
Linux kernel. When your installation is configured in such a way as to make
the dynamic linking a problem, just
Lightning flashed, thunder crashed and Dan Sugalski [EMAIL PROTECTED] whispered:
| or we can all darned well fake it at the very least.
Dan, Larry, and the rest of the members of perl6-internals:
I apologize for my behaviour the other evening. It was childish and served
no purpose on this
Lightning flashed, thunder crashed and Steve Fink [EMAIL PROTECTED]
whispered:
| Depends on your definition of "module". Many people seem to be assuming
| "module" eq "shared library".
Yes, exactly. I use module as a generic term for something other than the
main perl binary itself, a black
Dan Sugalski writes:
If the vtable stuff goes into the core perl engine (and it probably will,
barring performance issues), then what could happen in the
I have a lot of questions. Please point me to the appropriate place
if they are answered elsewhere.
vtables are tables of C functions?
On Sun, 27 Aug 2000, Nathan Torkington wrote:
Dan Sugalski writes:
If the vtable stuff goes into the core perl engine (and it probably will,
barring performance issues), then what could happen in the
I have a lot of questions. Please point me to the appropriate place
if they are
Jarkko Hietaniemi [EMAIL PROTECTED] writes:
bytes
microperl, which has almost nothing os dependent (*) in it 1212416
shared libperl 1277952 bytes + perl 32768 bytes1310720
dynamically linked perl
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Allow Varibles in tr///
=head1 VERSION
Maintainer: Richard Proctor [EMAIL PROTECTED]
Date: 27 Aug 2000
Mailing List: [EMAIL PROTECTED]
Version: 1
Number: 165
if (/Time: (..):(..):(..)/) {
$hours = $1;
$minutes = $2;
$seconds = $3;
}
This then becomes:
/Time: (?$hours=..):(?$minutes=..):(?$seconds=..)/
This is more maintainable than counting the brackets and easier to understand
for a complex regex. And
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Additions to regexs
=head1 VERSION
Maintainer: Richard Proctor [EMAIL PROTECTED]
Date: 27 Aug 2000
Mailing List: [EMAIL PROTECTED]
Version: 1
Number: 166
=head1
=head1 TITLE
Replace =~, !~, m//, and s/// with match() and subst()
In a marked oversight, I'd also like to note that tr// would be replaced
with trade:
Perl 5 Perl 6
--- --
$str =~ tr/a/b/;$new =
Perl6 RFC Librarian writes:
match; # all defaults (pattern is /\w+/?)
match /pat/;# match $_
match /pat/, $str; # match $str
match /pat/, @strs; # match any of @strs
When I was thinking about this very topic yesterday and today, I
came up
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
Last Modified: 27 August 2000
Version: 2
Mailing List: [EMAIL PROTECTED]
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Replace =~, !~, m//, and s/// with match() and subst()
=head1 VERSION
Maintainer: Nathan Wiger [EMAIL PROTECTED]
Date: 27 Aug 2000
Version: 1
Mailing List: [EMAIL PROTECTED]
Number: 164
Nathan Wiger writes:
Honestly, not sure. Although, there are two things I'd say about it:
1. I don't think it's a showstopper for this RFC, since the
feature you are addressing is actually a new piece of
functionality.
Hmm. This is exactly the same situation as with chomp()
Nathan Torkington wrote:
Hmm. This is exactly the same situation as with chomp() and somehow
chomp() can tell the difference between:
$_ = "hi\n";
chomp;
and
@strings = ();
chomp @strings;
Good point. I was looking at it from the general "What's wrong with how
@arrays are
On 27 Aug 2000 19:01:45 -, Perl6 RFC Librarian wrote:
m//g just returns 1 for matching.
Er... but in a scalar context, m//g DOES only match once! If you want
more, repeat the match. Or use it in a list context, then it will try to
match them all.
$_ = "abaabbbababbbabbaaa";
Damian Conway writes:
pre mymethod : group("safe-coding practice") { @_ 0 }
pre mymethod : group("debugging") { print @_, "\n"; }
Using these for lvalue subs doesn't give you the behaviour you want:
sub foo :lvalue { $foo }
post foo { die if $foo == 5 }
eval {
foo() =
* Nathan Wiger ([EMAIL PROTECTED]) [28 Aug 2000 13:07]:
Are we maintaining the RFC's in HTML anywhere? I don't see them.
If not, could we add an HTML link at the end of the RFC links:
RFC 0 (v4): Some title [ HTML ]
Sometimes reading HTML is easier on the eyes than plain text. Plus you
Making 0 the first element makes as much sense as 1- just a convention.
However there is precedence for letting the user decide. Does anyone else
remember
)ORIGIN 1
? So we establish a var $something=n where n is the array origin.
I don't think I'd ever use it personally, having been a c
THING =~ OTHER_THING
is translated to
bind(THING,OTHER_THING)
with bind() having user-defined semantics.
I think Damian has an RFC in-the-works on operator overloading that
will address this.
That one's been passed to brian d foy and (if memory
Damian's Text::Balanced does a pretty good job of tokenizing Perl
as it is. / by itself requires a lot of lookahead, and it's still
a guess.
I don't get it. What makes it so hard? If you see a "/" when you're
expecting an operator, or end of statement, then it's
"Array and placeholder indices both start at *zero*!"
Sorry for being late, but "why?!"
It makes more sense in a vacuum, but given $1, $2, etc, I'd *much* more
expect them to start with ^1, ^2, and so on. It's much more consistent.
But ^1, ^2, etc. have
Damian Conway wrote:
But ^1, ^2, etc. have *nothing* to do with $1, $2, except analogically.
And I'm removing that analogy from the next version of the RFC! ;-)
They have *everything* to do with $_[0], $_[1], $_[2], etc.
I realize this, but I don't think most people will see it that way.
X-posted to [EMAIL PROTECTED]
David L. Nicol wrote:
If arrays as we know them implement by using a key space restricted to
integers, I think a reasonable way to get matrices would be to open
up their key space to lists of integers.
I've been thinking along exactly the same lines. There's a
57 matches
Mail list logo
