On Tue, Jun 04, 2002 at 01:11:58PM -0700, David Wheeler wrote:
On 6/4/02 12:59 PM, Steve Simmons [EMAIL PROTECTED] claimed:
Actually, for 6PAN I think they should have to pass. And maybe we
need a bug submission setup, and status checks, and . . . OK, OK, I'll
stop now. They're nice
On Tue, Jun 04, 2002 at 04:15:02PM -0400, John Siracusa wrote in
response to me:
Frankly, I'd argue that nothing in 6PAN ought to be in alpha/beta state.
. . .
Nah, I think it's useful to be able to upload unstable versions to 6PAN to
get the widest possible audience of testers. It's a
On Tue, Jun 04, 2002 at 04:13:36PM +0100, Simon Cozens wrote:
Hmm, June 4. Independence day, with an off by 1 error. Must be a C
program involved somewhere. :-)
In brief, I'm with Damien on this one. IMHO C++ is an ugly bastard of
a programming language because they cut the cord
On Tue, Jun 04, 2002 at 05:40:08PM +0100, Simon Cozens wrote:
Steve Simmons:
We have said that perl5 will be *mostly* mechanically translatable into
perl6.
And we shall keep saying this until we believe that it is true?
*grin*
My apologies for using the wrong name, Simon. Doh!
--
STEP
On Tue, Jun 04, 2002 at 12:59:38PM -0400, John Siracusa wrote:
In the spirit of Simon's desire to see radical changes when appropriate, I
propose the following high-level goals for 6PAN . . .
1. Multiple versions of the same module may be installed on a single system
with no possibility of
Paul Johnson wrote:
Has anyone considered the problems associated with XS code, or whatever
its replacement is?
Pardon my ignorance, but what's XS code?
Many thanks to all for the pointers.
Paul Johnson wrote:
I don't think any proposal of this nature would be conplete without a
consideration of these aspects.
Agreed.
On Fri, Jan 26, 2001 at 02:08:01PM -0600, Garrett Goebel wrote:
Discussion of RFC 271 and 194 on pre and post handlers for subroutines
reminded me of Larry's desire for Perl 6 to support the coexistence of
different versions of modules.
Besides http://dev.perl.org/rfc/78.pod, are there any
On Tue, Aug 29, 2000 at 09:15:35AM +0100, John McNamara wrote:
At 13:11 28/08/00 -0400, Steve Simmons wrote:
To tell the truth, this third item should probably should become
a separate RFC, and if you'd like to simply say one is forthcoming,
that'd be fine by me.
What I really want to do
I'd like to see eq and it's brethen retained, as dammit there are times
I want to know (-w) if numbers are turning up when there should be
words and vice-versa. However, spinning off of something Randal wrote:
Yes, but what about:
$a = '3.14'; # from reading a file
$b =
On Thu, Aug 24, 2000 at 03:40:00PM -, Perl6 RFC Librarian wrote:
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Case ignoring eq and cmp operators
IMHO this problem is better solved by using =~ and its brethren,
which already allow you to do
On Wed, Aug 16, 2000 at 02:38:33PM -0400, Uri Guttman wrote:
i see problems with overlapping areas. I/O callbacks fall under both io
and flow IMO. some of the error handling like dying deep in eval and
$SIG{DIE} also fall under error and flow.
This is true, and inevitable. But IMHO it'd be
On Sun, Aug 13, 2000 at 07:35:06PM -0700, Peter Scott wrote:
At 03:30 PM 8/13/00 -0500, David L. Nicol wrote:
Whose RFC deals with this?
63, 70, 80, 88 and 96. There would appear to be a groundswell of interest :-)
Well yes, but they represent three authors with (as best I can tell)
On Sat, Aug 12, 2000 at 06:18:08AM +1000, Damian Conway wrote:
Please, please, please, PLEASE, let us not replicate the debacle that is
C++'s const modifier!
It doesn't feel like a debacle to me, it feels like it put the control
in the programmers hands. Yes, the syntax is often unweildy --
On Thu, Aug 10, 2000 at 05:46:14PM -0400, Bennett Todd wrote:
Today there's no difference. If the proposal under discussion were
to pass, and packages' namespaces were to become local to the
namespace where the "use" occurred, then perhaps main::whatever
could be a common, stable, global
On Wed, Aug 09, 2000 at 05:53:44PM -0400, Ted Ashton wrote:
I'll take that as my cue ;-).
Ah, nothing like a man who knows when to pick up his cues.
*shudder* This whole business is getting pretty scary . . .
[[ discussion of ugly implicatations elided ]]
The short answer is that
On Thu, Aug 10, 2000 at 11:01:39AM -0400, Bennett Todd wrote:
Rather than proliferating the number of keywords eaten with all
these *ref varients, this sounds like a useful place for returning
an object with a default stringification of the class:
. . .
Ref RFC 37, RFC 73.
I have no
Overloading an existing operator such that it changes the performance
in prior situation is evil, evil, evil. Yes, I know it can have some
wins, and I agree they're big ones. But no win is worth having to
debug this (admittedly contrived for the example) situation:
if ( ( $ares = A() ) (
Perhaps Damian's want() (RFC 21) can be used to allow allow either return
type?
Yes indeed.
Assuming that's adopted, of course.
Sure looks to me like a good idea; I hope it does.
On Tue, Aug 08, 2000 at 06:34:19PM -0500, Mike Pastore wrote:
Perl++
perm -- good old hairy perl, finally under control.
Running and ducking,
--Steve
On Wed, Aug 09, 2000 at 10:44:03AM -0700, Larry Wall wrote:
: Note that it may not be possible to satisfy conflicting requests. If
: module CA and module CB demand two different versions of the same
: module CC, the compiler should halt and state the module conflicts.
Pardon me for sniping
I'm pretty much opposed to this idea. It's pushing OO too far onto perl.
On Tue, Aug 08, 2000 at 10:59:40PM -0400, Dan Sugalski wrote:
On Wed, 9 Aug 2000, Damian Conway wrote:
If you take this, I won't be able to port the forthcoming Klingon.pm
module to Perl 6!!!
And this would be a bad thing how, exactly? :)
I SHOULD KILL YOU WHERE
Functions like stat() and get*ent() return long lists of mysterious
values. The implementation is assumedly easy: just push some values
out of C structs into the Perl return stack.
. . .
Firstly, who can remember which one of the stat() return values was
the atime is or which is the 4th
On Fri, Aug 04, 2000 at 09:10:38AM +0200, Johan Vromans wrote:
You missed the point.
If you need 6+ lines of code for each elementary error check, this is
what is going to happen . . .
You're correct, but that's not what I was suggesting. The magic words are
`for each elementary error
On Thu, Aug 03, 2000 at 12:51:10PM +1000, [EMAIL PROTECTED] wrote:
Programer Modifiable Warnings and Error Messages
Brust, Corwin" [EMAIL PROTECTED]
. . .
Removing/fixing $[line noise here] variables
Corwin Brust [EMAIL PROTECTED]
That second is actually mine. Barring
On Thu, Aug 03, 2000 at 11:40:24AM +0900, Simon Cozens wrote:
On Wed, Aug 02, 2000 at 07:34:36PM -0700, Nathan Wiger wrote:
That Perl should stay Perl
Do we need an RFC for this? Seems like this is more of a "guiding
concept" that should be intergrated into everything. Just my opinion.
On Wed, Aug 02, 2000 at 03:34:56PM -0400, John Porter wrote:
Brust, Corwin wrote:
I want perl's error (and warning) messages to be specific to each program I
write.
Isn't this covered by locales?
Completely different beast. I don't claim to fully understand locales,
but that's not
On Wed, Aug 02, 2000 at 11:46:15AM -0700, Peter Scott wrote:
=head1 TITLE
Filehandles should use C* as a type prefix if typeglobs are eliminated.
I could go for this, given the `if typeglobs are eliminated' caveat.
29 matches
Mail list logo
