Nice perl 6 article
http://www.unixreview.com/documents/s=1780/urm0111h/0111h.htm Dan --"it's like this"------- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Parrot demo at tonight's Boston perlmonger meeting is *off*
Folks, If anyone was planning to go to the Boston perlmongers meeting to see the parrot demo, be aware that the meeting has been cancelled. We'll try again at the next meeting. Dan --"it's like this"------- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Second public parrot demo
Hey, folks.
I'm going to be giving the world's second public parrot demo at this
month's Boston.pm meeting. It's Tuesday the 11th at 7 PM, give or take, at
the Boston.com building in (who'd've thought) Boston. :) If you're
interested in coming, make sure to RSVP to Ronald Kimball,
<[EMAIL PROTECTED]>. (Don't RSVP me! I'll lose the note!)
Directions at http://boston.pm.org/where.html, or
http://maps.yahoo.com/py/maps.py?Pyt=Tmap&addr=320+Congress+St&city=Boston&state=MA&zip=02210-1238&country=us&slt=42.351300&sln=-71.049600&mag=9&cs=9&name=Boston.com
(barring word-wrap)
And yes, we'll have details of how to get the current parrot source
yourself next monday, so you can play along at home! :)
Dan
--"it's like this"---
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
Re: perl 6 mailing lists status
At 02:24 PM 5/27/2001 -0600, Nathan Torkington wrote:
>Bryan C. Warnock writes:
>I'd like to see activity on the topics behind:
> * perl6-stdlib
> * perl6-build
>Dan, Graham--should these lists persist in their current form?
Got me, as I'm not on either set.
>It looks like the perl6-internals-api-{embed,parser,syntax-tree} lists
>represent too much fragmentation, and that the perl6-internals list is
>where that discussion will take place. Dan?
Yeah, those can go. One of those "Seemed like a good idea at the time" things.
>We'd need Chip's okay to close the Topaz list. I don't know what he
>would like to do with it.
Is Chip back from Saturn, then? :)
Dan
------"it's like this"---
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
Re: Perl, the new generation
At 04:09 PM 5/16/2001 -0400, Adam Turoff wrote:
>It's also amazing how long some people can go without seeing a
>statement modifier or non-default delimiters like s{}{};
Or for real fun, qx''; Nothing quite like disabling double-quote
interpolation to flip people out...
Dan
--"it's like this"---
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
Re: Perl, the new generation
At 01:51 PM 5/16/2001 -0600, Nathan Torkington wrote:
>Dan Sugalski writes:
> > People think they *must* know all the core bits of a language, and they
> > think that consists of all the stuff we ship with perl. (And, let's face
> > it, we ship a *lot* of stuff with perl) It's like you're not allowed to
> > know only a part of a language anymore--that's somehow ungeeky or
> something.
>
>Hmm, it'd be interesting to see a Map of Perl. Operators, functions,
>modules, features, etc. divided up according to topic and complexity
>and laid out around the central blob of "Basic Perl" that everyone
>knows (variables, assignment, math, chomp, printing, etc).
Given the different ways you can come into perl, it might be more a job for
Damian, but then the map'd likely be all Quantum or something... :)
Dan
--"it's like this"---
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
Re: Perl, the new generation
At 01:32 PM 5/16/2001 -0600, Nathan Torkington wrote: >Bryan C. Warnock writes: > > I think the biggest fear isn't that Perl is going to grow out of its > niche, > > but that it's going to outgrow it. It's great that Perl has been able to > > expand to be so many things to so many people, but not at the expense of > > forgetting its roots - of the whole Right Tool / Right Job that it came > > from. > >In that case, how exactly has it forgotten its roots? I mean, in what >way is it not as useful as it was before? It's not. (Well, OK, there's the speed thing--perl is slowing down) It's all perception... Dan ------"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Perl, the new generation
At 12:49 PM 5/16/2001 -0600, Nathan Torkington wrote: >So I guess I don't see it as that big a problem. Am I missing >something? I think you might be. This isn't a problem of reality--it's a problem of perception and personal tendencies. People think they *must* know all the core bits of a language, and they think that consists of all the stuff we ship with perl. (And, let's face it, we ship a *lot* of stuff with perl) It's like you're not allowed to know only a part of a language anymore--that's somehow ungeeky or something. I've seen the same thing with C++, where folks think they need to know the whole class library and STL before they can do anything. And cheap shots at C++ aside, that's not true either--you can be perfectly productive writing standalone code without knowing all those bits. Dan ----------"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Perl, the new generation
At 11:58 AM 5/16/2001 -0400, Adam Turoff wrote: >On Tue, May 15, 2001 at 03:41:15PM -0600, Nathan Torkington wrote: > > Stephen P. Potter writes: > > > When we moved from 4 to 5, so people thought we should continue > > > developing 4 without all the "useless" new stuff, like OO and > > > threads and etc. I wonder more and more if they weren't right. I > > > wonder if as 6 develops if we shouldn't split off the old 4 syntax > > > and have two languages. > > > > If you want to do it, do it. I vomit at the thought of a language > > without data structures or modules, though, and I wouldn't be > > surprised if others did too. > >It's not so much that Perl shouldn't have data structures or modules. >I think what Stephen is saying (and he's not the only one) is that >the bare minimum amount of Perl you *must* know to be productive >is increasing. Either that, or we're giving the impression that >it's increasing. Many people don't want to get bogged down in how >the details of Unicode, upperclass level CS topics or Perl's unique >syntactical peculiarities to parse a damn log file (or find and >use a CPAN module that does it). I don't know if it's much reassurance to anyone, but I use quick-n-dirty perl a lot. Making it not go away is definitely not in the program. I think we really, really need a perlquick.pod or something that just runs through the amount of perl you need to do simple filter & file processing tasks. Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: You will not have to rewrite your Perl 5 programs!
At 02:58 PM 5/10/2001 -0700, Nathan Wiger wrote:
>* Dan Sugalski <[EMAIL PROTECTED]> [05/10/2001 14:18]:
> > >
> > >Perl 6 *will* provide a backwards compatible Perl 5 parser. The
> > >details are not nailed down, but this definately will happen.
> >
> > Damn straight. One way or another, perl 6 will eat perl 5 code close to
> > painlessly. (Typeglobs, perhaps, aside)
>
>Cool. Dan, is this a fundamental change from the philosophy that you
>expoused earlier? Last time I brought this up it seemed you were
>against having perl6 eat perl5 code. I'm thinking specifically of:
>
> http://www.mail-archive.com/perl6-language@perl.org/msg06258.html
>
>I'm NOT trying to put you on the spot :-), just wondering if the
>philosophy has changed...
Yes, it has. (And feel free to put me on the spot--If I say stupid and/or
contradictory things in public I ought to be called on it... :)
Dan
--"it's like this"---
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
Re: You will not have to rewrite your Perl 5 programs!
At 10:06 PM 5/10/2001 +0100, Michael G Schwern wrote: >I'd just like to make this abundantly clear, since there seems to be >some confusion (and hopefully I'm not the one confused). > >*** You will NOT have to rewrite your Perl 5 programs *** > >Perl 6 *will* provide a backwards compatible Perl 5 parser. The >details are not nailed down, but this definately will happen. Damn straight. One way or another, perl 6 will eat perl 5 code close to painlessly. (Typeglobs, perhaps, aside) Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Not revisiting the RFC process (was: RFC 362...)
At 02:24 PM 2/22/2001 -0800, Edward Peschko wrote: > > No. Please don't, and save me the trouble of having to reject them. I'd > > rather not do that. > >Exactly my point. There is no recourse that is given to me, or a lot of other >people for that matter. Well, there's always the implementation. Granted, it's the messy, nasty side of things, but it is the area we're presently working in. Knowledge of C is *not* required either--just because that's what the current pieces up for discussion are written or going to be written in doesn't mean we can't open things up more. A good chunk of perl 6's internals will be extendable via perl. >And like I said, my time is variable, and the time that I have to devote to >design/implementation of perl is limited may or may not follow Larry's >schedule. > >So I'll leave it up to you - what venue/recourse/means do I have for >submitting new ideas for review? > >And please don't say via mailing list because submitting new ideas via >mailing list is absolutely pointless. Then at the moment you don't really have one. If that's a problem, then I'm sorry. >I'd rather write them semi-formally, catalog them, get input on them while >they are still hot, and have them archived somewhere. seems the most >productive thing for me to do... I'm not entirely sure about that. Writing proposal documents that build on a foundation that doesn't actually exist may not be the most productive use of your time. It would really suck to spend days on something that turns out to be unimplementable or meaningless because the design decisions it was based on were faulty. Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Not revisiting the RFC process (was: RFC 362...)
At 01:41 PM 2/22/2001 -0800, Edward Peschko wrote: >On Thu, Feb 22, 2001 at 04:04:31PM -0500, Adam Turoff wrote: > > emphatically not a series of RFCs. We made mistakes with the RFC > > process and don't want to repeat them. > >But you are making a fundamental mistake if PDDs are shoehorned to fit the >entire design process. RFC's should be messy, outspoken, and they should >cover the entire spectrum of what perl is about. They should then be >drilled *down* into PDDs. PDDs are for internals pretty much exclusively. If it doesn't involve the implementation or design of the low-level guts of perl, it doesn't belong in a PDD. Which isn't to say it has to all be C and bit-level things--the parser wedges that can be written in perl would be specified in perl, of course. Some random stranger should be able to take all the 'standard' PDDs (however they're marked) and build a perl interpreter/compiler. That's the plan, at least. > > There's nothing stopping you, but the RFC archive is closed and > > will likely not be reopened (save for some minor details in the > > queue). It's primary value is in cataloging a series of ideas of > > what Perl could or should become. > >Exactly... and your point is that 'the number of things that perl6 which Perl >could or should become' is now fixed in stone? Well, I think Nat's planning on switching over a different name and restarting the numbering scheme, so that's something. The bigger thing is that the new proposals will be based on the perl we produce from Larry's design. They'll be (mostly) incremental changes, rather than wildly radical ones, since they'll start from a fixed base. I hope. :) > > > So I ask you - *why* make an artificial deadline? What's the point? > > > > The deadline was not artificial. It was by design. > >yes. It was 'artificial' by design. It was artificially imposed. And it was >wrongfully imposed. Yes it was, and no it wasn't. At some point you need to retreat, take the brainstorming, and produce a spec then an implementation. We've left the brainstorming stage and are waiting for Larry to get the spec together. (More or less) Once we've got an implementation, then it'll be time to start brainstorming in earnest again, though I fully expect there to be a batch of RFCs and PDDs for the things that didn't make the first cut for whatever reason. (Time, personnel, my sanity... :) That's OK too. >I can see the value of having an initial 'cutoff', and then having cutoffs >going on forward, but to say *whoa nelly* the only forum now >for off the cuff discussion is via thread is just wrong. No, it's appropriate. Whether the delay between the cutoff and the spec is appropriate is what's really the issue. I'm not going to go there, though. >We've tried that before; it was called perl5-porters. It led to the same idea >over and over again because there was no formal way of cataloging good ideas >and bad ideas. Nah, p5p was something else entirely. I do think things'll go better for perl 6. >And before you say 'this is PDD', think of exactly how badly this would dilute >the PDDs. PDDs would contain everything from undigested ideas to meticulously >crafted ones. It would be a mess. Well, the RFC library (the real one the IETF has) is a lot like that, but the internet hasn't collapsed yet, Infinite Monkeys protocol or not. > > If you want to contribute, patch bleadperl, or make a contribution > > on what we're doing today. > >Ok, you are on. I'll write up my 30 ideas, and you'll accept them as PDDs. Ok? No. Please don't, and save me the trouble of having to reject them. I'd rather not do that. Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: State of PDD 0
At 04:01 PM 2/20/2001 -0700, Nathan Torkington wrote:
>Dan Sugalski writes:
> > I've been thinking since I sent my last mail on this that we might
> actually
> > want to leave the two (PDD & RFC) separate. Keep on with the RFCs for
> > 'external' things, and PDD for the actual internals implementation of
> things.
>
>Ultimately, I think we're going to need at least three different
>types of documentation:
>
> * internals design documents (PDDs)
> * language design documents (PLDs?)
> * change requests, once we've got something to change (PCRs)
That works. I rather like it, and I expect once we get a working perl 6, we
probably won't need to freeze things either--worst case we mark a proposed
document irrelevant or something of the sort.
Dan
--"it's like this"---
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
Re: State of PDD 0
At 04:43 PM 2/20/2001 -0600, Jarkko Hietaniemi wrote: >On Tue, Feb 20, 2001 at 02:43:14PM -0800, Peter Scott wrote: > > At 05:30 PM 2/20/01 -0500, Dan Sugalski wrote: > > >At 02:15 PM 2/20/2001 -0700, Nathan Torkington wrote: > > >>Bryan C. Warnock writes: > > >> > Ask, all, are we reusing perl6-rfc as the submittal address, or > will there > > >> > be a new one (perl-pdd)? > > >> > > >>I'm in favour of renaming to reflect the new use of the list. Dan? > > > > > >I've been thinking since I sent my last mail on this that we might > > >actually want to leave the two (PDD & RFC) separate. Keep on with the > RFCs > > >for 'external' things,... > > > > I suggest that we clearly delineate the RFCs which were pre-deadline from > > the ones that are post-deadline. The advantage to having the original > > deadline was that it motivated many of us to get off our butts and fish or > > cut bait. If we're going to continue this process now, I move that: > > > > New RFCs be numbered starting from 1000 (easiest way to denote the > difference); > > > > Old RFCs are frozen, and that means frozen. I have no idea how far > Larry's > > got on digesting them and I really don't want to try and interfere with > > something that could be making its way down his small intestine. People > > should be free to write new RFCs that contradict older ones, or head > off on > > some tangent, but please let's not keep refining the old ones, enough is > > enough. > >Strongly agreed. That works for me--we could increment the thousands number by one each time we open things up for a new RFC period. Once we have a working perl 6 of some sort we can kick in with RFC 1000, and once perl 6.1 is done we can go with 2000, and so on. Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: State of PDD 0
At 02:38 PM 2/20/2001 -0800, Ask Bjoern Hansen wrote:
>On Tue, 20 Feb 2001, Dan Sugalski wrote:
>
> > > > Ask, all, are we reusing perl6-rfc as the submittal address, or
> will there
> > > > be a new one (perl-pdd)?
> > >
> > >I'm in favour of renaming to reflect the new use of the list. Dan?
> >
> > I've been thinking since I sent my last mail on this that we might
> actually
> > want to leave the two (PDD & RFC) separate. Keep on with the RFCs for
> > 'external' things, and PDD for the actual internals implementation of
> things.
>
>I have created perl6-announce-pdd. Mail [EMAIL PROTECTED]
>for clues.
>
>How should the submission process work? As for the RFC's?
Sounds good to me.
Dan
--"it's like this"---
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
Re: State of PDD 0
At 02:15 PM 2/20/2001 -0700, Nathan Torkington wrote: >Bryan C. Warnock writes: > > Ask, all, are we reusing perl6-rfc as the submittal address, or will there > > be a new one (perl-pdd)? > >I'm in favour of renaming to reflect the new use of the list. Dan? I've been thinking since I sent my last mail on this that we might actually want to leave the two (PDD & RFC) separate. Keep on with the RFCs for 'external' things, and PDD for the actual internals implementation of things. Dan ------"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: RFC 362 - revisiting the RFC process (was Warnings, strict, and CPAN)
At 01:36 PM 2/20/2001 -0800, Edward Peschko wrote: >On Mon, Feb 19, 2001 at 11:38:03PM -0500, Dan Sugalski wrote: > > At 07:20 PM 2/19/2001 -0800, Edward Peschko wrote: > > >RFC 362 > > >--- > > > > > >=head1 TITLE > > > > > >The RFC project should be ongoing and more adaptive. > > > > It's my understanding that this is, in fact, the plan. The only reason > > things have paused (and it is a pause, not a stop) is that we're waiting > > for Larry to take what's been done so far and build something resembling a > > coherent base we can implement. After that's done then we'll have > something > > to work from, which is a good thing. > >Ok, fair enough. I think that perl should have a two-tiered process >though, and >it should be ongoing and two tiered. > >Bryan Warnock mentioned PDD as being 'comprehensive', but I think that is a >mistake. There should be a more formal process for distilling conversations, >lest we repeat length(@array), '??', etc, ad-nauseum. PDD should be stuff >that was decided as 'golden' and then implemented. Honestly, the PDDs are for the stuff that was implemented, not the stuff that was decided. Or, more clearly, PDDs describe the implementation or proposed implementation at the internals level. RFCs are for language-level features. We should have PDDs on garbage collection and memory allocation (I know, I know--I'm working on it! :). We should not have PDDs on, say, currying. Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Things have paused... really?
At 01:32 PM 2/20/2001 -0600, Dave Rolsky wrote: >On Tue, 20 Feb 2001, Simon Cozens wrote: > > > valuable and interesting. (aside: Python is Mahler. Discuss.) So while > we may > >Hmm, I think of Python as more Babbit than Mahler. Perl is ... John Cage? Would that mean that perl 6 corresponds to 4'33"? (If I have the composers right...) Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: State of PDD 0
At 01:05 PM 2/20/2001 -0500, Bryan C. Warnock wrote: >On Tuesday 20 February 2001 11:22, Dan Sugalski wrote: > > D'oh! Yes, mark it as Approved, or whichever step is past developing. >(I'm > > a little scattered at the moment, so I don't have the doc handy) > >Actually, now that I've been updating this, I'm going to hold it at >development for a little while, if only because I have some more changes >coming down the pike. (The actual formatting will stay the same, so I >guess Simon would call these meta-meta-meta changes.) Fair enough. PDD 0, version 2... :) >Ask, all, are we reusing perl6-rfc as the submittal address, or will there >be a new one (perl-pdd)? Let's use perl-rfc for now. Dan ------"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: State of PDD 0
At 09:05 AM 2/20/2001 -0500, Bryan C. Warnock wrote: >To date, I've received a whopping zero comments on PDD 0, the defining >document for the PDD process. > >That means one of five things: >http:[EMAIL PROTECTED]/msg01126.html > >Nat, Dan: PDD 0 is also still at the Proposed level (even though it was >assigned a number). Is it at least good enough to bump to Developing? D'oh! Yes, mark it as Approved, or whichever step is past developing. (I'm a little scattered at the moment, so I don't have the doc handy) Dan ------"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: RFC 362 - revisiting the RFC process (was Warnings, strict, and CPAN)
At 07:20 PM 2/19/2001 -0800, Edward Peschko wrote: >RFC 362 >--- > >=head1 TITLE > >The RFC project should be ongoing and more adaptive. It's my understanding that this is, in fact, the plan. The only reason things have paused (and it is a pause, not a stop) is that we're waiting for Larry to take what's been done so far and build something resembling a coherent base we can implement. After that's done then we'll have something to work from, which is a good thing. If we don't ever stop, ponder, and implement, the RFCs will be just another go-round of intellectual masturbation. (and we *really* don't need to go there...) Yeah, it means the process will be bursty, but that's just the nature of the beast. Dan ------"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: "Art Of Unix Programming" on Perl
At 11:48 AM 2/12/2001 -0800, Edward Peschko wrote:
> > Rushing the process because of intermittent PR problems isn't going
> > to make Perl6 any better at achieving it's goal - solving tomorrow's
> > problems better than Perl5.
>
>Again, I don't think that this would be rushing things at all. Give a
>couple of RFC's to chew on, announce it to the world, develop interest,
>give the 'perl internals' people stuff to work on, generate discussion,
>move from high-level design to medium-level design.
While I'm not in a position to rush Larry, we are starting in on the bits
of the internals that we can do without much input from him. It's slow
going (mainly because we've been waiting) but it has started.
Hopefully we should see some actual progress reasonably soon.
Dan
------"it's like this"---
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
Re: "Art Of Unix Programming" on Perl
At 07:06 PM 2/9/2001 +, Simon Cozens wrote:
> > Perl's internals are notoriously grubby; it's been understood for years
> that
> > the language's implementation needs to be rewritten from scratch, but an
> > attempt in 1999 failed and another seems presently stalled.
>
>If that other is Perl 6, I don't think we're stalled, are we? Language design
>is waiting on Larry to produce the spec, and internals design is going on
>quietly but steadily. We're in the design stage. That'll probably last a
>while because scripting languages and interpreters aren't easy things to
>design, and are even harder to get right.
Yes, but you see, we're not generating code. All the rest of the stuff is
irrelevant, and Real Hackers don't need to design--it's all self-evident.
Besides, you only need to design if you're building one of those Cathedral
thingies, and we all know how bad those are. (If you need to reach higher,
the correct method is, of course, to add another layer of tents on top of
the previous one)
Dan
--"it's like this"---
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
Re: What's a PDD for the rest of us?
At 03:08 PM 12/6/00 -0500, Bryan C. Warnock wrote:
>On Wed, 06 Dec 2000, Dan Sugalski wrote:
> > Well, until Larry releases the spec, just about everything else is frozen,
> > though we can certainly expand the PDD stuff to include the standard
> > library, documentation, and QA stuff. (It seems a tad premature to be
> > proposing language changes when we neither have a final language spec nor
> > an implementation of that spec...) PDDs don't have to be all internal--I
> > changed the name to deal with the confusion with the IETF's RFCs. (We were
> > fast creeping up on the active RFC range)
>
>Understood. One other quick question. Are the PDDs expect to go terminal at
>the delivery of Perl 6, or should the active PDDs continue to evolve and
>govern Perl 6 maintenance as well? (If that makes any sense.)
I want them to continue, though whether they do depends on who has the
magic sucker hat once things go final. It's my intent that anyone who wants
to get complete documentation for X (where X could be the parser API, or
the vtable API, or the guaranteed behaviour of the GC, or the PerlIO API
and required behaviour) can grab the PDD covering it and be set.
Something, more or less, like the IETF standards RFCs, only with revisions
of each PDD rather than a half zillion "supercedes or upgrades" RFCs.
Dan
--"it's like this"---
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
Re: What's a PDD for the rest of us?
At 02:39 PM 12/6/00 -0500, Bryan C. Warnock wrote: >In http://www.mail-archive.com/perl6-internals@perl.org/msg01766.html, >Dan outlined rev 2 of the RFC process, PDD (Perl Design Docs). > >Everything seems rather specific to internals - will there be a separate >mechanism in place for all-things non-internal, say, for instance, the format >for a non-internal mechanism mirroring the PDD? Well, until Larry releases the spec, just about everything else is frozen, though we can certainly expand the PDD stuff to include the standard library, documentation, and QA stuff. (It seems a tad premature to be proposing language changes when we neither have a final language spec nor an implementation of that spec...) PDDs don't have to be all internal--I changed the name to deal with the confusion with the IETF's RFCs. (We were fast creeping up on the active RFC range) Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
A moment about software quality...
http://www.salon.com/tech/feature/2000/12/06/bad_computers/index.html And no, open source software is *not* immune. Dan --"it's like this"------- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Tech documentation (Re: Perl Apprenticeship Program)
At 04:29 PM 12/5/00 -0500, Kirrily Skud Robert wrote: >On Tue, Dec 05, 2000 at 11:28:31AM -0800, Nathan Wiger wrote: > > > > Anyways, that's just one suggestion. Do I have any idea where to find > > these mythical people? No, unfortunately. Perhaps some feelers on > > newsgroups might be a good place to start. Personal experience shows > > that this could be a win, though. > >Open Source Writers Group (http://oswg.org/) is a good starting point. >I'm subscribed to their mailing list. I can think of a couple of other >good places to try, too, but they're a bit politically incorrect to >mention in this context :-/ Who on earth would be considered politically incorrect in this context? Dan ----------"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Perl apprenticing (was Re: Backtracking through the source)
At 01:23 PM 11/30/00 -0500, Buddha Buck wrote: >At 11:47 AM 11-30-2000 -0500, Bryan C. Warnock wrote: >>I forget who proposed it originally, but I thought it an excellent >>analogy, and >>an excellent model for Perl development. Like any tradecraft, there are >>masters, apprentices, and the common consumer. The apprentice shouldn't >>master, just as the common consumer shouldn't apprentice. Unfortunately, >>right >>now it's "choose your own category." I'll elect to choose low. I'm an "Perl >>apprentice wanna-be", in search of an opportunity to prove that I am >>apprentice >>material. (I think too many PAWBs are looking for opportunities to prove >>that >>they are master material. I'm not about to shoot myself in the foot that >>way. >>At least on purpose. Slap me around if I get too obnoxious.) > >Here here! Is there a place where PAWB's can sign up? Not at the moment, at least not formally. Want to set something up? (And yes, I'm serious. A good master/apprentice thing would help a lot of folks, I think) >I'm signed up for the -internals lists mainly as an educational >experience. It should be fascinating to see how a system as complex as >Perl 6 gets developed, even if I'm unable, through lack of skill, to >directly contribute. My hope is that if I'm not able to contribute to >Perl 6, then I should have learned enough to be able to contribute to Perl >6.1 (or Perl 7, whichever is next). Do be careful of selling yourself short. While you might not necessarily have the appropriate skill set to deal with parts of the perl core, that doesn't mean you can't contribute. (This is the generic rather than specific 'you' here) A good working knowledge of, say, the properties of complex numbers is as important as knowledge of the guts when building the complex number class. Or, to use the building analogy, you don't need to be an architect to say "shouldn't the bathroom have a door in it?" :) Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Backtracking through the source
At 10:07 AM 11/30/00 -0500, Andy Dougherty wrote: >On Thu, 30 Nov 2000, Bryan C. Warnock wrote: > > > You don't want the compiler design to be a 'hands-on experiment' for us > > inexperienced folk? That's not elitist, that's pragmatic. > > > > You don't want this to be a learning experience - (corrections, > observations, > > answers) - to the same? *That's* elitist. > >Fair enough to a point, but please let's not overburden the experienced >folk by also _expecting_ them to always supply "corrections, observations, >and answers". To carry Simon's analogy forward, it's the same as walking over to the construction site and asking the construction crew lots of questions. You can hope they'll answer and expect they'll be reasonably polite to a point, but they're not always going to answer, aren't obligated to educate you on how to design or build buildings, and some of them may tell you to go away if you pester them. That analogy, however, isn't applicable here. We're not building anything yet. What we're doing is *designing* the building. A more appropriate analogy is one where you walk into the architect's conference room and start commenting on and fiddling with the design of the building. While the sign says "Open Meeting", the expectation is that you're competent in the areas you'll choose to participate in. Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Guidelines for internals proposals and documentation
At 02:45 PM 11/17/00 +, David Grove wrote: >Dan Sugalski <[EMAIL PROTECTED]> wrote: > > > At 10:19 AM 11/17/00 -0800, Ken Fox wrote: > > >However, I don't want to see early (premature) adoption of fundamental > > >pieces like the VM or parser. It makes sense to me to explore many > > possible > > >designs and pick and choose between them. Also, if we can keep >external > > API > > >design separate from internal design I think we'll have more wiggle >room > > >to experiment. (That's one of the big problems with perl 5 right now.) > > > > That's one of the reasons I'd like to work on the APIs first. I realize > > > that doing even that will have an effect on the design of the pieces > > behind > > the APIs, but we have to startsomewhere. > >But.. but... but... we don't even have a design spec. I mean, we don't >even know for sure what Perl 6 is going to look like for certain, inside >or outside. Wouldn't we have to know the outside before we try to put the >insides together? No, not really. For the actual code we will, of course, but there's a lot we can do now. (And a good part of the parser could still be written now, since most of the changes will likely be reasonably trivial) The APIs perl presents to the world are pretty much independent of the language. For example, we can take a good stab at the extension API now--regardless of how the language looks, extensions will still need to get and set scalar, hash, and array values. Perl would have to change a *lot* for that to be no longer valid. The API presented to an embedding programs similarly can be worked on--the fact that the language might change doesn't alter the syntax of the run_perl_code() function. (or whatever we call it) We also do have, generally speaking, a picture of both perl (since Larry has said we're not gutting the language entirely) and the internal structure. I've been a bit lax in presenting that internal picture, but I'll fix that in a little bit. Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Guidelines for internals proposals and documentation
At 10:19 AM 11/17/00 -0800, Ken Fox wrote: >However, I don't want to see early (premature) adoption of fundamental >pieces like the VM or parser. It makes sense to me to explore many possible >designs and pick and choose between them. Also, if we can keep external API >design separate from internal design I think we'll have more wiggle room >to experiment. (That's one of the big problems with perl 5 right now.) That's one of the reasons I'd like to work on the APIs first. I realize that doing even that will have an effect on the design of the pieces behind the APIs, but we have to startsomewhere. >One issue with the language RFC process that Larry and Mark-Jason Dominus >have discussed is inconsistency. (I still can't figure out whether it's a >strength or weakness.) We should do a better job of telling people about >how our PDDs fit into the bigger picture. I propose that all PDDs state >which other PDDs they require, which they supersede and which they conflict >with. This will make it a lot easier to identify coherent designs. That's one place where the PDD process and the earlier RFC process will differ. Docs that make PDD 'developing' status or better are real design documents for what'll ultimately be perl 6. Most of the brainstorming work I'd like left on the mailing lists, or in informational PDDs. (And I'd like to try and keep those reasonably relevant) >Dan Sugalski wrote: > > 2) We start counting from 2. (RFCs 0 and 1 are reserved, in case anyone > > beats me to them) > >(I thought you said they were PDDs... ;) D'oh! :) >Why don't you just quickly issue several PDDs on the subjects that you >want to reserve. They can be skeleton documents that just contain the >sections you want us to write. (I hope that the numbers 0 and 1 aren't >important -- they might be superseded by PDD 16 and 23...) They're policy/philosophy/broad-outline docs, so they're unlikely to be replaced anytime soon. > > 3) The format of the previous RFCs will be followed. The implementation > > section is optional, though strongly encouraged where appropriate. > >I disagree. An implementation section is mandatory for a PDD. Anybody >that can't bother to take the time to sketch out a *possible* implementation >hasn't thought deeply about the subject. Anything without an implementation >section is just a draft. If a PDD is a proposal for an API, then most of >the PDD is the implementation section! No PDD's going in without someone responsible giving it the nod, so I'm not worried about drafts getting in without a good reason. And one of the reasons that the implementation section's optional is that I don't see a reason to enforce it for PDDs that specify APIs, for example. Code and/or algorithms for those (along with things like the bytecode PDDs) seem rather superfluous. Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Guidelines for internals proposals and documentation
At 12:38 PM 11/15/00 -0500, Adam Turoff wrote: >On Wed, Nov 15, 2000 at 04:42:58PM +, Nicholas Clark wrote: > > On Wed, Nov 15, 2000 at 11:35:56AM -0500, Adam Turoff wrote: > > > All PDDs (like RFCs) need to start with 'Status: Developing' by default. > > > Since statuses like 'Standard', 'Rejected', etc. have Real Meaning (tm), > > > there should be some review in place (by a WGC, principal, > etc.). Statuses > > > like 'Withdrawn' and 'Superceded' should be accepted from PDD > authors/teams. > > > > They don't need to start with "Developing" if they start with status > > "Experimental" or "Proposed" > >The real issue is that there needs to be at least one default status that >the author can assign. With RFCs, Developing referred to the RFC, and >with PDDs, they refer to the underlying design/interface/implementation. >I think I misread Dan's re-interpretation of 'Developing'. Probably. I don't think I was clear enough the first time around. > > > This is a community process. I'm uncomfortable leaving such decisions > > > to such a small number of people. How about nominating/electing a > > > > If PDDs start as "Proposed" without needing any approval does this remove > > the problem of a small group having a stranglehold? > >No, because Dan has proposed a 'core team' of sorts, where any one >of the (at least) three team members cast a final vote (towards >'standard' or 'rejected'). Yup. >Keep in mind that this isn't "Dan's Perl API" (or Nat's, or Larry's), >but "Our Perl API". I'd be more comfortable if at least two people >(from a group of >4) were involved in making any decision that >carries weight, or if there were a process of rotating the WGC as >necessary to avoid Pumpking Burnout (tm). This only holds while the primary design takes place--what happens when perl 6 hits maintenance/extended development is still up in the air. (read: That's *not* my problem... :) I want perl 6's internal API to have the same sort of artistic integrity that the language has. That's not, unfortunately, possible with everyone having equal say. I'd like it to be otherwise, but that's just not possible with people involved. The point is definitely *not* to do any sort of consolidation of power. Anyone reasonably sane, capable, and interested is welcome to chair any of the internals design lists and/or be responsible for shepherding a PDD to solidity. That's fine with me. (In fact I'd be thrilled if the design was handled by a host of folks that weren't me) My job is to play the Larry role for the backstage stuff. Luckily for me the task is reasonably partitionable, so I don't have nearly the burden of consolidating things that Larry does at the language level, and what I'm trying (perhaps clumsily) to do is farm out pieces to people while making sure we don't start with the sort of mess we have now with perl 5. Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Guidelines for internals proposals and documentation
At 03:48 PM 11/15/00 -0500, John Porter wrote: > > team, the leader could be removed by majority appeal, but otherwise has > > authority in that area, and could not override the group. With the groups > > as a collective, general election of a core team was shot down > >We take it in turns to act as a sort of executive officer for the week... Supreme executive power derives from a mandate from the masses, not from some farcical aquatic ceremony. (But that's only because we didn't all manage to get to the Monterey Bay Aquarium at the same time... :) Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: The new api groups
At 03:34 AM 11/15/00 +, David Grove wrote: >I'm on announce, I believe... I didn't get anything. (Internals seems like >a poor place to make than announcement.) How do I check to see that ezmlm >hasn't unsubscribed me from announce when my server was down last week for >a couple of days? It's read-only, so I can't test-post to it, and I'm not >up on ezmlm grammar. Just [EMAIL PROTECTED] with a help/help? It's always safe to resubscribe. You'll get an error message if you're on already. Dan ------"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Guidelines for internals proposals and documentation
At 07:35 AM 11/15/00 +, Mike Lacey wrote: >- Original Message - >From: "Dan Sugalski" <[EMAIL PROTECTED]> >To: <[EMAIL PROTECTED]> >Cc: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>; "Nathan Torkington" ><[EMAIL PROTECTED]> >Sent: Tuesday, November 14, 2000 10:59 PM >Subject: Guidelines for internals proposals and documentation > > > > Here are some guidelines for the design process for internals-level docs. > >(good stuff ommitted) > > > 7) These are *not* brainstorming documents! These are solid, concrete > > proposals for either the design or implementation of perl 6. If you have a > > brainstorm but don't currently have the skillset (or requisite brain > > damage... :) to make a concrete proposal, get in touch with either the > > correct WG chair or Nat or me, and we'll do our best to hook you up with > > someone in a position to make your ideas concrete. > >Dan, > >Shouldn't there be another stage (that other people could contribute to) >before you pass a wild-but-maybe-useful idea to >someone? Yup. That's what the lists are for. If the split list format doesn't work (and it might) it'll be on perl6-internals, otherwise it'll be on the appropriate sub-list. Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Guidelines for internals proposals and documentation
Here are some guidelines for the design process for internals-level docs. 1) The damn things will be called PDD, or Perl Design Documents. Calling them RFCs was getting confusing for those of us dealing with IETF RFCs, especially as we're edging in towards the active RFC range. 2) We start counting from 2. (RFCs 0 and 1 are reserved, in case anyone beats me to them) 3) The format of the previous RFCs will be followed. The implementation section is optional, though strongly encouraged where appropriate. The status field is mandatory--PDDs submitted without one get a status of "Informational". 4) The PDDs are real documentation. When one goes to status:Standard, it *will* describe reality. If, when reality materializes, it doesn't then it needs to be updated. Someone should, for example, be able to take the PDD on vtables and write their own perl datatype without needing to refer to the source. 5) The stauses for PDDs are: proposed: Someone's putting forth a concrete proposal developing: The PDD is in active development and considered a real part of perl 6. standard: The PDD's done. (Well, for now at least) superceded: The PDD's been replaced by another. informational: The PDD is merely informational, and not a standard experimental: The PDD describes an experimental thing, and isn't a standard. 6) Only a WG chair, pumpking, or one of the principals (i.e. Me, Nat, or Larry, or our replacements) can mark a PDD as developing, standard, or superceded. 7) These are *not* brainstorming documents! These are solid, concrete proposals for either the design or implementation of perl 6. If you have a brainstorm but don't currently have the skillset (or requisite brain damage... :) to make a concrete proposal, get in touch with either the correct WG chair or Nat or me, and we'll do our best to hook you up with someone in a position to make your ideas concrete. Dan ------"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Fwd: new lists. perl6-internals-api-*
At 12:10 PM 11/14/00 +, David Grove wrote: I think these questions have been answered already, but just in case they haven't it doesn't hurt to re-iterate. >Sorry for the crosspost (the information was requested). This is where I >got the information on the new api groups. I've subscribed to the groups >but haven't seen any traffic on them yet. I don't see any reason to >believe that this wouldn't be authentic, but if it is, then if I'm not >missing some huge discussion somewhere, then somebody's got the cart >before the horse... The groups generally are independent of Larry's work, and if it turns out that the RFCs they produce need changing when he's done, well, that's OK. They're started because I want to get *something* done, and they're in the area where we don't have to wait for Larry to at least get starte. >You know anything about this Nat? Nat, this also brings up another issue I >hadn't foreseen. If one person (Dan, Sarathy, or whoever, not picking on >anybody) leads so many working groups, how can that work into the fairness >system that we banged our heads together to eek out? Kudos to Dan for >(trying to) take on so much, but the wisdom of this is questionable, even >if he can handle all the work. I'm in as chair only because I didn't think quite enough to call for volunteers first. (I've got something mono-ish--go easy on me :) I'm all for changing the chairs, as well as the target date. In fact, an announcement to that effect will go out in a bit. >The frustrating part is that I actually want to participate in the parser >group. I think I have some to add. The problem is we don't have any >language definition from Larry yet, so figuring out a parser seems wy >premature. We don't even know what's desired in the core, since we're >looking toward a minimal core. The parser group is for the parser *API*, not the parser itself. It's supposed to design the calls inside the parser for wedges written in perl or C and suchlike things, so when it's done we can start writing a skeleton parser piece. The calls won't change much, I think--what token boundaries are doesn't matter if we're only defining the format for the function that'll be calld when one's seen. That the language isn't fully defined doesn't mean we can't start parsing with perl 5 and go from there, but that's a separate issue for a separate group that's not started yet. Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: The new api groups
At 12:17 AM 11/14/00 +, David Grove wrote:
>Dan & al.,
>
>I'm very surprised to see planning groups for api and parsing for perl6
>springing up, with goals of providing RFC's in nine days. This is rather
>confusing given that Larry hasn't yet (that I'm aware of) determined what
>Perl6 will even look like, what, if any, new keywords will be there, what
>will be features of the language, etc. Planning a map from "here" to
>"there" doesn't sound quite feasible when we don't know where "there" is.
>What am I missing?
Well, the APIs are for the most part independent of what Larry's doing--the
API an interpreter presents to an extension doesn't have much to do with
what the language looks like.
The deadlines are so close mainly because things got held up a bit. I asked
Ask to set them up just before the mail loop from hell caught the vmsperl
and p5p lists, so the deadlines are shorter than they need to be.
(Though I don't think we really need more than a few weeks to get a good
set of working RFCs for this, though of course they'll get amended and
expanded as work proceeds)
Dan
--"it's like this"---
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
Re: Critique available
At 04:41 PM 11/3/00 +, David Grove wrote: > > > Anyone think others are needed? > >or, roughly translated, "Issues should be faced rather than avoided by >attacking the person who points them out." I'd lump that in with act professionally, though in general issues do need direct addressing. It's also important that everyone involved in the discussion realize that they may be wrong. (And sometimes wildly wrong) Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Critique available
At 09:30 PM 11/3/00 +, Simon Cozens wrote:
>On Fri, Nov 03, 2000 at 04:42:34PM -0500, Stephen P. Potter wrote:
> > Not to mention "revisionist history". There were any number of uncourteous
> > voices during the RFC process.
>
>Exactly. Dan, weren't you the very person who had to tell people on more
>than one occasion to grow up and behave like adults?
Yup. And, amazingly enough, they did. :-P
This is a rather important thing, as community building is concerned.
Explicit expectations of behaviour are a *good* thing, assuming it doesn't
get tyrannical. I'm not talking about the occasional outburst--everyone has
bad days, and sooner or later just about everyone's going to flip out in
public. (I fully expect at some point I shall go embarrassingly ballistic
for all to see :) That's OK. But what we as a community should do is
decide, generally or exactly, what is and isn't acceptable.
"Act politely and professionally" is certainly a good one. "Behave better
than my 5 year old son" is another. "Assume the other party's not a native
english speaker" is a good third.
Anyone think others are needed?
Dan
--"it's like this"---
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
Re: Critique available
At 10:42 AM 11/3/00 +, Simon Cozens wrote: >On Thu, Nov 02, 2000 at 10:14:25PM -0500, Dan Sugalski wrote: > > Not in the p5p sense, at least. Regardless of the levels of disapproval, > > generally the disapproval was voiced with at least some courtesy. p5p is > > rather less polite about things. > >I think that's what they call a "false memory". There's been one acrimonious >thread in the past six months or so. Well, things have been rather more pleasant since Tom and Ilya stopped posting much, that's for sure. I suppose it is less of a shark tank than it used to be. (Now the only thing that eats people is the actual source...) Dan ----------"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Critique available
At 04:17 PM 11/2/00 +, Simon Cozens wrote: >On Thu, Nov 02, 2000 at 11:12:50AM -0500, John Porter wrote: > > As an RFC author and persistent discutant, I always assumed that > > all/most/many of such qualified internals folks would be reading > > the perl6 lists, and would squawk when appropriate. > >On the whole, driving a spike between language and internals by giving them >separate lists was not a good idea. In some ways it was premature. In others it was a good thing. Like everything else, there were tradeoffs involved. Many of the folks who participated in -language were *not* internals folks. It wasn't their area of expertise, many of them would've been scared off by discussions of the guts, and most (generally self-admittedly) had nothing much to contribute to internals design. Leaving the lists together would've either left internals discussion out entirely (and while there wasn't much, it was there) or scared these folks off. p5p does that in a big way. (Granted the guts of perl 5 are pretty off-putting in general) We would be well-served if we could manage to merge things to some extent, certainly, but I don't think the separation's made things worse than what we would've gotten if we hadn't done that. Dan ------"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Critique available
At 06:08 PM 11/2/00 +, Simon Cozens wrote: >On Thu, Nov 02, 2000 at 11:44:50AM -0600, Jarkko Hietaniemi wrote: > > Firstly, now, for the first time in the Perl history, we opened up the > > floodgates, so the speak, and had at least some sort of (admittedly) > > weakly formalized protocol of submitting ideas for enhancement, > > instead of the shark tank known as perl5-porters. > >perl6-language was not a shark tank? Not in the p5p sense, at least. Regardless of the levels of disapproval, generally the disapproval was voiced with at least some courtesy. p5p is rather less polite about things. Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Critique available
At 10:11 AM 11/2/00 -0500, Mark-Jason Dominus wrote: >My critique of the Perl 6 RFC process and following discussion is now >available at > > http://www.perl.com/pub/2000/11/perl6rfc.html The biggest issue I have with this (and had the first time around) is the complaint about the IMPLEMENTATION section. Bluntly, I would really rather there have been none included in the language RFCs and, for the ones that had them, I rather liked Damian's "this space intentionally left blank" ones. We have no infrastructure to build on. Whinging about a lack of implementation details seems rather inappropriate. Ideas are nice, but I expect most of the recommended implementations (if we got them) would've been tossed out or wildly modified anyway, and it just annoys folks to ignore things we've asked for. Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: My reading list
At 12:49 AM 10/24/00 +0100, Simon Cozens wrote: >On Mon, Oct 23, 2000 at 04:11:34PM -0600, Nathan Torkington wrote: > >I'd just like to stoke the latent paranoia. Latent? What, there's some that *hasn't* come out yet? Damn, I bet it's too late to be afraid... Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: compile-time taint checking and the halting problem
At 09:44 AM 10/23/00 -0700, Larry Wall wrote: >David L. Nicol writes: >: Steve Fink wrote (and I edited slightly): >: >: > I can't figure out why so many people misinterpret my RFC12 >: > as requiring a solution to the halting problem. >: >: a large class of incompletely expressed >: suggestions appear to get grouped into >: >: "This requires solving the halting problem!" >: >: without providing further explanation. > >Well, in my case, I wasn't actually meaning it strictly. Sorry for the >imprecision--it's hard to squeeze everything into a talk. To me the >saying is just shorthand for "potentially sufficiently computationally >expensive that I don't want to worry about it for the default case". >In other words, I was lumping polynomial in with exponential, and RFC12 >feels polynomial to me. And it's not that I'm against the availability >of polynomial algorithms in the parser, or the use of polynomial >algorithms in general--I just think the default compile-and-run parser >should avoid them. I'm really hoping to make allowances for a variety of optional optimizations. We can save the nastier things (and with perl's active data, a lot of stuff could reasonably be classed as difficult--good optimization's going to need fairly complex flow analysis, I think) for explicit requests, possibly with different default optimization levels for parse-and-go perl and compile-to-bytecode perl. Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Transcription of Larry's talk
At 01:07 AM 10/19/00 -0500, J. David Blackstone wrote: > > On Wed, Oct 18, 2000 at 10:32:32AM -0700, Larry Wall wrote: > >> Rename the local operator? Yeah, I think we ought to do that. It > >> confuses people when we call it local(). The problem is, of course, > >> that this is not a perfect solution--they haven't come up with the > >> right name here: savetmp, tmpsave, scratchpad, etc. > > > > You're learning Japanese, right? It's gotta be "toriaezu".[1] :) > > > > [1] 'For the time being', roughly speaking. > >Do we need to add a book on Japanese to the reading list? Seems like >I'm the only one here who doesn't speak it. You're not the only one. (Though it is on my todo list... :) >[And now they're keeping the newbies locked out by doing all >development work in Japanese.] Nah. Only those newbies that don't speak Japanese. If we wanted to keep the newbies out we'd write perl 6 in INTERCAL. :-P Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: C Sharp?
At 10:30 PM 10/18/00 -0500, David Grove wrote: >Isn't C# (C Sharp) a Microsoft-owned language that is (currently) available >only on Win2k (though apparently targeted for crossplatform)? After Larry >said >he was thinking of making parts of Perl 6 in C#, Perl's not going to be written in C#. What it's probably going to do (or at least have the potential to do) is emit C# code the same way it'll be able to emit Java bytecode. Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Transcription of Larry's talk
At 10:58 AM 10/18/00 -0700, Larry Wall wrote: >Simon Cozens writes: >: You're learning Japanese, right? It's gotta be "toriaezu".[1] :) > >Yes, but if we go down that route, we're gonna end up with all the >verbs at the end. Instead of "print @foo", we get something like: > > @foo wa kaite kudasai; Sounds like a job for Lingua::Nippon. Doesn't Damian have a paper on that? Dan ------"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Transcription of Larry's talk
At 07:39 PM 10/18/00 +0100, Simon Cozens wrote: >On Wed, Oct 18, 2000 at 02:37:16PM -0400, John Porter wrote: > > http://www.mail-archive.com/perl6-language@perl.org/msg00517.html > >No, and no, and no. Of course not. That'd make perl look like Intercal, which would be silly. Since it's going to be our implementation language, there wouldn't be much point in writing perl code, now would there? :-P Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Reading list
At 03:56 AM 10/11/00 -0700, Carlos Ramirez wrote: >Here's a listing of 'recommended reading' gathered from this list >(provided by Nat). I'm not sure if this will be a permanent place for >this link, but for now you can get it here. If i left out a book or if >you have a new suggestion you can contact me or post it here and I will >add them as soon as i can. > >http://www.perldoc.com/readinglist.pl This is nicely done, and thanks. There are two things I was hoping to add to the list: short reasons as to *why* a particular book is on the p6 reading list (The ones on for distinct reasons, like Understanding Comics or Garbage Collection, I'd like differentiated from general CS texts), and categories of books so we can separate the project management from the theory from the general background texts, and suchlike. Doable? Dan ------"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Reading list
At 09:06 AM 10/12/00 -0400, Clayton Scott wrote:
>Carlos Ramirez wrote:
> >
> > Here's a listing of 'recommended reading' gathered from this list
> > (provided by Nat). I'm not sure if this will be a permanent place for
> > this link, but for now you can get it here. If i left out a book or if
> > you have a new suggestion you can contact me or post it here and I will
> > add them as soon as i can.
> >
> > http://www.perldoc.com/readinglist.pl
>
>Introduction to Algorithms
>By: Cormen, Thomas H. / Leiserson, Charles E. / Et Al. / McGraw-Hill
>ISBN: 0070131430
>
>Fatbrain says they cannot get this book but to see at ISBN 0262031418
>It seems to be the same book but has a higher price and
>(Mit Electrical Engineering and Computer Science Series) appended
>to the title.
That second ISBN is the one off the copy I got a month or so ago. Ran ~$80
US, IIRC.
Dan
--"it's like this"---
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
Re: Continued RFC process
At 04:51 PM 10/10/00 -0700, Daniel Chetlin wrote: >On Tue, Oct 10, 2000 at 08:23:07PM +0100, Nicholas Clark wrote: > > Having had cause to root around in the archives of perl6 and perl5 lists, > > can I suggest that we use the system that perl5-porters is archived on in > > preference to the system that the perl6 lists use (MHonArc, apparently). > > Personally I found the threaded summaries and search facility on the perl5 > > archive much more effective. What do other people think? > >Er, compared to what the perl6 lists are doing right now anything is >preferable. But xray _sucks_! Given the choice between searching xray >and chewing tinfoil, I might choose the tinfoil. I'm trying to get them on a regular crawl schedule at work (I work for Northern Light, one of the search engines) but that's a spotty thing at the moment. (Soon, though, I hope... :) Dan ----------"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
RE: Continued RFC process
At 09:04 PM 10/10/00 -0400, Bryan C. Warnock wrote:
> > On Mon, 9 Oct 2000, Nathan Torkington wrote:
> >
> > > Closed-for-posting mailing lists that are publically readable is the
> > > best suggestion we've had to meet these ends so far.
> > >
> > > Anyone have better suggestions?
> >
>
>Instead of group-writable and world-readable, how about group-writable
>and world-moderated?
>
>(Or just plain moderated, with the flavor o' the day being
>autohandled...)
>
>It's more work, which I am not a fan of, but I'm not a fan of everybody
>having a say, nor a select few workers having a say.
I rather like it. Russ did have a point earlier, and I'm tempted to leave
things open at the moment, or go the dual-subscription route and
automoderate everything as OK until a problem arises.
Dan
--"it's like this"---
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
RE: Continued RFC process
At 05:59 PM 10/10/00 -0500, David Grove wrote:
>On Tuesday, October 10, 2000 3:27 PM, Simon Cozens [SMTP:[EMAIL PROTECTED]]
>wrote:
> > Consider:
> > "Public Opinion": Hey, we need Perl 6 stable in three weeks.
> > Coders: But, uhm, we haven't started coding yet.
>
>Consider:
>Microsoft: We need Perl by April 15th
>Head Cheese: Ok, sure
>P5P: HuH???
>"Public Opinion": HuH???
>[Result: Perl 5.6 chaos]
No, M$ didn't have much to do with it. You can yell at Larry and Camel
deadlines if you like, but that's wrong too.
5.6 was released because it was mostly done, more stable than 5.005 for the
bits it had in common, and because of general apathy in the developer realm
for the bits that were unfinished. Like, for example, Unicode.
>No, offense, Dan. This isn't targeting you. I think you're starting to
>realize this now. At first, I think you thought I was.
No, I never thought you were. Or, more specifically, I never really gave it
much thought and didn't care if you were or not. You mistook courtesy, lack
of time, and a desire to not appear domineering for offense.
Dan
--"it's like this"---
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
RE: Now and then
At 08:50 PM 10/10/00 -0500, David Grove wrote: >Group: I have now had seventeen requests to fork perl from people other than >"elitists" apparently joking (?) about it. I haven't been. I don't think anyone else has either. It's not a joke, and it is a valid thing to do. >The answer is ABSOLUTELY NO. Stop asking. If _YOU_ fork it, don't consider >yourself any advocate of Perl or this community! The problems in this >community are not solved by secession. That's a rather absolutist and silly thing to say. Sometimes secession *is* a valid option. In some cases it's a better option. I'd far rather that someone with a profound difference in opinion of the direction of development fork and go off on their own, rather than either stay and make lots of folks (including themselves) miserable or having the community as a whole lose them. Forking isn't bad. The world's certainly not a worse place for having all the various BSD and SysV Unix forks. (Most of the commercial Unices qualify, as do the *BSDs) Neither is it a bad place for having the GCC fork not all that long ago. Dan ------"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Continued RFC process
At 06:58 PM 10/10/00 -0500, Tad McClellan wrote: >On Tue, Oct 10, 2000 at 03:42:48PM -0400, Dan Sugalski wrote: > > At 12:31 PM 10/10/00 -0700, Stephen Zander wrote: > > > >>>>> "Dan" == Dan Sugalski <[EMAIL PROTECTED]> writes: > > > Dan> A better analogy is that Larry's the Bishop and Chief > > > Dan> Architect, while the rest of us are engineers, sectional > > > Dan> architects, artisans, craftsmen, journeymen, and apprentices, > > > Dan> working to build up a cathedral. (And yes, I do mean this > > > Dan> analogy in the way you likely think I do, amongst other ways) > > > > > >Ooohh, Freemasonry comes to Perl. Can I make up the handshake? :) > > > > I was sort of hoping to go with Perl 6 Secred Decoder Rings, but a > ^ ^ > ^ ^ > > handshake'd be keen too... :-) > > >Would that be a Sacred Decoder? > >Would that be a Secret Decoder? I'm not fnord telling... :-P >Maybe it's not even a typo. > >Is it an attempt to create a new word so that you can be >enshrined in etymologies throughout the world? Argh! You're on to the master plan. Do please wave "Hi" to the Orbital Mind Control Lasers so we can take care of that little problem... :) Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Continued RFC process
At 07:09 PM 10/10/00 -0600, Nathan Torkington wrote: >Dan Sugalski writes: > > "General consensus" is best, but that can't be guaranteed. "Consensus of > > the ruling council" is more attainable, but there's that whole "ruling > > council" thing to contend with. "What Larry says" is best, but what > happens > > if he doesn't, or gets hit by a bus at some point? > >In terms of ongoing maintenance, I'd say that the teams will act as >the Ruling Council. When teams get pissed off with the release >manager, then the leader will have to go. When members of a team >can't work together, then the release manager works with them to >figure out where the problem is and fix it. This might be everything >from "play nice" to hiring a hitman :-) Works. We still have those Quantum Ninja that we're holding in reserve for Damian... :) Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Continued RFC process
At 11:12 PM 10/10/00 +0100, Simon Cozens wrote: >On Tue, Oct 10, 2000 at 06:01:16PM -0400, Dan Sugalski wrote: > > "General consensus" is best, but that can't be guaranteed. "Consensus of > > the ruling council" is more attainable, but there's that whole "ruling > > council" thing to contend with. "What Larry says" is best, but what > happens > > if he doesn't, or gets hit by a bus at some point? > >I'd be happy with "what the project manager says". We trust the project >manager to be able to gauge "general consensus" and decide what's best for >Perl. It gives us a "what Larry says" style polity without the sacred cow. > >And if the project manager goes mad (in the case of Nat, more mad :) and we >have to shoot him, then Larry should do that. And if Larry gets bussed, look >around at other open source projects and see what happens when the >maintainer's unmaintainable - people either stick it out, or fork. And that all works for me. Anyone care to RFC it? :) Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Continued RFC process
At 10:48 PM 10/10/00 +0100, Simon Cozens wrote:
>On Tue, Oct 10, 2000 at 05:40:04PM -0400, Dan Sugalski wrote:
> > You're being too specific. There is no assumption possible that perl
> > developers will do *anything*. Ever. This is a volunteer community. Any
> > other assumption you might make is unfounded.
>
>David also seems to miss the irony that the people who *can* be expected to
>work on Perl because they being paid to do so are probably employed by...
I know, I know! Compaq, right? :)
>Anyway, this is generating light. Could someone start generating heat, please?
Sure. This does bring up one important point, though it's getting lost in
everyone jumping on Dave for being a paranoid loony.
Under what circumstances, and with what procedures, do we 'officially'
remove folks from their positions? I know that I, for one, will step down
if either Nat or Larry asks, but what happens if for some reason I turn
into a raving nutter and won't go? Or if someone just disappears and we
need a new person in the position?
"General consensus" is best, but that can't be guaranteed. "Consensus of
the ruling council" is more attainable, but there's that whole "ruling
council" thing to contend with. "What Larry says" is best, but what happens
if he doesn't, or gets hit by a bus at some point?
It's not a pleasant thing to deal with, and hopefully not ever needed, but
it's better to deal with now when we don't have to than later when we do...
Dan
--"it's like this"---
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
RE: Continued RFC process
At 02:11 PM 10/10/00 -0500, David Grove wrote: >However what I was responding to was the shutting out of anyone who >doesn't agree with the politics of the perl elite, and wants to mouth off >from time to time (me). You sort of have to read between the lines on this >one, Peter, because this is an old argument. Nobody's actually saying what >they mean, and I think we prefer it that way. We don't prefer it that way, honestly. This dancing around the issue is damned annoying. Let's be blunt here. Your two big beefs seem to be that WinXX gets shorted in the development process, and that ActiveState is doing Evil Things. (That ActiveState has been responsible for 90% of the WinXX code in perl seems to not have made a difference, but we shan't go there right now) I don't much care about the latter problem--Larry feels he's resolved it and I'm fine with that. This is, as far as I'm concerned, his baby. As for the former Y'know what? That's probably not going to change. Perl lives and grows based entirely on contributions of source from the world. I don't have a Windows development system, I'm not at all familiar with developing on Windows, and I'm not *going* to develop on Windows. Period. You want Windows support? Great. Write the code and send it in. Don't like the install system? Go build one you do. I, for one, won't refuse code from anyone for personal reasons--if the code's solid (or there's no alternative) I'll take it no matter how much I might dislike someone. (Though it never helps to come across as a paranoid nutcase) I'll reject it on technical grounds, of course, but that's a separate matter. >The problem with this is the assumption. There is _no_ assumption possible >that the developers will read a free list, or care what it says. You're being too specific. There is no assumption possible that perl developers will do *anything*. Ever. This is a volunteer community. Any other assumption you might make is unfounded. There is no central authority. There is no guaranteed management control. There is no *nothing*. Perl is an open source project whose development is currently run by a group of interested parties. Don't like the way it's run? Fork the source and go for it. >Dan, I don't know you. I've never had any problem with you or your leadership. That's fine. I fully expect that someone (and this is a generic someone here--I have no names in mind) will by the time this is all done. I'm not at all thrilled at the prospect, but it's one of the first things I came to terms with after volunteering. >I don't believe that you'll head us into a mess, because I've no reason to >believe it. You are also not technopolitically inclined in the same direction >as your predecessor. I should point out two things: 1) Sarathy isn't technopolitically inclined in the way you think 2) My technopolitical leanings are likely not to your (or some other people's) tastes >I have no arguments with you. However, the possibility >still exists, and always will, unless some kind of check/balance system is in >place. What you want isn't currently possible. Period. The only way to make it even remotely possible is to entrust perl development to some sort of entity akin to the Apache Software Foundation, and if we do that we will undoubtedly piss of yet another group of people. (And you'll likely be in that group too) Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Continued RFC process
At 12:31 PM 10/10/00 -0700, Stephen Zander wrote:
> >>>>> "Dan" == Dan Sugalski <[EMAIL PROTECTED]> writes:
> Dan> A better analogy is that Larry's the Bishop and Chief
> Dan> Architect, while the rest of us are engineers, sectional
> Dan> architects, artisans, craftsmen, journeymen, and apprentices,
> Dan> working to build up a cathedral. (And yes, I do mean this
> Dan> analogy in the way you likely think I do, amongst other ways)
>
>Ooohh, Freemasonry comes to Perl. Can I make up the handshake? :)
I was sort of hoping to go with Perl 6 Secred Decoder Rings, but a
handshake'd be keen too... :-)
Dan
--"it's like this"---
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
Re: Continued RFC process
At 08:20 AM 10/10/00 -0700, Nathan Wiger wrote: >Andy Dougherty wrote: > > > > On Mon, 9 Oct 2000, Nathan Torkington wrote: > > > > > Closed-for-posting mailing lists that are publically readable is the > > > best suggestion we've had to meet these ends so far. > > > > > > Anyone have better suggestions? > > > > Just that it not be *too* hard to get on the closed lists (and, > > symmetrically, that it not be *too* hard for the list chair to bounce > > someone *off* the list if that person is judged to be persistently and > > seriously damaging to the list). > >Yep, this is my only concern. It should be reasonably easy to say "I >really want to help" and get on the closed lists. Perhaps the best way >of making sure the lists don't bloat into "everyone has an opinion" >lists is to require that *all* members contribute code to that list's >purpose. If you're on the list, you _must_ program. So, if you really >want to help with async i/o, that's fine, join -internals-io, but be >aware that if you aren't actively contributing code you'll be dropped. I'd rather not limit the subscriptions to people that are coding. We need as many folks with good design skills as we can muster, and I'd rather not require them to also submit code. The two skills (coding and designing) are separate ones--good coders can (and often are) lousy designers, while good designers aren't necessarily good coders. Good design skills are also significantly scarcer than good coding skills. I also don't want to lose the folks with experience in an area just because they don't have time to do code either. Someone like Graham, Tim, or Alan might well be able to drop a mail message or six in between other things while still not having the time (or interest) to sit down and actually write a chunk of code. That pretty much leaves us with "wing it" as a methodology, but that's probably OK for now. Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Continued RFC process
At 09:31 AM 10/10/00 -0600, John Barnette wrote: >D'you think it's a possibility to provide read-only access to the lists >for interested parties? I'm certainly not competent enough to contribute >to a core discussion, for example, but I have no doubt that my eventual >Perl6 facility would be greatly increased by observing the dialogue. Read-only access is a must for any list like this, and with more than just a web archive. I'm sure Ask will set things up so anyone that likes can subscribe to the read-only version of the list. Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Continued RFC process
At 10:36 PM 10/9/00 -0500, J. David Blackstone wrote:
> > J. David Blackstone wrote:
> >>
> >> When they drafted the U.S. constitution, there was
> >> a huge debate over whether to base congressional representation on
> >> population per state or make each state equal. Both sides had a good
> >> claim to the other being unfair; giving a smaller state (Rhode Island,
> >> or Mac users) equal say with a larger one can seem unfair to the
> >> larger segment, and I think in this case it would be. ("No,
> >> seriously, guys, I think we should move the epoch to 1904.")
> >
> > I agree with jdb. One equivalent vote per person opens the possibility
> > that some company in Redmond could assign 250 of its employees to
> > "go vote in that Perl thing and make it ours".
>
> Ouch. Didn't even think of that.
Or, just as bad, the vote hits slashdot and we have a half-zillion frothing
slashdotties descend on us and either vote their bigotries on us or just
screw around for fun.
> > Also, I'd point out a weakness in the presidential analogy for Larry.
> > The President of the U.S. can only veto; any legislation he ignores
> > passes by default. Also, the President cannot introduce legislation.
> > Rather, Larry is like a king; and we are his ministers, courtiers, and
> > noblemen. We can argue til we're blue, debate, resolve, and vote; but
> > in the end, it's Larry who makes the decision.
>
> Yes, although Larry is kind of like a king after the signing of the
>Magna Carta. There's no divine right, here; if Larry decides we're
>going to eliminate dollar signs for scalars and optimize the core for
>a C module, most of us will jump ship. (Though not
>without tears of regret.)
I'll point out a bigger failing in the analogy. The US isn't a democracy,
none of the states are (except for the odd dabbling in, usually badly, it
with ballot initiatives), and very few municipalities are.
A better analogy is that Larry's the Bishop and Chief Architect, while the
rest of us are engineers, sectional architects, artisans, craftsmen,
journeymen, and apprentices, working to build up a cathedral. (And yes, I
do mean this analogy in the way you likely think I do, amongst other ways)
Regardless, a "design decision by majority vote" just isn't going to fly in
a mostly-volunteer effort, and it rarely does in a commercial effort.
(Whether it results in a working system is a separate matter) If you need
an example, we have Unicode staring us straight in the face. It was put on
the table both out of general need and directly to serve a large part of
the perl userbase (i.e. Windows), and look how far it got us. Heck, 5.6 was
released as tatty as it was *because* people weren't working on the things
that were unfinished.
If a proposal is put forth to handle personnel issues via some sort of
community decision, that's great. If it gets Larry's approval I'm all for
it and will follow the decisions it makes. (Even if, or especially if, the
result is I take my leave) The one thing we should *not* do, though, is
make design decisions by vote. It's worse than decisions via committee--at
least those have some hope of being technically sound.
Dan
--"it's like this"---
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
Re: Continued RFC process
At 06:38 PM 10/8/00 -0400, Uri Guttman wrote: >the second part is internals. not to take anything from dan, but i see a >bottom up approach being very useful here. I disagree. This is too big a project to manage that way. If we do it we're setting ourselves up for an enormous amount of trouble later on. (And not that much later at that) The various pieces *must* have well-defined interfaces and behaviours, and that absolutely has to be specified before work begins on any particular piece. >hammer out some >working/prototype vtable code, work on the new I/O subsystems (this is a >big project in its own right), work on byte code and related design >issues, etc. again, these teams should be led and staffed by people with >real experience in those areas. this should not be a public exercise >(again read only should apply to any outsiders). Sure, as long as the behaviours of the individual pieces are known when work starts. Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Continued RFC process
At 04:13 PM 10/8/00 -0600, Nathan Torkington wrote: >I've heard people asking for RFCs to continue after the brainstorming. >What do we want to do that we need RFCs for? Design? Implementation? >Working out the fine details of behaviour? What I'd like to see is the internals design and implementation use RFCs as the specifications and documentation for the different pieces of the guts. I'm not sure the free-for-all way we handled things to start is appropriate (I'm rather sure it's *not*), but that's OK, since the requirements are different. Much as folks might dislike it, I think some sort of prefilter is in order for RFCs if we continue that way. (We'll be doing *something* of the sort on the internals side) RFCs should have at least some solidity before they hit the standards track. Feasable would be nice, but if someone wants to present an alternative to the current implementation of something (vtables, variables, interpreter structure) that's fine--we may need a Plan B at some point. Or Plan C, since I suppose we're working on Plan B now. The separate sub-lists are definitely a useful tool in some circumstances, and I'd like to see those used as well. The internals encompasses a lot of area, and having separate lists should make life an awful lot easier. (Whether this ultimately proves to be true is a separate issue) The folks designing the bytecode don't, for example, need to interact a whole lot with the folks designing the garbage collection code. All this might just be an internals-only issue, and if that's the case then I'm fine with that. If it's not, though, it seems to make sense to coordinate things project-wide. Dan ------"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Update on the RFC Process
At 04:26 PM 10/3/00 -0400, Adam Turoff wrote:
>On Tue, Oct 03, 2000 at 08:50:24AM -0600, Nathan Torkington wrote:
> > Bradley M. Kuhn writes:
> > > It seems to me that the perl6-internals, perl6-qa, and perl6-licenses
> groups
> > > should be able to produce additional RFCs after this. Of course, the
> > > Language will be frozen, but these three groups may need to remain fluid
> > > after the 14 October 2000 annoucement.
> >
> > I think perl6-licenses should start to move towards a decision after
> > the 14th. Find something that there's a rough consensus for, write up
> > the pro-s and con-s, then give it to Larry.
>
>What about pending -licenses RFCs? Bradley has made a very good
>point that -licenses (and -qa?) aren't directly impacted by the
>language design and should be immune from the moritorium.
I'd personally like a license chosen before any code gets written in
earnest, so that might well argue for -license to wrap up before then.
(Whether this is an issue or not is up in the air--it depends on who's
submitting code)
Dan
--"it's like this"---
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
Re: Update on the RFC Process
At 04:13 PM 10/3/00 +0100, Simon Cozens wrote: >On Tue, Oct 03, 2000 at 04:06:00PM +0100, Piers Cawley wrote: > > Personally I'm betting that the volume we've seen on -language will > > pale into tiny insignificance compared to the volume on -internals > > once Larry has made his announcement. > >I doubt it; I think we've a lot of people who want to talk about how >Perl should be. I don't think we'll have *that* many people when it >comes to actually trying to implement those ideas. I'm with Simon on this. The set of people with the skills and time to design or implement the core is significantly smaller than the set of folks who think they can redesign some (or all) of the language. The discussion's also likely to be more focused and less grumpy. I hope... :) If we look at p5p, most of the traffic at any one time revolves around design issues, not implementation. (Barring the runup to a release, when the volume's more in OK/NOK messages) I expect the same will be true for us, though I expect the volume of internals design traffic to be smaller than that for language design. Dan ------"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: *REALLY*, it's getting close here...
At 07:56 PM 9/28/00 -0700, Daniel Chetlin wrote: >On Fri, Sep 29, 2000 at 12:56:44AM +0100, Simon Cozens wrote: > > Why isn't there a documentation w/g? Yes, this is a hint. > >My RFC 240 garnered exactly 0 responses, so there doesn't seem to be >much of an interest. I was trying to decide today whether I should >freeze or withdraw. It probably either got lost in the shuffle of RFCs, or the folks who'd deal with it have been too busy to notice. The mass of language morphing RFCs have really started to get to people. (Okay, they started a while ago...) I'm not sure the method you propose in the RFC's a good way to go--it would probably be better to start from scratch and use the experience we've gained with the current doc set to redesign the documentation. It really desperately needs reordering and its divisions changed. Dan ----------"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: RFC - Prototype RFC Implementations - Seperating the men from the boys.
At 05:30 PM 9/11/00 -0400, Chaim Frenkel wrote: >Up until that point, it is wasted energy. At this point, without code >there is nothing locked down, no cost in changing. (Yes, even though >they are bits, changing software, changing architecture has major >costs.) Don't forget that changing architecture has costs, even without code backing it yet. There's still the mental costs of refiguring how it all fits together. (And it does all need to fit together--if the mental model's a kludged up hack, the implementation will be too) This isn't to argue against making changes and reworking things, mind. Just pointing out that all changes have a cost. Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Can perforce gateway to CVS without loss of metadata? (was Re: code repository)
At 11:30 AM 9/8/00 -0400, Bradley M. Kuhn wrote: >Adam Turoff wrote: > > > *: Sarathy tells me that Perforce sucks at maintaining thousands of > > anonymous checkouts, while CVS doesn't mind at all. This is a perfect > > reason to use anon CVS vs. Perforce, but does not require that Perforce be > > ditched in favor of CVS, only that an anon CVS gateway be maintained. > >Will this anonymous gateway have all the relevant meta-data? Will it look, >to a user of the gateway, like the live repository is CVS when they go >hunting through metadata? I don't think there can be a one-to-one mapping--perforce changes may affect multiple files, while CVS changes don't. That'll end up with a single checkin to perforce looking like multiple CVS checkins. Probably not a big deal, since the real problem would be going the other way. Dan ------"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: code repository
At 10:24 AM 9/8/00 -0400, Bennett Todd wrote:
>2000-09-07-19:50:35 Adam Turoff:
> > > Given that it's only available to people who happen to run supported
> > > platforms,
> >
> > OK. That pegged the fud-o-meter. The list of supported platforms
> > listed on http://www.perforce.com/perforce/loadprog.html is hovering
> > around fifty, [...]
>
>Sure hope it includes every platform that anyone who should be a
>checkin-permitted core developer would want to use, including any
>new ones that emerge between now and then (noting that things like
>new versions of system libraries make new platforms as far as
>binary-only commercial software is concerned). This pretty much
>implies that, as long as perl6 lasts, the company supporting
>perforce must remain in business and remain friendly. They own the
>code, and we can't support it.
As opposed to what, CVS? Right now if I want to make any sort of meaningful
checkin with CVS I need to ftp the changes over to a linux box because the
VMS client sucks so badly. (It's unbuildable without serious assault last
time I checked, so I'm stuck with a prebuilt binary) And I can imagine how
much fun it must be to get it building on a Cray or OS/390 machine running CMS.
No matter what we choose we're going to come up short.
Dan
--"it's like this"---
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
Re: code repository
At 10:48 PM 9/7/00 -0600, Nathan Torkington wrote: >But I am cool to the idea that we should lose good coders to >potentially bad ideas. Explore those ideas later, get perl6 working >first. Unfortunately we're going to lose good coders regardless of what we do. Any significant decision's going to annoy someone (even the decision making process is going to piss someone off because it's going to rub someone the wrong way) Being able to cope with that gracefully and diplomatically may be the toughest part of perl 6's development. Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: code repository
Bennett, Perforce is a better source code control system than the source alternatives, and certainly better for the task we face than CVS. You're certainly not forced to use it. You can, if you rather, grab snapshot archives, rsync from the repository directory, or even grab a copy of the source from the proposed anon CVS mirror. If you've got a better alternative with a proven track record (and the only alternatives I know of that rival it all cost) put it on the table, please. Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: code repository
At 11:49 AM 9/7/00 -0400, Bennett Todd wrote: >2000-09-06-10:51:35 Dan Sugalski: > > >Finally, most free software and open source projects have > > >standardized on CVS. Do we really have a compelling reason to go > > >against the standard? > > > > Perl 5 uses perforce, [...] > >I thought one of the primary motivations for this investment of time >and effort here on the perl6-* lists was the problem that far too >few people can contribute to perl5 development. Perl 5's development issues have nothing to do with the code repository--given how many branches are active, perforce seems to be a win. The problems perl 5 has are almost entirely due to a code base that has reached past the end of its useful life. Perl 6 development is open to anyone with perl source, a text editor, a compiler and a copy of diff. (And for good code I'll generate the fscking diffs myself if I can get a copy of the changed source) *Nobody* needs *any* repository tools to play this game. Period. Dan ------"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: code repository
At 12:14 AM 9/6/00 -0400, Bradley M. Kuhn wrote: >Dan Sugalski wrote: > > The decisions should be based on technical merit and general availability. > >I would include "available under a free software license" as part of the >definition of "general availability". You would, but in this case I don't. We can give anyone we want a client and get them access to the repository. >For example, perforce doesn't ship standard with operating system >distributions such as Red Hat, Debian, and FreeBSD, because it isn't under a >free software license. However, CVS does ship with those systems. So? CVS is still inferior, and there are a *lot* of other operating systems in the world. Having to go fetch one program to check things in really isn't a hardship. >Also, what if people want to learn how the source system works on their own, >and experiment with it? They can go do it on a test repository they set up on a scratch machine. I'd rather people not play with the p6 repository honestly--we're going to have enough problems of our own. >With only 100-user license, we are pretty tight as >to who can do that. There are probably more than 100 people on the various >perl6 mailing lists who'd want to at least experiment with the system on >their own. Anyone who wants it can get a 2-user license to perforce to set up and run wherever, which is just dandy. (And I don't want the perl repository being a test anyway) Ask can always get more licenses if he needs, so the 99-user current limit (I's like one of the licenses dedicated to anonymous read-only access) isn't a big deal. >On another point, developers typically want to run checked-out versions of >the software if they are actively participating. I have always been sad I >was unable to do this with perl5, even though I wasn't an active developer. Huh? You've always been able to. The development tree (or one version of it) has always been available from activestate, and a perforce ID or anonymous access has been available for the asking. >I would hate to see perl6 development go the same route. The code would >remain much more public and accessible if it were available via anonymous >CVS. Isn't that something we want? There were plans to set up a read-only CVS mirror last I knew, and I don't think that's changed. The perl 5 tree's available via FTP and rsync, and I don't see any reason to change that for perl 6. And, honestly, if the effort >One might argue that we can use a "snapshot" system can solve this problem. >In my experience, The "snapshot" system can be quite inconvenient, for both >those submitting patches and those accepting them. It just doesn't beat >anonymous CVS access. That's fine. We set up anonymous perforce access, or people can use the CVS mirror. Either way it doesn't matter, since I feel strongly that we should be accommodating people working from a point-release version *anyway*. Compared to that, snapshots or anonymous repository access is easy going. >Finally, most free software and open source projects have standardized on >CVS. Do we really have a compelling reason to go against the standard? Perl 5 uses perforce, and perforce is a lot nicer. I don't much care what the other projects use--that's largely irrelevanyt, and in many ways a misleading argument. (It's the same sort of argument that pushes MySQL as a database since "most folks are using it", regarless of its inadequacy for a task) Perforce is much nicer for the people who need to manage the repository, and that's the important thing. We can get easy-enough access to the repository for the casual hacker and that's fine. Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Proposed RFC for matrix indexing and slicing
At 08:28 PM 8/31/00 -0700, Nathan Wiger wrote: >Larry Wall wrote: > > > > More generally, for all X, I wouldn't mind > > if Perl became the language of choice for X. > >Who wouldn't! > >But I think that would probably have to be, "if Perl became the language >of choice for X - 1". > >Perl's gotta be written in something, after all... ;-) Other than the bootstrap issue and the speed issue, what's wrong with that? I'd rather write a parser in perl than pretty much anything else. (Well, OK, maybe SNOBOL, but...) Most C compilers are written in C, and if we can get perl emitting native code... Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: code repository
At 09:29 AM 9/4/00 -0400, Bradley M. Kuhn wrote: >Ask Bjoern Hansen wrote: > > > the perl-qa people have some code they need to manage in a repository of > > some kind. For now I have directed them to SourceForge, but I have a 100 > > users license for perforce I got for perl, so if we can get a quick > > consensus that we might want to make a perl6 code infrastructure around > > perforce then I'll go ahead and set it up. > >I would like to vote against perforce, because it is not free (as in >freedom) software, and CVS is. > >I don't think it's a good idea to build Perl6 development infrastructure >around non-free software. I don't think we should make decisions about the software we use for development based on political views. The decisions should be based on technical merit and general availability. >On a personal note, I would not be able to participate in Perl6 development >if doing so required that I use perforce, because I have personal ethical >beliefs that prohibit me from using free software. I may not be the only >one. The only requirements for perl 6 development above and beyond normal perl building should be a unix-style diff creator. All the rest is a goodie, but shouldn't be necessary. >I realize that perforce has possible technical benefits, but I think it's >better to (a) stick with CVS or (b) wait for Simon's perforce-on-CVS hack or >(c) start with CVS, and add Simon's hack when it's available. I'd rather not bet the development farm on any untested software. (Well, besides perl 6... :) This isn't any judgement on Simon's abilities, I just don't want to be debugging (and possibly regularly rebuilding) the source repository at the same time we're trying to figure out where we whacked perl. One wildly variable variable at a time, please... :) Perforce is nice, works very well, is liked by a lot of folks doing perl development now, and generally meets our needs. I don't see any reason why we shouldn't use it. Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
