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
At 10:26 AM 8/27/00 -0400, Bennett Todd wrote:
So I'd expect instead
use Fatal qw(:arithmetic :io ...);
Therefore the default (to get the current behavior) would be that
some of the classes had Fatality enabled and others didn't?
And if Fatal supported unimport, then the default
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
Matt Youell writes:
As I think about this, however, I can imagine that some might want to force
it's use. Perhaps that requirement could be built into a strict pragma, like
'use StrictTypes' ?? I seem to recall an RFC along those lines.
My idea for
use strict 'types';
is that Perl
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
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
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
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
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
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
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
On 5 Aug 2000 21:40:43 -, Perl6 RFC Librarian wrote:
It would be nice to be able to say
@a = @b || @c
instead of having to resort to
@a = @b ? @b : @c
Would it? It looks like a small win, unless @b is actually a list
instead of just an array.
Currently, || is a scalar
On Sat, 26 Aug 2000 19:04:48 +1000, [EMAIL PROTECTED] wrote:
Righto. I'll coach Sumesh through how to post an RFC properly, and how
to check whether something's in Perl yet or not.
DO NOT fill -language with discussions of these pseudo-RFCs. Please.
I'm begging you.
I don't get it. There are
: That numerical part could then form the basis of the extended exception
: mechanism. No, the programmer shouldn't memorize the error numbers:
: there should be predefined constants, like
:
: ERROR::filenotfound
:
: which are numeric, and which could then be used for the catch
At 10:20 AM 8/27/00 -0400, Bennett Todd wrote:
I'd usually rather just say
my $fh = open $filename;
and be done with it, but then I'd always "use Fatal qw(:all);". But
if I'd done such a "use Fatal", and then wanted to catch one, I sure
hope I wouldn't have such a rabid try/catch
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Here Docs Terminators (Was Whitespace and Here Docs)
=head1 VERSION
Maintainer: Richard Proctor [EMAIL PROTECTED]
Date: 16 Aug 2000
Last Modified: 27 Aug 2000
Mailing List:
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
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
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
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.
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
Do we have an RFC yet that proposes Perl to be easier parsable?
Damian?
Working on it.
Damian
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
25 matches
Mail list logo
