On 6/14/05, Larry Wall <[EMAIL PROTECTED]> wrote: > Heh, that classification was a fast guess about RFCs made more than > 4 years ago. I'm amazed it's stood up as well as it has, even where > it hasn't.
I agree, and lacking anything I could find more recent, initially thought it was the right way to go. > I think at this point we should assume that any RFCs that haven't > been officially blessed should be considered officially suspect, > and prior art (Perl 5) should generally take precedence unless we > decide otherwise. If something seems too good to leave out, we can > talk about it here. There is another question at the Monastery entitled "What's in Perl 6?" asking specifically which RFCs have been accepted, rejected, and of course the ones somewhere in the middle. about http://perlmonks.org/index.pl?node_id=96184 The written Apocolypses answered that question for the applicable RFCs but there are two problems. The first is that we are now primarily focusing on Synopses. The second is that it is hard to frame synopses without the knowledge of which RFCs are in what state. > > That being said, it's pretty clear that there are some things that > are suboptimal about Perl 5's pack/unpack. My primary focus here is on the design documents. I believe that it will be easier to focus on what is left my having a means to measure. Using the analogy of a house, once the frame is up it is easy to walk in and see that the master bedroom is finished while the kitchen hasn't been started. I believe it will be easier to point people to reference material then it is to rehash questions repeatedly on the list. I believe it will be easier for someone to modify documentation if an organized framework tells them where it needs to go. I freely admit I may be living in the clouds and my well intentioned idea is good in theory but hard to do in reality. If you, or anyone else, can see a clear way to move forward for those outside of the cabal to help - we would certainly appreciate it. > Not really, except insofar as we've talked about compact classes of > native types working like C structs. There are lots of nitty things > we can fix with pack/unpack, but the basic underlying problem is > that pack/unpack are defined operationally rather than declaratively. Sorry, perhaps I should have been more clear. This was a general question with regards to the design documents and not specifically with pack/unpack. So is there anything those of us not in @larry can do to help out with the design documents and specifically where can we go to get reference material? > Larry > As a side note, the only thing I would like to see in pack/unpack is a way to make the following task easier: You have to read records in the following way: 2 bytes = what type of record you have 3 bytes = how long the record value is ? bytes = value of record which is determined by previous read In p5, you need to keep track of your offset and skip that number of bytes each time. It would be nice if p6 could somehow make that easier. Again, my focus is on the design docs and not on pack/unpack. I just used it as a discussion point since it is what I was working on at the time. Joshua Gatcomb a.k.a. L~R
