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 op
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
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 PROTECTE
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 PROTECTE
I have added the remaining changes based on the traffic in -errors
and the batch of changes I received from Peter Scott. Production
formatting has been completed. RFC 88v3d1 is available at:
http://www.avrasoft.com/perl6/rfc88.htm
An updated version of the Perl 5 reference implementati
2000-08-22-16:40:13 Peter Scott:
> >I'm not sure, but I think Chaim's main point was just that, not
> >that divide-by-zero should be ignored too.
>
> Well, it could be made user-selectable, right Bennett? Do you envisage
> being able to say
>
> use Fatal qw(Arithmetic IO etc)
>
> usi
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Simplify C 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 C by deletin
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
get all the cross-links and stuff. Just a suggestion.
-Nate
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
2000-08-27-12:03:07 Peter Scott:
> > use Fatal qw(:io ...);
> > no Fatal qw(:arithmetic);
>
> Bingo, yes. I will make appropriate changes to RFC 80. You might
> think about whether RFC 70 needs to be changed.
I don't think so; while I mention styles of changes and growth for
F
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 R
[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 lis
On Sun, Aug 27, 2000 at 10:31:05AM -0700, Nathan Wiger wrote:
> > The defined permissions are:
> >
> > '!', which forces the method call to fail, without further ado L<[5]>, and
> Isn't '!' the same as not specifying ':accessible', since the autoaccessor
> method therefore won't exist and eit
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 autoaccess
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
=hea
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
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
Filtering Here Docs
=head1 VERSION
Maintainer: Richard Proctor <[EMAIL PROTECTED]>
Date: 27 Aug 2000
Version: 1
Mailing List: [EMAIL PROTECTED]
Number: 162
=head1 A
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 2
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 t
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/catc
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 re
> : 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
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: [EM
> 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 prot
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 a
> > 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
> > 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
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;
>
>
> E
On Sat, 26 Aug 2000, Steven W McDougall wrote:
> 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 }
>
> Does this program output
>
> 12
>
> or
>
> 1
> "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
> How would you handle differentiating between safe-coding practices and
> debugging type (internal) pre/post conditions?
Why would one bother?
A comment would serve to distinguish them, wouldn't it?
However, I have given thought to allowing conditions to be grouped,
and de-activated by gr
> "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?)
> DC> However, I have given thought to allowing conditions to be grouped,
> DC> and de-activated by group. This would probably meet your need.
>
> DC>pre mymethod : group("safe-coding practice") { @_ > 0 }
> DC>pre 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 d
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!
> I'd rather than any "variables are represented by objects" magic
> be done behind the
> No. Using !x explicitly disallows the method call in context x, even if
> there is class one, or an AUTOLOAD, or a superclass one. The idea is that
> you can specify !r, and avoid the expensive fallbacks.
This just plain seems ludicrous to me. This definitely isn't something
having to do with
> 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. =^)
> However, nobody should ever have to call something like $n->NUMBER or
> $n->asInt if they don't want to. And they definitely shouldn't have to
> know the
> > 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
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
>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
me
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)
> >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 hav
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 requi
Nathan Wiger writes:
> 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
> are done throught STORE(), and context checking is done on access. So I
> was picking at details.
Are you proposing making
On Sun, 27 Aug 2000, Nathan Torkington wrote:
> 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 whe
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
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, jus
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 lis
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 b
Michael G Schwern <[EMAIL PROTECTED]> writes:
>Like all other optimizing attempts, the first step is analysis.
>People have to sit down and systematically go through and find out
>what parts of perl (and Perl) are eating up space and speed. The
>results will be very surprising, I'm sure, but it w
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? P
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
Tom Christiansen <[EMAIL PROTECTED]> writes:
>
>Disastrously, you will then also lose the shared text component,
>which is what makes all this cheap when Perl loads.
But we can on modern OSes have shared data too.
>Since the
>modules will have to be pasted in the data segment of each process
>
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
=hea
>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 r
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 A
> =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]
Nathan Torkington wrote:
>
> When I was thinking about this very topic yesterday and today, I
> came up with this problem:
>
> @strs = ();
> match /pat/, @strs; # surprise! I'm matching on $_
>
> That is, how do you tell an empty array from no arguments?
Easy: We'll just use lazy evalua
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
=h
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 cho
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
@
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()
> 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 $f
Damian Conway writes:
>> sub foo :lvalue { $foo }
>> post foo { die if $foo == 5 }
>>
>> eval {
>> foo() = 5;
>> };
>
> Postconditions on lvalue subs are not tested until the end of the complete
> expression in which the sub is called.
But that won't change t
* 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 y
> =head1 ABSTRACT
>
> C and C are
...part of...
> what makes Perl hard to tokenize. Requiring
> them to be written C and C would
...help to...
> solve this.
Damian
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 "k
> 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
> >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 w
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 lot of language
issues to c
82 matches
Mail list logo
