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
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? Is there any action on the api lists that I'm not seeing? If not, I'd say we've got the cart before the horse.
Re: Guidelines for internals proposals and documentation
"David Grove" [EMAIL PROTECTED] wrote : 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. This is precisely why I proposed the BS level just below Development. In fact I'm going to write the MailMan make-a-list page right now or by monday. Maybe the somewheretostart :) is with design tools to build attributes and connectors for the components and then display them nightly w/ a graph representation of the whole complex structure. My second desire is to build perl6 purely w/ perl tools/servers, and then wholly with perl6 as soon as it can stand on its own. That way if there are any problems the core team would be the first to know about it ;) John
Re: Guidelines for internals proposals and documentation
Using the IBM article that Jarkko found as an example, core implementations of different languages may have more in common with each other than implemetations of the same language, I think PPC is actually significant enough so that it should not be painted into a perl-only corner. Seeing that the majority of the debate or confusion in PCC is at the germination level, I am proposing a more nebulous level... BS ( for brain storming ) which would precede development. It would be open enough to allow any developer (perl or no) to contirubute while hopefully spinning off the perl component into their own lang's direction. An example for this would be what I learned at the NYPC/LinuxSociety demo last night. In the 2.4 compile, you now use "make xconfigure" rather than "make configure". Its a TK app that makes the process more fun than work and it should be ported to every configure esp perl. On our side, there is notion in of eliminating "make" (a good idea IMHO) by updating the cons modules. It would then be a piece of cake for anyone on these lists to bring these two together, where the PPC would guide the feature set... (I'm just wondering how to do this in HTML/CPANTS ;) Anyone who wants can start a BS list w/ GNU/Mailman on http://puny.vm.com just email me an I will make a link;) John
Re: Guidelines for internals proposals and documentation
On Wed, Nov 15, 2000 at 04:20:58PM -0500, Dan Sugalski wrote: 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. There are many people who have good taste and experience where the Perl API is concerned. Forcing those people to come to a majority vote on every PDD isn't going to fly. The answer isn't to reduce that set of people to one person; Larry doesn't scale exponentially. 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) There are only a small number of people who can bless/unbless a PDD into a standard or forcibly withdraw it from consideration. It's good that there's a small number (1) is involved, but it's bad that each of those people can singlehandedly bless/unbless something. From p5p, we saw that if 2 or 3 people objected to a proposal/idea/patch, it was probably flawed in some way. OTOH, if 3 or 4 of those same people saw merit in a proposal/idea/patch, then it was probably worthy of consideration[*]. This is one of the ways where p5p worked well (and where the RFC process failed). We should formalize this for the Perl6 API process. The first order of business should be to determine the process by which PDDs become accepted/rejected/mentored/etc. Next, we find the people with good taste and spare tuits to accept/reject/mentor proposals through the process. Z. *: This is the audience-participation variant of "throw it at the pumpking and see if he accepts it."
Re: Guidelines for internals proposals and documentation
Nat and I argued parts of this (I think this is included) at some length. Actually, I think I drove him crazy getting specifics out of this. Adam Turoff [EMAIL PROTECTED] wrote: On Tue, Nov 14, 2000 at 05:59:40PM -0500, Dan Sugalski wrote: 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. This doesn't sound right. I'm still waiting to find out whether a group will be submitting a) a single PDD, b) multiple PDD's, or c) multiple PDD's merged into a single PDD. case pdd a) this makes sense as stated, I think b) this makes no sense submitters would control their own PDD's except only leader could stamp accepted c) submitters would control their own PDD's except only leader could stamp PDD accepted and only leader could stamp master PDD anything esac Okay, my bash is a bit off, but you get the idea. If anyone is interested, I think that within groups, b or c sounds like a logical approach to solving the problems at hand, since each person would likely have a very very very specific problem area in mind. Method a sounds a bit like a ... hmmm ... cluster-Muck, with everybody trying to come up with bits and pieces of the same document rather than coming up with ideas that end up in a single (or multiple) PDD to be submitted even higher outside the working group. I'm thinking project management terms here. 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. FWIU, "Developing" would be after an initial proposal, and means it wasn't tossed out at the first mention of it. It makes sense that it's a status of its own. The RFC process accidentally required single-authorship for all RFCs. We should allow RFCs to be maintained by a group of collaborating authors (without forcing them to start a mailing list first). Any of these authors should be able to make updates and update the status as appropriate (e.g. Developing, Withdrawn, Superceded). I think this is similar to what I'm suggesting with my a-b-c's above. I do agree that single-authorship would be a management problem. But then, multiple management could cause tangenting, but (according to EFNet #perl) there's nothing wrong with discussing winnie the pooh from time to time when burnout sets in. ;-)) Maybe sub PDD's (SPDDs) can be conceived of as "discussion", but I think that perhaps in groups with big jobs, actual proposals about how minutiae might be accompilshed could help set ideas in stone more than just discussion, then discussion could have its proper place. If SPDD's are used, it would be the responsibility of a team leader to collect the ideas and come up with a main one that everyone needed to agree on, which should be a simple diplomatic process and less overall work for the team leader himself, and more thoughtful (full of thoughtoutedness) effort from the team members. This is a community process. I'm uncomfortable leaving such decisions to such a small number of people. How about nominating/electing a core team that will be responsible for the API design, whereby a vote of 3/10 is needed to reject a PDD and a vote of 5/10 is needed to accept a PDD? (The numbers 3, 5 and 10 are arbitrary, and used to demonstrate that this doesn't need to degenerate into review by committee.) This is where Nat and I, I think, had a hurdle, and is the reason for my reponse to this email. The concern that was expressed was the development of the interests of a small group overriding the interests of the whole, the creation of another perl-elite caste, etc. Nate, correct me if I have it wrong PLEASE... It is, within a single group, the responsibility of the team leader to moderate discussion and lead the team to a unanymous decision. Within the 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 (I proposed that), and I'm agreeing to the reasons for it... it's potentially caste-building (that wasn't the reason, but I have my own reason too). Since one team would not be familiar with issues within another group, it would be a tremendous thing to ask of a "core team" to decide on all PDD's including both their own and ones they aren't directly working with. All in all, I think Dan's doing a good job making this make sense. I'm just curious about the inner workings of a group.
Re: Guidelines for internals proposals and documentation
On Wed, Nov 15, 2000 at 11:35:56AM -0500, Adam Turoff wrote: On Tue, Nov 14, 2000 at 05:59:40PM -0500, Dan Sugalski wrote: 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. This doesn't sound right. 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" 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? Nicholas Clark
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
