On Tue, Jun 14, 2005 at 09:38:43AM -0400, Joshua Gatcomb wrote:
: On 6/13/05, Patrick R. Michaud <[EMAIL PROTECTED]> wrote:
:
: > Since it might not have been clear from my earlier post -- I've
: > now committed the S17 framework draft into the repository. Thanks.
:
: I am now questioning using "Perl6 Timeline By Apocolypse" as reference
: material.
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 am rather interested in seeing the specs for pack/unpack
: so I went about finding where it should go:
:
: There are 2 RFCs listed for A09 for pack/unpack
: 142 Enhanced Pack/Unpack
: 247 pack/unpack C-like enhancements
:
: There is an RFC for A13 regarding distinguishing packed data
: 258 Distinguish packed data from printable strings
:
: The rest of the RFCs for pack/unpack fall into A29
: 246 pack/unpack uncontrovercial enhancements
: 248 enhanced groups in pack/unpack
: 249 Use pack/unpack for marshalling
: 250 hooks in pack/unpack
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.
That being said, it's pretty clear that there are some things that
are suboptimal about Perl 5's pack/unpack.
: Now S09 and S13 have already been written but do not include the
: details regarding pack/unpack.
:
: The patch to S29 is obvious - just add a heading for pack/unpack and
: hope someone fills in the blanks.
:
: The patch for S13 is more difficult since I don't believe it warrants
: a full heading. Probably just needs a guess as to how to expose the
: flag to return a bool value i.e. $string.packed, comment about the
: 'packed' warnings/strictures pragma, and stick it the "right" place.
:
: The patch to S09 has me stumped.
:
: Is there any other reference material I can use to put together solid
: frameworks that are closely representative to what @larry might
: produce?
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.
As a kind of funny bytecode for serializing operations, it's rather
powerful, but you'll notice that C gets by without such operationally
defined structs.
So I think that what we're going to end up with is a pack/unpack engine
not so different from what we have, but it will very rarely be used
directly. Rather, any compact class can automatically serialize/deserialize
automatically, but can also be asked for its pack pattern for explicit
control of pack/unpack when you want that.
At the same time, I think the pack/unpack bytecode is not necessarily
the final compiled form, since many of them could be "jitted" to PASM
code that doesn't need to be interpreted by a pack/unpack engine,
but handled directly by the VM, and maybe even jitted down to real
machine code. That implies that either we modify the pack/unpack
interface to allow explicitly produced compiled objects via MMD:
@foo = unpack(packcomp("H*"), $string)
or we rely on caching of the compiled pack program with the supplied string.
@foo = unpack($pk, $string); # recompiled only if $pk changes
Arguably the latter is more user friendly, and doesn't commit to
the compiled form if it turns out to actually be more efficient to
interpret the pack bytecode directly. And we already presumably do
that sort of caching for strings interpreted as rules.
Larry
