Re: 6PAN (was: Half measures all round)

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'

Re: 6PAN (was: Half measures all round)

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, a

Re: 6PAN (was: Half measures all round)

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 possibilit

Re: Half measures all round

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

Re: Half measures all round

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 ineffective

Re: RFC on Coexistance and simulaneous use of multiple module version s?

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.

Re: RFC on Coexistance and simulaneous use of multiple module version s?

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?

Re: RFC on Coexistance and simulaneous use of multiple module version s?

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

Re: Multiple for loop variables

On Mon, Aug 28, 2000 at 04:10:01PM -0400, Eric Roode wrote: > Peter Scott wrote: > >Graham Barr once allowed as how he thought it would be neat if you could say > > > > for my($x, $y, $z) (@list) { ... } I too am pushing for this feature, to the point where I'm considering an rfc on the topic

HERE construct

General comment on all the discussion of HERE docs. When HERE docs cause you a problem, don't use 'em. There is little win if any over print << HERE; Dear Sir: You owe me bucks. Pay up. Me. HERE and $msg = 'Dear Sir: You owe

Re: RFC 143 (v1) Case ignoring eq and cmp operators

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

Re: Do we really need eq?

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 =

Re: RFC 114 (v1) Perl resource configuration

On Wed, Aug 16, 2000 at 08:03:31PM -, Perl6 RFC Librarian wrote: > Perl should provide a mechanism to have common code autoloaded from a > file. . . . > A C file could be used to set system-wide defaults that > the system administrator would like to promote. For instance, > C could turn on

Re: Permanent sublists (was Re: Language WG report, August 16th 2000)

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 b

Re: RFC 83 (v1) Make constants look like variables

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 --

Unify the Exception and Error Message RFCs?

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) pr

Re: RFC 83 (v1) Make constants look like variables

I really like the idea of constants in perl, but think the RFC should go a lot further. C/C++ has solved this problem; we should follow in their footsteps. Spinning off from Larrys syntactic comment and Mike Pastores example, how about some of the following: A constant struct with constant val

RFC 78 and shared vs unshared modules/data

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

Re: RFC 78 (v1) Improved Module Versioning And Searching

> 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.

