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

Reply via email to