"RFC": re [un]pack()

[Michele Dondi]

To be fair I had the idea I'm about to expose while developing a new
japh of mine (the one about which I'm talking in my other post),
though I think that this may be useful in "production" code too...

Coming to the point, it often happens to resort to "cascaded"
[un]pack()s. In my specific case I have

$coded=pack 'u', pack 'w', $something;

and respectively

$something=unpack 'w', unpack 'u', $coded;

but even longer combinations are possible/common. Now I understand
that this stresses the natural order in which transformations are
applied, though I wonder if templates could be cascaded instead, by
means of a new metacharachter, e.g. C<:>, a la

$coded=pack 'u:w', $something; # Or perhaps 'w:u'
$something=unpack 'w:u', $coded; # 'u:w'?

Should this be considered too error-prone or undesirable for any
reason, disambiguation may come from supplying "cascaded" parameters
by means of a different data type, a la

$coded=pack ['u', 'w'], $something; # Or perhaps 'w:u'
$coded=unpack ['w', 'u'], $something; # 'u:w'?

Any thought?


Michele

 

[Michele Dondi]

Coming to the point, it often happens to resort to "cascaded"
[un]pack()s. In my specific case I have

[snip]

Any cmt on this?!?


Michele

 

[Anno Siegel]

Coming to the point, it often happens to resort to "cascaded"
[un]pack()s. In my specific case I have

[snip]

Any cmt on this?!?

Well, if I must...

I have occasionally used a sequence of pack and unpack in a single
statement (can't remember triple ones), so I don't see much need for
your syntax extension.

pack and unpack suffer from obscurity, not from a lack of flexibility.
If anything is wanting it's a means to identify which parts of one
template interact with which parts of the other. I don't see your
extension helping much, in fact it makes it natural to put them all
on one line. Some kind of column formatting (do-able with explicit
pack/unpack) is a better approach.

Anno

 

[Brian McCauley]

Coming to the point, it often happens to resort to "cascaded"
[un]pack()s. In my specific case I have

I have occasionally used a sequence of pack and unpack in a single
statement (can't remember triple ones), so I don't see much need for
your syntax extension.

[snip more stuff]

I concur completely with Anno.

 

[Michele Dondi]

pack and unpack suffer from obscurity, not from a lack of flexibility.

I totally agree with you. I find that these two functions are
incredibly powerful and useful, but every time I need them I have to
read the docs two or three times and despite of this generally I still
have to find the correct template by trial and error!

If anything is wanting it's a means to identify which parts of one
template interact with which parts of the other. I don't see your
extension helping much, in fact it makes it natural to put them all
on one line. Some kind of column formatting (do-able with explicit
pack/unpack) is a better approach.

I see... though, as of the *second* suggestion (i.e. by means of, say,
an arrayref) I gave, the extended syntax wouldn't *necessarily*
enforce the all-on-one-line style:

my $packed = pack [ qw/template1
template2
template3/ ], @data;


However, taking into account your, and Brian McCauley's, knowledgeable
opinion, I think I won't bother anymore!


Michele

 

[Anno Siegel]

I totally agree with you. I find that these two functions are
incredibly powerful and useful, but every time I need them I have to
read the docs two or three times and despite of this generally I still
have to find the correct template by trial and error!

I think that's how most people work with them. It is good to know
they're around, and to have a general idea what you can do with them.
If you actually need something, look it up.

[...]

However, taking into account your, and Brian McCauley's, knowledgeable
opinion, I think I won't bother anymore!

Then again, as Paul Graham said in his essay _Great Hackers_, "The
key to being a good hacker may be to work on what you like."

From a Perl perspective, I'd like to add "...and the wisdom to choose
what to publish on the CPAN"

Anno

 

[Ilya Zakharevich]

[A complimentary Cc of this posting was sent to
Michele Dondi

To be fair I had the idea I'm about to expose while developing a new
japh of mine (the one about which I'm talking in my other post),
though I think that this may be useful in "production" code too...

Coming to the point, it often happens to resort to "cascaded"
[un]pack()s. In my specific case I have

$coded=pack 'u', pack 'w', $something;

and respectively

$something=unpack 'w', unpack 'u', $coded;

but even longer combinations are possible/common. Now I understand
that this stresses the natural order in which transformations are
applied, though I wonder if templates could be cascaded instead, by
means of a new metacharachter, e.g. C<:>, a la

$coded=pack 'u:w', $something; # Or perhaps 'w:u'

My opinion on this construct is very contrary to what other posters
suggest. Actually, this construct is a part of my pack()-megapatch of
a couple of years ago.

[Just to remind the history: this megapatch should have consisted of
7 parts, I actually debugged and submitted to p5p only 5 parts of
it; I eventually stopped since only the first two parts were
included anyway.]

This construct is absolutely analogues to the '/' operator of
(un)pack(), the only difference is that one of unpacked values is used
as a target of daughter unpack(), not as a count for the daughter
unpack(). (Similarly for pack().) So in my patch it would be sitting
on // operator:

unpack "... v/a* // (v*) ..."

will unpack the substructure "length in bytes, followed by an array of
integers of this length". Note the similarity with

unpack "... v / v* ..."

used when the count is in number of integers, not bytes.

The reasons why (IMO) the approach of doing this programmatically is
viable for very simple examples only:

a) it breaks the symmetry between pack()/unpack(): when done
programmatically, one must (obviously) use different code for
pack()ing and unpack()ing; in addition to increased probability
of having bugs, these two pieces of code can easily go out of
sync.

b) This construct is *very* widespread; it is easy to do
programmatically for very simple examples only; with more
complicated packed sturctures it may take quite some effort to
find *which* entries one needs to apply the second (un)pack().

c) (un)pack() is one of the few pieces of functional-programming
sublanguage of Perl (RExes are another one). Moving more
processing inside (un)pack() replaces CODE by DATA.

[Now, when my patches added the ability of comments and
structure inside (un)pack() templates], such a move means a
major simplification of code. For complicated tasks, this may
mean significant reduction of design/debugging time.

Hope this helps,
Ilya

 

[Michele Dondi]

[A complimentary Cc of this posting was sent to
Michele Dondi
<[email protected]>], who wrote in article <[email protected]>:

Please, don't!

Coming to the point, it often happens to resort to "cascaded"
[un]pack()s. In my specific case I have

My opinion on this construct is very contrary to what other posters
suggest. Actually, this construct is a part of my pack()-megapatch of
a couple of years ago.

Dear Ilya, I must say that at first your post seemed so much above the
top of my head that it took me some effort even to understand wether
after all you were agreeing or disagreeing with me! ;-)

So it seems that, unlike me and the other poster who responded, you
are *not* the kind of guy who finds [un]pack()'s "correct" patterns by
trial and error...

However, now that I've read it carefully a few times (and I'm ready to
read it again a few more!) I must say that I find it both interesting
and valuable.

As a side note, even if I've never had any training on specific
functional languages (apart a minimal amount of exposure to sml), it
seems that personally I have, say, an inclination at least for some
typical contructs of them. In this sense you may find interesting a
discussion held on the p6l mailing list that started with a message of
mine on a topic (loosely) related to that of this thread. I may give
you some reference if interested...


Misha