My opposition to RFC20, and an alternative

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() ) && (

Re: RFC 78 (v1) Improved Module Versioning And Searching

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 p

Re: RFC 78 (v1) Improved Module Versioning And Searching

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 (ass

Re: RFC 73 (v1) All Perl core functions should return ob

I'm pretty much opposed to this idea. It's pushing OO too far onto perl.

Re: RFC 78 (v1) Improved Module Versioning And Searching

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 C and module C demand two different versions of the same > : module C, the compiler should halt and state the module conflicts. > > Pardon me for snipin

Re: Things to remove

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

Re: RFC 71 (v1) Legacy Perl $pkg'var should die

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 SH

Re: wildcard includes

I'm working on an RFC on module versioning. It'd be done by now, except my boss and family keep expecting me to work and be fatherly. :-) Let me get that banged out, and then lets look at adding wildcards to it.

RFC17 (v1) comments and responses

This is an omnibus response to those who've commented on RFC17 (v1). The version I'm about to submit to the librarian is now available as html at . General note -- please look over the abstract. Some folks have made really good suggestions to change th

Re: RFC 37 (v1) Positional Return Lists Considered Harmf

> 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 4t

Re: Language RFC Summary 4th August 2000

On Fri, Aug 04, 2000 at 03:37:08PM +1000, [EMAIL PROTECTED] wrote: > > 1. put their hands up to write the "up for grabs" RFCs > 2. work towards getting the "requested/promised" and "draft" RFCs up to >the point where they can be submitted to the librarian. > 3. let me know if you think an RFC

Re: Recording what we decided *not* to do, and why

On Fri, Aug 04, 2000 at 01:18:36PM -0400, John Porter wrote: > O.k., what I really meant was, When they're both incapable of doing > the sorts of things I want a macro language to do, does it matter > that one is gobs more powerful than the other? I freely admit to knowing very little about macr

Re: Recording what we decided *not* to do, and why

On Fri, Aug 04, 2000 at 12:07:00PM -0400, John Porter wrote: > I don't mind cpp too much; but I'd really like something much > more powerful than cpp. Hmm -- cpp++?? m4. IMHO perl6 should continue the rich tradition of stealing from the best rather than re-inventing an only marginally better w

Re: try/catch (Was: Re: RFC: Modify open() and opendir() to return handles)

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 c

Re: Removing/fixing $[line noise here] variables

In writing up the RFC on removing/fixing $[line noise here] variables, I've decided to leave out the following suggestion: On Tue, Aug 01, 2000 at 06:47:41PM -0700, Nathan Wiger wrote: > Alan Burlison wrote: > > > > Steve Simmons wrote: > > > > > I'd pr

Re: RFC: Modify open() and opendir() to return handles

On Thu, Aug 03, 2000 at 08:54:35PM +0200, Johan Vromans wrote: > Peter Scott <[EMAIL PROTECTED]> writes: > > If we get a good-looking exception throwing/catching mechanism and > > syntax, this may not matter. >try { > java >} >catch (Exception e) { > think again >} I

Re: Recording what we decided *not* to do, and why

On Thu, Aug 03, 2000 at 11:27:27AM -0600, Nathan Torkington wrote: > Steve Simmons writes: > > . . . IMHO the RFC editor should be responsible for this. > > IMHO someone should write an RFC on why perl6 should NOT have > comments. The RFC editor doesn't have time to fol

Recording what we decided *not* to do, and why

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 o

Re: RFC stuff

On Wed, Aug 02, 2000 at 08:27:19PM -0600, Tom Christiansen wrote: > What you're doing here is recreating USENET. But badly . . . > Is there an open NNTP server running with all these as the perl.* > groups? That would help a lot. Please, please, please. I'm already considering moving these s

Re: RFC stuff

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. Ba

Re: BiDirectional Support in Perl6

On Thu, Aug 03, 2000 at 02:31:01PM +0300, Roman M . Parparov wrote: > This is quite unexplored field. I, being an Israeli resident, am forced > to deal once in a while in applications that should output RTL languages, > both as plain text output and hypertext output. By RTL, do you mean the inte

Re: Where must you 'no strict'?

Summary: There is no circumstance in which I have had to do `no strict.' Background: I've spent much of the last six months cleaning up bad perl (let's hope none of my co-workers are on this list...). When I'm done with a tool or module, it runs silently under -w and under strict. 100%. I've

Re: RFC: Filehandle type-defining punctuation

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.

Re: Removing/fixing $[line noise here] variables

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 n

Module versioning changes

Despite my throw-it-over the transom comments on global vars, that's not really why I came here (tho I will pitch in on the topic). The perl features that most bites me in the ass is how module versioning and searching works. The easiest way to describe what I want is by examples, so here are se

Re: Removing/fixing $[line noise here] variables

On Tue, Aug 01, 2000 at 04:47:47PM -0400, Dan Sugalski wrote: > Put together an RFC for it. (Soon!) This is a language topic, but it will > impact internals a touch, and I'd like to get as many of the "impact > internals" things spec'd out as soon as possible . . . Uh, OK - but how about we wa

Removing/fixing $[line noise here] variables

In re the discussion of $^O, etc, etc, I'd like to throw out some ideas on these line noise features and (for lack of a better name) perl control values. IMHO there are two distinct sets of problems here. One is that the existing $[linenoise] vars are horrible names and really need some syntacti

Re: formats and localtime

On Tue, Aug 01, 2000 at 01:17:25PM +1000, Damian Conway wrote: > My (limited) understanding of the aims of Perl 6 were to start again with a > clean slate and fix the things that are broken, or that could be designed > better with hindsight. Backwards compatibily was to be fed to the lions. > >