Re: ... as a term
Larry Wall <[EMAIL PROTECTED]> writes:
> If you're into dwimmery, you could make all of these work, too:
>
> print (1, 2, 4, ...)
> print (1, 4, 9, 16, 25, ...)
> print (1, 1, 2, 3, 5, ...)
> print ('a', 'b', 'c', ...)
> print (3, 1, 4, 1, 5, 9, 6, 2, 5, ...)
You forgot:
print (1, 11, 21, 1211, ...)
Re: ... as a term
Numerical python uses "..." in the same sense for axis
lists in multi-dim arrays. (Improved syntax for multidim
arrays is one wishlist item from PDL for the perl core.
See RFC117)
NumPy allows you to say:
a[..., :];
where "..." means "however many", - so this is a slice along
the last dimension.
you can also say:
a[10:20,...,10:30,30]
etc.
Karl
Larry Wall wrote:
>> If you're into dwimmery, you could make all of these work, too:
>
> print (1, 2, 4, ...)
> print (1, 4, 9, 16, 25, ...)
> print (1, 1, 2, 3, 5, ...)
> print ('a', 'b', 'c', ...)
> print (3, 1, 4, 1, 5, 9, 6, 2, 5, ...)
>
> : BTW, I propose the this new operator be pronounced "yadda yadda yadda". :-)
>
> If you want to save the world, come up with a better way to say "www".
> (And make it stick...)
>
> Larry
Re: ... as a term
Damian Conway wrote: > > Easy. I'll just add a C operator to Q::S. It would take no > arguments and return a (lazy?) list of every possible Perl subroutine. > > PS: Can you tell whether I'm joking? I think you're both joking AND not joking, at the same time. -- John Porter We're building the house of the future together.
Re: ... as a term
On Tue, Aug 22, 2000 at 09:49:12AM -0400, John Porter wrote: > Damian Conway wrote: > > > > Easy. I'll just add a C operator to Q::S. It would take no > > arguments and return a (lazy?) list of every possible Perl subroutine. > > > > PS: Can you tell whether I'm joking? > > I think you're both joking AND not joking, at the same time. s/at the same/in constant/; # HTH -- $jhi++; # http://www.iki.fi/jhi/ # There is this special biologist word we use for 'stable'. # It is 'dead'. -- Jack Cohen
Re: ... as a term
Larry Wall wrote: > > Either that, or it's a funny unary operator that can take 0 or 1 argument. > > But I'd be happy with just ... as a statement. Dwimming the unary > operator may not be worth it. Especially since it might be confused > with the binary operator. Could you make it "evaporate" and compile time, just like the (proposed) qc()? And if it is an operator, it should commute its context. (Hopefully this would "just happen" if the ... evaporates.) -- John Porter We're building the house of the future together.
Re: ... as a term
Damian Conway wrote: > > I think this is fraught with peril. I'd have expected: > > print (1, 2, 3, ...) or die; > > to print > > 12345678910111213141516171819202122232425262728etc No, if that's what you wanted, you'd get it with print( 1, 2, 3 .. ) # RFC 24 -- John Porter We're building the house of the future together.
Re: ... as a term
Piers Cawley wrote: > > You forgot: > print (1, 11, 21, 1211, ...) print( 'M', 'MI', 'MIU', ... ) ALso, Larry, how about making the various common emoticons meaningful? please do come from 10; :-) I.e. "belay that command". -- John Porter We're building the house of the future together.
Re: functions that deal with hash should be more liberal
Casey R. Tweten wrote:
>
> sub func {
> return qw/KeyOne Value1 KeyTwo Value2/;
> }
>
> print "$_\n" foreach keys &func();
Please. There are ways -- well, just one way -- to do this, even in perl5.
print "$_\n" foreach keys %{{ func() }};
--
John Porter
We're building the house of the future together.
Re: functions that deal with hash should be more liberal
In reply to your message from the not too distant future: next Monday AD Reply-to: [EMAIL PROTECTED] Return-receipt-to: [EMAIL PROTECTED] Organization: a) Discordia b) none c) what's that? Content-Typo: gibberish, charset=ascii-art Date: Tue, 22 Aug 2000 10:15:48 EDT From: Jerrad Pierce >So, you're saying to dispense with prototypes, even in the core, and leave >us with the slowest language known to man? No and no. If you have internal prototypes, why can't it attempt a type conversion IFF you didn't satisfy the prototype. It's like doing math with strings, it checks to see if it really can use it as a number first... Why is this so hard? So the internals stay almost the same, but before resorting to die, you attempt a cast, if it works you warn that's inefficient under strict, and of course in the docs. If I occasionally want to be inefficient, I should have the license to do so. But I really don't think it'll be that less efficient, considering the alternative is to do the casting myself, which will almost certainly use more memory, and run slower than anything in the core. No? >I don't see that flying. All it requires is forgetting to hit the ground. -- * __* . \ | / .. . . . ((_ _ . . . -- / \ -- .. . +. . _/\ oo. | * . . . * / ;M\_ . ..oo. . .. . /\. / :IMM\ ....oo. Jerrad Pierce /\ / \ / ;IIWMM ..oo... 209 North Street +/ \ / \ . / ;WM ...o... Randolph, MA 02368/ \ \ ___/ :;IWM oooo.../\\ / :: ;;IIIMI .ooo.http://www.pthbb.org /\ \ : :::;IIIM ..ooo __ || || ::.:: MOTD on Prickle-Prickle, the 15th of Bureaucracy, in the YOLD 3166: "God is too big for only one religion." -- A. Weysman
Re: functions that deal with hash should be more liberal
>So the internals stay almost the same, but before resorting to die, >you attempt a cast, if it works you warn that's inefficient under strict, >and of course in the docs. If I occasionally want to be inefficient, I should >have the license to do so. But I really don't think it'll be that less >efficient, considering the alternative is to do the casting myself, which will >almost certainly use more memory, and run slower than anything in the core. >No? It will show that you are doing what you *want* to do, not letting automagic error-blind spoofery behind the curtains flummux up your life unnecessarily. --tom
Re: functions that deal with hash should be more liberal
Today around 10:11am, John Porter hammered out this masterpiece:
: Casey R. Tweten wrote:
: >
: > sub func {
: > return qw/KeyOne Value1 KeyTwo Value2/;
: > }
: >
: > print "$_\n" foreach keys &func();
:
: Please. There are ways -- well, just one way -- to do this, even in perl5.
:
: print "$_\n" foreach keys %{{ func() }};
Yes, there is.
Thank you for your input.
--
print(join(' ', qw(Casey R. Tweten)));my $sig={mail=>'[EMAIL PROTECTED]',site=>
'http://home.kiski.net/~crt'};print "\n",'.'x(length($sig->{site})+6),"\n";
print map{$_.': '.$sig->{$_}."\n"}sort{$sig->{$a}cmp$sig->{$b}}keys%{$sig};
my $VERSION = '0.01'; #'patched' by Jerrad Pierce
Re: Things to remove
Damian Conway wrote: > > Tom's opcode dumping functionality could, in principle, be added to > Data::Dumper as it stands. > > My proposal was merely that C<&Data::Dumper::Dumper> body-snatch C. But that's a crummy name for it, unix legacy not withstanding. Is someone working on an RFC? IIRC, it would propose that the entire state of the interpreter can be marshalled and unmarshalled, providing both a checkpointing capability and code mobility. Optionally the marshall will include only the explicitly given structures (subroutines, variables); or perhaps only a selected subset of interpreter state (code, data). -- John Porter We're building the house of the future together.
Re: Things to remove
Tom Christiansen wrote: > > Hmm, what about CHECK blocks? CHECK blocks would be great! But of course, they work in memory, which is not useful for persisting program state across executions, or moving it across machines. -- John Porter We're building the house of the future together.
Re: ... as a term
Larry Wall wrote: > > I'd entertain a proposal that ... be made a valid term that happens > to do nothing, so that you can run your examples through perl -c for > syntax checks. Or better, make it an official "stub" for rapid > prototyping, with some way of getting a warning whenever you execute > such a stub. Has anyone done an RFC on this yet? If not, I'll volunteer. -- John Porter
Re: ... as a term
John Porter writes: : Could you make it "evaporate" and compile time, just like the (proposed) qc()? Hard to make it evaporate at compile time and still give a warning at run time. :-) Larry
Re: ... as a term
Larry Wall wrote: > John Porter writes: > : Could you make it "evaporate" and compile time, just like the (proposed) qc()? > > Hard to make it evaporate at compile time and still give a warning at > run time. :-) Eh, eh... Curdle it into the appropriate warn() call! -- John Porter
Re: functions that deal with hash should be more libera
In reply to your message from the not too distant future: next Tuesday AD
Reply-to: [EMAIL PROTECTED]
Return-receipt-to: [EMAIL PROTECTED]
Organization: a) Discordia b) none c) what's that?
Content-Typo: gibberish, charset=ascii-art
Date: Tue, 22 Aug 2000 11:06:21 EDT
From: Jerrad Pierce
>It will show that you are doing what you *want* to do, not letting
>automagic error-blind spoofery behind the curtains flummux up
>your life unnecessarily.
Umm no.. for what I *want* to do is take the keys of the hash returned as a
list by a block. That's what I want. And yes I can do it with %{{}}.
But it's hardly symmetrical to working with arrays, and definitely not
obvious. Especially to a newbie, and even to lightly seasoned veterans.
How is it error-blind? Someone proposed that it complain if the cast was
performed on an odd-element list. But even that could be valid (the last key
has undef as a value). And I proposed making strict catch this. What other
errors might there be?
Whatever happened to making easy things easy, out of the box?
And if I want to be a masochist and have my code scrutinized like hell,
using strict, -wT ?
use strict 'hash';
no strict 'hash';
--
* __* .
\ | / .. . . . ((_
_ . . .
-- / \ -- .. . +. . _/\
oo. | * . . . * / ;M\_ .
..oo. . .. . /\. / :IMM\
....oo. Jerrad Pierce /\ / \ / ;IIWMM
..oo... 209 North Street +/ \ / \ . / ;WM
...o... Randolph, MA 02368/ \ \ ___/ :;IWM
oooo.../\\ / :: ;;IIIMI
.ooo.http://www.pthbb.org /\ \ : :::;IIIM
..ooo __ || || ::.::
MOTD on Prickle-Prickle, the 15th of Bureaucracy, in the YOLD 3166:
"God is too big for only one religion." -- A. Weysman
Re: functions that deal with hash should be more libera
Today around 11:06am, Jerrad Pierce hammered out this masterpiece:
: >It will show that you are doing what you *want* to do, not letting
: >automagic error-blind spoofery behind the curtains flummux up
: >your life unnecessarily.
:
: Umm no.. for what I *want* to do is take the keys of the hash returned as a
: list by a block. That's what I want. And yes I can do it with %{{}}.
: But it's hardly symmetrical to working with arrays, and definitely not
: obvious. Especially to a newbie, and even to lightly seasoned veterans.
Hear, hear! Do What I Mean.
: Whatever happened to making easy things easy, out of the box?
: And if I want to be a masochist and have my code scrutinized like hell,
: using strict, -wT ?
:
: use strict 'hash';
: no strict 'hash';
--
print(join(' ', qw(Casey R. Tweten)));my $sig={mail=>'[EMAIL PROTECTED]',site=>
'http://home.kiski.net/~crt'};print "\n",'.'x(length($sig->{site})+6),"\n";
print map{$_.': '.$sig->{$_}."\n"}sort{$sig->{$a}cmp$sig->{$b}}keys%{$sig};
my $VERSION = '0.01'; #'patched' by Jerrad Pierce
Re: functions that deal with hash should be more libera
Jerrad Pierce wrote:
> In reply to your message from the not too distant future: next Tuesday AD
> Reply-to: [EMAIL PROTECTED]
> Return-receipt-to: [EMAIL PROTECTED]
> Organization: a) Discordia b) none c) what's that?
> Content-Typo: gibberish, charset=ascii-art
> Date: Tue, 22 Aug 2000 11:06:21 EDT
> From: Jerrad Pierce
Please stop doing this.
And for God's sake get rid of that obnoxious .sig.
> Umm no.. for what I *want* to do is take the keys of the hash returned as a
> list by a block. That's what I want. And yes I can do it with %{{}}.
> But it's hardly symmetrical to working with arrays, and definitely not
> obvious. Especially to a newbie, and even to lightly seasoned veterans.
I think you are still confused as to the difference between arrays and
hashes, which are variables, and lists, which are not.
The assignment of lists to arrays and hashes are well-defined operations,
and quite transparent. Also feeding the confusion is that some array
operations also work on lists, such as scalar() and ()[]. But lists
are still not arrays; and certain array operations can ONLY work on
arrays, because they must work on variables, which lists are not.
Symmetrically, hash operations must work on hashes, which lists are not.
But I do agree it would be nice if there were a way to simultaneously
construct and dereference an anonymous array or list, perhaps something
like
@( 1, 2, 3 )
%( foo => 1, bar => 2 )
which would be equivalent to
@{[ 1, 2, 3 ]}
%{{ foo => 1, bar => 2 }}
but with perhaps lower overhead.
--
John Porter
We're building the house of the future together.
Re: functions that deal with hash should be more libera
>But I do agree it would be nice if there were a way to simultaneously
>construct and dereference an anonymous array or list, perhaps something
>like
> @( 1, 2, 3 )
> %( foo => 1, bar => 2 )
>which would be equivalent to
> @{[ 1, 2, 3 ]}
> %{{ foo => 1, bar => 2 }}
>but with perhaps lower overhead.
You're working too hard.
[ 1, 2, 3 ]
{ foo => 1, bar => 2 }
as in
$name = 'foo';
$value = { foo => 1, bar => 2 }->{$name};
Not that I'm claiming this is excessively efficient, but
it's already there. One just works on the compiler to
be smarter on optimizing. Or the programmer:
$table = { foo => 1, bar => 2 }->{$name};
$name = 'foo';
$value = $table->{$name};
--tom
Re: functions that deal with hash should be more liberal
In reply to your message from the not too distant future: next Tuesday AD Reply-to: [EMAIL PROTECTED] Organization: a) Discordia b) none c) what's that? Content-Typo: gibberish, charset=ascii-art Date: Tue, 22 Aug 2000 12:58:38 EDT From: Jerrad Pierce >I think you are still confused as to the difference between arrays and >hashes, which are variables, and lists, which are not. Lists are what the CORE or a subroutine throw back at you. Arrays and hashes are user data structures. Often, arrays and lists can be treated similarly, if not the same. Not so hard to get. The assigment operator can do explicit list to array or hash conversion, I'm just proposing that there be the ability for an implicit conversion when calling a function with a list. Other than the issue of semantics (array is not list), I still have not seen: a) why this is the Wrong Thing b) while not the Wrong Thing, it should not be done. c) something to refute Do What I Mean -- * __* . \ | / .. . . . ((_ _ . . . -- / \ -- .. . +. . _/\ oo. | * . . . * / ;M\_ . ..oo. . .. . /\. / :IMM\ ....oo. Jerrad Pierce /\ / \ / ;IIWMM ..oo... 209 North Street +/ \ / \ . / ;WM ...o... Randolph, MA 02368/ \ \ ___/ :;IWM oooo.../\\ / :: ;;IIIMI .ooo.http://www.pthbb.org /\ \ : :::;IIIM ..ooo __ || || ::.:: MOTD on Prickle-Prickle, the 15th of Bureaucracy, in the YOLD 3166: "God is too big for only one religion." -- A. Weysman
Re: functions that deal with hash should be more liberal
>Other than the issue of semantics (array is not list), I still have not
>seen:
>a) why this is the Wrong Thing
Why what is the wrong thing? Why treating an immutable list
as a mutable array is wrong? Because you can't change the length
of a list -- it doesn't have an AV to update. If you want
$n = pop fn()
you are just obfuscating writing
$n = (fn())[-1];
>b) while not the Wrong Thing, it should not be done.
It should not be done because it is wrong to lose compile-time
type checking save under grave environmental stress, the likes
of which you are yet to demonstrate. The burden of proof rests
with you to show why to turn perl dumber.
>c) something to refute Do What I Mean
You have yet to show what you mean, or that what you mean is
painful to accomplish.
There are real issues, but you've missed them. One is the
cumbersomeness of writing
while ( ($k,$v) = each %{ $x[$i][$j] } ) {}
instead of:
while ( ($k,$v) = each $x[$i][$j] ) {}
But that comes with similar attendant problems. What then
should
while ( ($k,$v) = each fn() ) {}
do? How often should fn() be called there? And what if it
returns a hash ref versus a list? What about a list of one
hash ref?
Comflating values with variables is not always sensible: consider
4++, for example; this isn't (old) FORTRAN. :-) Why you should be
able, without a whit of added notation to that effect, to pop a
function return list or each a function return list is not something
you have efffectively proven.
Catching errors is important. The dweomer you would claim desirable
is slippery magic at best, more complex than I think you think.
--tom
Re: functions that deal with hash should be more libera
Tom Christiansen wrote:
> it's already there. One just works on the compiler to
> be smarter on optimizing.
I suppose that's true. But why would
%( foo => 1, bar => 2 )
be "working harder" than
%{{ foo => 1, bar => 2 }}
??? It's few keystrokes and would be a less tricky concept
to remember.
--
John Porter
Filtering rules
(Off-topic for this list, but I'm not sure where else to send it)
Could we have a discussion somewhere of useful filtering rules for all
these perl6 lists? Specifically, I'm looking to steal other people's
.procmailrc snippets. I imagine that a lot of people have written their
own, and everything I do in that @#$!! config language breaks the first
four times I try it (partly because my mail directory is NFS mounted in
a place where NFS locks permanently hang any process attempting to use
them).
Ask posted a very nice rule to perl6-announce:
=for procmail
I added another header to the perl6-all mails. X-Mailing-List-Name
will contain the original list name, san -help and whatnot.
So the recommended procmail filter rule would now be:
:0:
* ^Mailing-List: contact [EMAIL PROTECTED]; run by ezmlm
* ^X-Mailing-List-Name: \/(.*)
perl/$MATCH
or something like that.
Enjoy,
- ask
=cut
(perhaps there is a discussion on perl6-all, which I do not subscribe
to?)
Just for perl6-language, I use:
=for procmail
:0:/tmp/sfink.locks/language.lock
* ^[EMAIL PROTECTED]
{
SUBJECT=`formail -xSubject:`
:0 c
* ^TOsfink
| formail -f -i "Subject: (COPY) $SUBJECT" >>$HOME/mbox
:0
perl6-language
}
=cut
That's so if anyone is replying to a message I posted deep in some
subthread, I don't miss it (because I *always* read the group threaded;
the traffic would overwhelm me otherwise.) But I probably have the locks
backwards or something.
I think I may have to subscribe to the firehose (perl6-all) and use
something closer to Ask's filter, though.
Can someone tell me how to fetch a digest of an existing subgroup and
split it into separate messages? I know, there are examples that do
things like this, but I'm hoping to be lazy and just steal someone
else's working rule.
Thanks!
Re: functions that deal with hash should be more liberal
In 42 lines, of which 25 were waste, Jerrad Pierce wrote: > > a) why this is the Wrong Thing It is simply not the way perl works. In these matters at least, perl is quite consistent. > c) something to refute Do What I Mean DWIM is cutesy, but not actually meaningful. Perl comes closer to dwim than most any other language, but dwim is not really a perl goal. Instead, you should persuasively explain why your proposed change significantly furthers perl's real goal of making easy things easy and hard things possible. You already have a way of constructing and dereferencing (accessing) an anonymous hash on the fly; what else do you need? -- John Porter We're building the house of the future together.
Re: functions that deal with hash should be more liberal
In reply to your message from the not too distant future: next Tuesday AD
Reply-to: [EMAIL PROTECTED]
Return-receipt-to: [EMAIL PROTECTED]
Organization: a) Discordia b) none c) what's that?
Content-Typo: gibberish, charset=ascii-art
Date: Tue, 22 Aug 2000 13:48:36 EDT
From: Jerrad Pierce
>$n = pop fn()
>you are just obfuscating writing
>
>$n = (fn())[-1];
yes
>It should not be done because it is wrong to lose compile-time
>type checking save under grave environmental stress, the likes
Why are you losing checking? It would seem right now keys
would first check to make sure it'll be getting *something* OR die
then to make sure that that something is a hash OR die
And all I said was replace the last OR die with:
OR warn (if under strict&|-w) AND cast at run-time
If you gave it hash you short-circuit right out and have not lost any time.
If it in fact is not a hash, you may get warning under strict or -w.
>of which you are yet to demonstrate. The burden of proof rests
>with you to show why to turn perl dumber.
This is *not* making it dumber, the only way it would make it dumber is if
you lost your test. But you don't have to lose your compile-time test...
>But that comes with similar attendant problems. What then
>should
>while ( ($k,$v) = each fn() ) {}
>do? How often should fn() be called there? And what if it
>returns a hash ref versus a list? What about a list of one
>hash ref?
It should be called once, otherwise you would loop indefinitely.
It should then pass every other value into $k and $v, while you iterate
over the contents. For example:
while ( ($k,$v) = each fn() ){
push @F, $k;
push @G, $v;
}
not being dissimilar from
@F = fn();
unzip(2, \@F)
>Comflating values with variables is not always sensible: consider
>4++, for example; this isn't (old) FORTRAN. :-)
Well that's a different issue, since that always evaluates to the same thing...
--
* __* .
\ | / .. . . . ((_
_ . . .
-- / \ -- .. . +. . _/\
oo. | * . . . * / ;M\_ .
..oo. . .. . /\. / :IMM\
....oo. Jerrad Pierce /\ / \ / ;IIWMM
..oo... 209 North Street +/ \ / \ . / ;WM
...o... Randolph, MA 02368/ \ \ ___/ :;IWM
oooo.../\\ / :: ;;IIIMI
.ooo.http://www.pthbb.org /\ \ : :::;IIIM
..ooo __ || || ::.::
MOTD on Prickle-Prickle, the 15th of Bureaucracy, in the YOLD 3166:
"God is too big for only one religion." -- A. Weysman
Re: functions that deal with hash should be more libera
John Porter writes:
> I suppose that's true. But why would
> %( foo => 1, bar => 2 )
> be "working harder" than
> %{{ foo => 1, bar => 2 }}
> ??? It's few keystrokes and would be a less tricky concept
> to remember.
It's a new syntax, not orthogonal to anything we already have. The
number of people wanting to coopt %{ or %( or %[ is truly frightening.
I think the message is: Don't put time into the parser when your
effort could better be spent in the optimizer.
Nat
Re: functions that deal with hash should be more liberal
I assure you that the number of people who get compile-time caught for writing keys or each $x[$i][$j] or pop or push $x[$i][$j] is *very* large. This is by far the most prevalent error that happens with data structures in apprentice and perhaps even journeymen perl programmers. Having the compiler immediately report this at run time is very important, and not at all worth losing. Go teach thousands of people perl data structures, and then you'll see what I mean. --tom
Re: functions that deal with hash should be more libera
Nathan Torkington wrote:
> John Porter writes:
> > I suppose that's true. But why would
> > %( foo => 1, bar => 2 )
> > be "working harder" than
> > %{{ foo => 1, bar => 2 }}
> > ??? It's few keystrokes and would be a less tricky concept
> > to remember.
>
> It's a new syntax, not orthogonal to anything we already have.
So? Perl's not like that. Perl is diagonal. And this is just
another corner being cut.
I have a list of stuff that looks a lot like a hash:
( foo => 1, bar => 2 )
Now, gol dern it, I want to treat it like a hash. I want *perl*
to let me treat it like a hash. Directly!
If not
keys ( foo => 1, bar => 2 )
then
keys %( foo => 1, bar => 2 )
Or *something*.
> I think the message is: Don't put time into the parser when your
> effort could better be spent in the optimizer.
Who "you"? This is the -language list.
--
John Porter
We're building the house of the future together.
Re: functions that deal with hash should be more libera
John Porter writes:
> So? Perl's not like that. Perl is diagonal. And this is just
> another corner being cut.
Cut away enough corners, and you have a black hole. Or something :-)
My point is that before you reach to invent new syntax, see if there's
a way to do what you want with the existing syntax. I have a document
coming on this to try and point people who want to give meaning to
every possible combination of punctuation and alphanumerics in the
right direction.
Perl is already very hairy and full of punctuational quirks. I think
we need a fairly compelling argument.
> I have a list of stuff that looks a lot like a hash:
>
> ( foo => 1, bar => 2 )
>
> Now, gol dern it, I want to treat it like a hash. I want *perl*
> to let me treat it like a hash. Directly!
A hash is a specific data structure, currently encapsulated in the
innards as an HV. What you have is a list. You can assign that list
to a hash, in which case Perl builds an HV for you.
> If not
> keys ( foo => 1, bar => 2 )
> then
> keys %( foo => 1, bar => 2 )
I personally prefer:
('foo', 'bar')
or even
qw(foo bar)
for that.
Seriously, how many times do you want to call keys or values on
a list and then never do anything else with it? Very very rarely.
Most of the times you say:
foreach $foo (keys %bar) {
# do something with $foo and $bar
}
or at the very least you save away the list of keys and do something
with the corresponding values later on.
Yes, there are a few situations (e.g, where the presence of the key in
the hash is important not the actual value stored with the key) where
you might want the keys returned by a function but nothign else.
But those are mighty mighty rare.
In those mighty rare cases, I say you should have to deal with:
keys %{{ foo() }}
Nat
Re: functions that deal with hash should be more libera
Today around 3:01pm, John Porter hammered out this masterpiece:
: Nathan Torkington wrote:
: > John Porter writes:
: > > I suppose that's true. But why would
: > > %( foo => 1, bar => 2 )
: > > be "working harder" than
: > > %{{ foo => 1, bar => 2 }}
: > > ??? It's few keystrokes and would be a less tricky concept
: > > to remember.
: >
: > It's a new syntax, not orthogonal to anything we already have.
:
: So? Perl's not like that. Perl is diagonal. And this is just
: another corner being cut.
As a user, I should be able to expect this:
sub func {
return ( qw/KeyOne Value1 KeyTwo Value2/ );
}
my %hash = &func();
print "$_\n" foreach keys %hash;
To work just like this:
print "$_\n" foreach keys &func();
In my, 'pretending to just learn' mode, I don't understand. Perl will assign
the LIST to the hash in example one, but in example two, it croaks.
Removing intermediate data structures is easy in Perl, but not this case,
instead, I have to do this:
%{{&func()}};
How... not easy to learn.
Especially since it's not documented. Perhaps, at least for the current version
of Perl, this should be documented in perlfunc under keys(), values() and
each(). Also in perlfaq4, although I bet this is not a frequent question.
--
print(join(' ', qw(Casey R. Tweten)));my $sig={mail=>'[EMAIL PROTECTED]',site=>
'http://home.kiski.net/~crt'};print "\n",'.'x(length($sig->{site})+6),"\n";
print map{$_.': '.$sig->{$_}."\n"}sort{$sig->{$a}cmp$sig->{$b}}keys%{$sig};
my $VERSION = '0.01'; #'patched' by Jerrad Pierce
Re: functions that deal with hash should be more libera
> my %hash = &func();
> print "$_\n" foreach keys %hash;
>To work just like this:
> print "$_\n" foreach keys &func();
>In my, 'pretending to just learn' mode, I don't understand. Perl will assign
>the LIST to the hash in example one, but in example two, it croaks.
A LIST is not a HASH. Learn that. Be done with it. Move on.
>Removing intermediate data structures is easy in Perl, but not this case,
>instead, I have to do this:
>%{{&func()}};
>How... not easy to learn.
>Especially since it's not documented. Perhaps, at least for the current
Say what?
--tom
Re: ... as a term
> > I think this is fraught with peril. I'd have expected: > > > > print (1, 2, 3, ...) or die; > > > > to print > > > > 12345678910111213141516171819202122232425262728etc > > No, if that's what you wanted, you'd get it with > >print( 1, 2, 3 .. ) # RFC 24 Sure, but I said "expected", not "wanted". I was pointing out that the distinction between the two syntaxes is too subtle, especially since, in English, we write infinite lists with three dots, not two. Damian
Re: functions that deal with hash should be more libera
>As a user, I should be able to expect this: I've decided I don't believe you, because despite having taught a zillion people Perl, I have never *once* seen the misexpectation and subsequent error that you're spending so much time complaining about. --tom
Re: functions that deal with hash should be more libera
Today around 1:41pm, Tom Christiansen hammered out this masterpiece:
: > my %hash = &func();
: > print "$_\n" foreach keys %hash;
:
: >To work just like this:
:
: > print "$_\n" foreach keys &func();
:
: >In my, 'pretending to just learn' mode, I don't understand. Perl will assign
: >the LIST to the hash in example one, but in example two, it croaks.
:
: A LIST is not a HASH. Learn that. Be done with it. Move on.
Goodness man, I got it, I have gotten it. Perhaps I'm using wrong terminology,
but I understand.
: >Removing intermediate data structures is easy in Perl, but not this case,
: >instead, I have to do this:
:
: >%{{&func()}};
:
: >How... not easy to learn.
:
: >Especially since it's not documented. Perhaps, at least for the current
:
: Say what?
Well, there is a mention to the effect of:
@uniq = keys %{{%foo,%baz}};
in perlfaq4.
And perlfunc says that keys only works on 'named hashes'. I suppose to a
seasoned veteran, that's sufficient.
There is no documentation that states:
``keys() just doesn't work on lists and/or arrays, you must use this syntax to
force that to work:
@array = keys %{{@array}};
''
Or something like that.
This suggestion was brought up as a means to make these functions more user
friendly.
If it's impossible, then I'll be glad to forget about it.
[Insert many replies that agree here, I'm sure.]
--
print(join(' ', qw(Casey R. Tweten)));my $sig={mail=>'[EMAIL PROTECTED]',site=>
'http://home.kiski.net/~crt'};print "\n",'.'x(length($sig->{site})+6),"\n";
print map{$_.': '.$sig->{$_}."\n"}sort{$sig->{$a}cmp$sig->{$b}}keys%{$sig};
my $VERSION = '0.01'; #'patched' by Jerrad Pierce
Re: functions that deal with hash should be more libera
Today around 1:51pm, Tom Christiansen hammered out this masterpiece:
: >As a user, I should be able to expect this:
:
: I've decided I don't believe you, because despite having taught a
: zillion people Perl,
Commendable. I value your expertise.
: I have never *once* seen the misexpectation and subsequent error that you're
: spending so much time complaining about.
Perhaps you never taught me :-)
Perhaps if you had, I wouln't be having this problem.
Perhaps, since you are ( or have been ) so prominent in documenting Perl, you
could and/or would help other people like me to understand this
problem/bug/feature/not too noticed 'thing'.
--
print(join(' ', qw(Casey R. Tweten)));my $sig={mail=>'[EMAIL PROTECTED]',site=>
'http://home.kiski.net/~crt'};print "\n",'.'x(length($sig->{site})+6),"\n";
print map{$_.': '.$sig->{$_}."\n"}sort{$sig->{$a}cmp$sig->{$b}}keys%{$sig};
my $VERSION = '0.01'; #'patched' by Jerrad Pierce
Re: functions that deal with hash should be more libera
>There is no documentation that states:
>``keys() just doesn't work on lists and/or arrays, you must use this syntax to
>force that to work:
> @array = keys %{{@array}};
>''
>Or something like that.
keys is documented to take a hash. Likewise, push an array.
This all seems completely obvious.
--tom
Re: functions that deal with hash should be more libera
And at this point we seem to have run out of steam for changing perl6 in this direction. Please take dialogue on the perl5 documentation to the perl5-porters list. Thanks, Nat
Re: functions that deal with hash should be more libera
Casey R. Tweten wrote:
>
> Removing intermediate data structures is easy in Perl, but not this case,
C, etc. must have data structures to work on. There's no "getting rid"
of them.
"I want find /usr to search the directory tree, but, um, I don't want to
actually *have* a directory tree..."
> Especially since it's not documented.
Oh, it is. The documentation of C, C, and C all state
clearly that they operate on HASH variables. And perldata and perlref
clearly describe how to make a HASH variable on the fly.
{ foo => bar } # create a HASH, getting a ref to it.
%{ ... } # dereference a HASH ref
--
John Porter
We're building the house of the future together.
Re: functions that deal with hash should be more libera
Casey R. Tweten wrote: > > There is no documentation that states: > > ``keys() just doesn't work on lists and/or arrays, Why should it bother saying that, when it already says keys() works on a HASH? Or is there some confusion that a HASH might also be an ARRAY or a LIST? -- John Porter We're building the house of the future together.
Re: functions that deal with hash should be more libera
Today around 4:07pm, John Porter hammered out this masterpiece:
: Casey R. Tweten wrote:
: >
: > Removing intermediate data structures is easy in Perl, but not this case,
:
: C, etc. must have data structures to work on. There's no "getting rid"
: of them.
Perl can create them for me.
: "I want find /usr to search the directory tree, but, um, I don't want to
: actually *have* a directory tree..."
*sigh* I like that example.
: > Especially since it's not documented.
:
: Oh, it is. The documentation of C, C, and C all state
: clearly that they operate on HASH variables. And perldata and perlref
: clearly describe how to make a HASH variable on the fly.
True.
: { foo => bar } # create a HASH, getting a ref to it.
:
: %{ ... } # dereference a HASH ref
Indeed, how intuitive.
Today around 1:51pm, Tom Christiansen hammered out this masterpiece:
:
: I've decided I don't believe you, because despite having taught a
: zillion people Perl, I have never *once* seen the misexpectation
: and subsequent error that you're spending so much time complaining
: about.
I think I use Perl differently that many other people, when it comes to this. I
don't consider my uses wrong, and I'd like to see them simplified. I'm content
to keep them the way they are in the face of this much adversity.
It seems that I ask the impossible. And if it's not impossible, then we become
worried about speed, but I wonder if that's what we're here to worry about
anyhow?
Today around 4:11pm, John Porter hammered out this masterpiece:
:
: Casey R. Tweten wrote:
: >
: > There is no documentation that states:
: >
: > ``keys() just doesn't work on lists and/or arrays,
:
: Why should it bother saying that, when it already says keys() works on a HASH?
:
: Or is there some confusion that a HASH might also be an ARRAY or a LIST?
No, there is no confusion, thanks.
Again, I must use Perl differently. I suppose I like to bend it in certain
areas more than most people.
Ho hum... I'm done with this battle.
--
print(join(' ', qw(Casey R. Tweten)));my $sig={mail=>'[EMAIL PROTECTED]',site=>
'http://home.kiski.net/~crt'};print "\n",'.'x(length($sig->{site})+6),"\n";
print map{$_.': '.$sig->{$_}."\n"}sort{$sig->{$a}cmp$sig->{$b}}keys%{$sig};
my $VERSION = '0.01'; #'patched' by Jerrad Pierce
Re: functions that deal with hash should be more libera
At 04:11 PM 8/22/00 -0400, John Porter wrote:
>Casey R. Tweten wrote:
> >
> > There is no documentation that states:
> >
> > ``keys() just doesn't work on lists and/or arrays,
>
>Why should it bother saying that, when it already says keys() works on a
>HASH?
>
>Or is there some confusion that a HASH might also be an ARRAY or a LIST?
I can see that...
Perhaps part of the problem is:
@array1 = (1, 1, 3, 5, 8, 13);
%hash1 = ('foo', 34, 'bar', "not a number", 'baz', 4);
@array2 = %hash1;
%hash2 = @array1;
This works, and may lead to confusion because:
1) You can assign lists, arrays, and hashes to @array
2) You can assign lists, arrays, and hashes to %hash
3) @array and %hash in list context works as expected
4) @array and %hash in array context works as expected
5) @array and %hash in hash context works as expected
While lists won't work in array or hash contexts, there are few places
where array or hash context is required, so a beginning Perl programmer
might not bump into them except for keys(), values(), and similar.
It doesn't help that Camel II's glossary defines "array" as "A named list
of values, each of which has a unique key to identify it. In a normal
array, the key is numeric... In a hash...the key is a string." and seems to
go to a lot of effort to deprecate "array" in favor of "list" (array
context: "A quaint, archaic expression used by people who have read the
first edition of this book. Nowadays called 'list context'.").
Reading that, what would you say the difference between an array, a list,
and a hash is?
(My answer: From that glossary, I'd say that 'array' and 'list' are
virtually synonymous. From actual use, I'd say that an array can be an
lvalue, but a list is strictly an rvalue.)
>--
>John Porter
>
> We're building the house of the future together.
Re: functions that deal with hash should be more libera
[to you only, as this thread is now distinctly off-topic for perl6-language]
Buddha Buck wrote:
>
> @array1 = (1, 1, 3, 5, 8, 13);
> %hash1 = ('foo', 34, 'bar', "not a number", 'baz', 4);
> @array2 = %hash1;
> %hash2 = @array1;
>
> This works, and may lead to confusion because:
This is exactly what I was referring to in an earlier post --
that the well-definedness of these assignment operations leads
the unsuspecting to believe that there really is some kind of
equivalence of the underlying structures, when in fact there
is not.
> Reading that, what would you say the difference between an array, a list,
> and a hash is?
>
> (My answer: From that glossary, I'd say that 'array' and 'list' are
> virtually synonymous. From actual use, I'd say that an array can be an
> lvalue, but a list is strictly an rvalue.)
( $a, $b, $c ) = ( 1..100 );
No, lists can be lvalues too.
The difference, as stated before, is that LISTs are not variables; that
is, a list has no unified internal data structure, upon which such
operations as push() or each() might work. Some people like to say that
a list is just a bunch of scalar values on the stack; but if you don't
think in terms of call stacks, that analogy doesn't illuminate.
I like to think of variables (scalars, arrays, and hashes) as being
Perl's intrinsic object types; each supports a set of methods: array
supports the push() method, hash supports the each() method, etc.
Thinking of it in these object-oriented terms, I can say that a LIST
is not an object, and so does not support any object methods.
There are some things you *can* do with a list, such as index into it
to get specific elements; but this is merely a syntactic convenience
for the programmer, and has little to do with indexing into a true
array variable.
Hope this helps,
--
John Porter
Re: functions that deal with hash should be more libera
>It doesn't help that Camel II's glossary defines "array" as "A named list >of values, each of which has a unique key to identify it. In a normal >array, the key is numeric... In a hash...the key is a string." and seems to >go to a lot of effort to deprecate "array" in favor of "list" (array >context: "A quaint, archaic expression used by people who have read the >first edition of this book. Nowadays called 'list context'."). Here's from Camel III. I hope you find this more helpful than before. =item B An ordered sequence of values, stored such that you can easily access any of the values using an integer subscript that specifies the value's offset in the sequence. =item B An archaic expression for what is more correctly referred to as I =item B An unordered association of I/I pairs, stored such that you can easily use a string I to look up its associated data . This glossary is like a hash, where the word to be defined is the key, and the definition is the value. A hash is also sometimes septisyllabically called an "associative array", which is a pretty good reason for simply calling it a "hash" instead. =item B A data structure used internally by Perl for implementing associative arrays (hashes) efficiently. See also I. =item B A syntactic construct representing a comma-separated list of expressions, evaluated to produce a I. Each I in a R is evaluated in a I and interpolated into the list value. =item B An ordered set of scalar values, =item B The situation in which an I is expected by its surroundings (the code calling it) to return a list of values rather than a single value. Functions that want a R of arguments tell those arguments that they should produce a list value. See also I. >Reading that, what would you say the difference between an array, a list, >and a hash is? I'm not sure from reading that. The answer that comes to my mind is that an array has an AV (updatable array metadata header structure) and a hash an HV (similarly), but a list--well, that's just SVs sitting around on a stack somewher. But that's not very useful for anyone who's still confused. >(My answer: From that glossary, I'd say that 'array' and 'list' are >virtually synonymous. From actual use, I'd say that an array can be an >lvalue, but a list is strictly an rvalue.) Actually, you *can* use a list lvalueably, provided that each of that list's components is also a legal lvalue. For example: ($a, $b, $c, $d, @etc) = fn(); However, currently you can't switch those, even for lvaluable functions. --tom
Re: New syntactic sugar builtin: in
This sounds like another job for the macro language.
Anyone have any idea what the macro language should look
like, aside from that the variables in it which will get
replaced might wear hats?
defining -language-macro might be premature because identifying
what suggestions and shortcuts make more sense as macros is a little
tricky; what we need to do is gather up a collection of all
the short rewrites we want to be able to do, ( including in my opinion
perl-5-isms like the postfix if/while/for ) and produce a language in
which they can all be succinctly and clearly declared.
Ones we like get to be standard macros (such as this one)
The difference btn a macro and a subroutine is, the interface is completely
different, and the macro does not create a coderef and register it with
the symbol table, rather it defines a way to rewrite and registers that with
the parser or lexer or "clarify" function (at some level.)
If these are all tagged to key words, that makes inplementation a lot
easier than if they are tied to syntax: After getting a token out of
the code, the lexer examines the tags of the token for macro definitions
and checks each one's rules to see if any match and if so does what is
defined.
Peter's "in" keyword would, in the (tokenize then clarify) language
I wrote over the weekend (and have written on two pads of paper, really I do)
be implementable as something tied to something very similar if
not exactly BOOLEAN_BAREWORD_in and this something would check to see
if the previous token can be coerced into a scalar and the next token
can be coerced into a list and if so, expand.
Macro expansion has the problem of expressions with side effects
appearing multiple times for no identifiable-by-beginners reasons, so
that is an argument against it.
Adding something to the parameter-list-specification language that
will look over to what-is-on-the-left-of-the-keyword is another
possibility.
Should this go to -internals ?
Markus Peter wrote:
>
> I'd like to see a new builtin named "in" which does the same as "in" in SQL.
> Basically,
>
> print "OK!" if $val in ("foo","bar","bla");
>
> is the same as
>
> print "OK!" if grep { $_ eq $val } ("foo","bar","bla");
>
> or
>
> print "OK!" if $val eq "foo" or $val eq
>
> except it's a lot more compact, intuitive to use and readable...
>
> --
> Markus Peter - SPiN GmbH
> [EMAIL PROTECTED]
--
David Nicol 816.235.1187 [EMAIL PROTECTED]
Laziness with responsibility http://www.tipjar.com/kcpm
Re: RFC 133 (v1) Alternate Syntax for variable names
>
> Consider the following syntax:
>
> my var; # declaring a scalar
> my array[]; # declaring an array
> my hash{};# declaring a hash
For the remainder of the enclosing block, the barewords var,
array and hash are to be interpreted as references to a scalar, an
array, and a hash.
As long as assignment starts doing automatic dereferencing this
will not be too tricky, it will require adding some work to C
and adding more barewords to the local bareword board.
--
David Nicol 816.235.1187 [EMAIL PROTECTED]
Laziness with responsibility http://www.tipjar.com/kcpm
RE: Uses for array notation (was Re: RFC 104 (v1) Backtracking)
-Original Message- From: Jeremy Howard [mailto:[EMAIL PROTECTED]] [...] Programmers shouldn't have to know how a computer implements things behind the scenes--which is really what requiring explicit looping forces. Great point, this should be in the RFC. -Corwin
Re: Permanent sublists (was Re: Language WG report, August 16th 2000)
On Wed., Aug 16, 2000, Nate Wiger wrote: > is good. Right now, people are hopping in 500 emails behind, replying to > something in the middle of the stream, and only later reading the > "please move this to -errors" post. Actually, I'm 1283 emails behind, to be exact. And that's just counting -language, no subgroups. jdb
Re: RFC 141 (v1) This Is The Last Major Revision
On 23 Aug 2000, Perl6 RFC Librarian wrote: > Since versioning is a meta-implementation issue, all that is required > is that fearless leader has to agree this is a good idea. Very funny. I suppose you don't mind if he changes his mind someday? I'm starting to think that you have too much time on your hands. -sam
RFC 140 (v1) One Should Not Get Away With Ignoring System Call Errors
This and other RFCs are available on the web at http://dev.perl.org/rfc/ =head1 TITLE One Should Not Get Away With Ignoring System Call Errors =head1 VERSION Maintainer: Jarkko Hietaniemi <[EMAIL PROTECTED]> Date: 22 August 2000 Version: 1 Mailing List: [EMAIL PROTECTED] Number: 140 =head1 ABSTRACT =head1 EXECUTIVE SUMMARY If something fails, you should care. =head1 TERMINOLOGY In the following 'system calls' mean anything not in the core language calling an external service, be it a 'real' system call (such as accept(), fork(), mkdir()) or a 'library' call (such as print(), syswrite() getpwent()). The difference is often arbitrary and depends on the implementation details of the operating system and the libraries. This difference is irrelevant for the purposes of this RFC (though relevant for the low-level implementation of this proposal). =head1 DESCRIPTION The 'strict' pragma (or whatever form it takes in perl6) should include in its 'default set of strictness' a new subpragma, 'system'. This subpragma has the following semantics: =over 4 =item * For many system calls it is possible to say during B that ignoring their return value is foolish and should be punished (by aborting during compilation). Examples of such system calls: open(), mkdir(), chdir(). There simply isn't an excuse for ignoring their return values. =item * For other system calls aborting during compile time may be too harsh: print() is an obvious example. But print() can fail, too: out of disk space, out of quota, closed socket. Such softer failures are indicated (at C level) by e.g. return of -1 and/or turning on errno. Such failures are detectable during B, and if, running under 'use strict', should croak. Lexical warnings could warn about such system calls: "print() can fail during runtime". =back =head2 Cheating Is Still Possible Not ignoring the return value is of course no guarantee of doing anything useful with the return value: $so_what++ unless defined fork(); But detecting whether 'something useful' is done is squarely in the realm of heavy AI. =head2 Is That An Object In Your Pocket Or Are You Just Oriented To See Me? This proposal does not deal with any object oriented issues, whether the detected errors 'throw' any 'exceptions' and how the user can 'catch' them. The proposed strict handling of system call failures should be independent of any higher level concepts such as object oriented 'exception handling'. Exception handling is welcome to provide ways to muster these low-level error conditions, though. =head1 MIGRATION ISSUES By having this new level of bondage-and-discpiline tucked away under 'use strict' the quick hack one liner nature of Perl is still available. =head1 REFERENCES perl6-language-errors perl6-language-strict perl6-language-io
RFC 139 (v1) Allow Calling Any Function With A Syntax Like s///
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Allow Calling Any Function With A Syntax Like s///
=head1 VERSION
Maintainer: John Porter <[EMAIL PROTECTED]>
Date: 17 Aug 2000
Version: 1
Mailing List: [EMAIL PROTECTED]
Number: 139
=head1 ABSTRACT
The calling syntaces of m()/s() should be consistent with other forms of
function call; this should be achieved not by eliminating the traditional
C form from m()/s(), but by allowing any function to be called with C.
=head1 DESCRIPTION
The strings delimited by the slashes, or other allowed delimiters, would be
passed as the arguments to the function. Note that this would include a
possible trailing string of C<\w> characters.
Furthermore, if the binding operator is used in conjunction with the function
call, it is passed as the first argument by reference, appropriately arranged.
Some simple example should help to demonstrate the idea:
greek( 'alpha', 'beta' );
could be written as any of the following:
greek/alpha/beta/;
greek#alpha#beta#;
greek(alpha){beta};
And, taking advantage of the trailing C<\w> string:
greek/alpha/beta;
greek#alpha#beta;
greek(alpha)beta;
Now, the following in the new syntax
$foo =~ greek/alpha/beta;
would be the same as the following in old syntax:
greek( \$foo, 'alpha', 'beta' );
=head1 IMPLEMENTATION
The mechanism that is currently invoked in the parsing of m()/s() expressions
could be used generally.
Note that all the parameters are necessarily strings; numeric literals
do not get pre-converted by the compiler. Or rather, whatever perl does
for m()/s() arguments, that would also be done when this syntax is used
to call other functions.
head2 Further Observations
The proposed semantics of the binding operator C<=~> looks to my eye very much
like a method referencing operator for direct (non-blessed) variable objects.
That is, there is no reason to suppose that
for ( %db =~ grok/SSN/$ssn/g ) ) { ...
is not an invocation of the C "method" on the C<%db> "object".
=head1 REFERENCES
L for details on the calling syntax of m//, s///.
RFC 141 (v1) This Is The Last Major Revision
This and other RFCs are available on the web at http://dev.perl.org/rfc/ =head1 TITLE This Is The Last Major Revision =head1 VERSION Maintainer: David Nicol <[EMAIL PROTECTED]> Date: 22 Aug 2000 Version: 1 Mailing List: [EMAIL PROTECTED] Number: 141 =head1 ABSTRACT Future perl version numbers will converge on 2 * PI =head1 DESCRIPTION By the end of this committee meeting, we will have a language that is arbitrarily extensible in accordance with decades of computer programming practice. Perl6 is NOT a quick hack done to save implementor time. It is a carefully crafted piece of fine work. It is correct. Having put all this work into it, we would like to see this version stick around a while, in the way of Knuth's TeX language or [pick your favorite historical math figure]'s [particular lasting contribution.] =head1 IMPLEMENTATION Since versioning is a meta-implementation issue, all that is required is that fearless leader has to agree this is a good idea. Furthermore, the deadlines will be arbitrarily extended. The first release will be 6, and then each subsequent release may or may not extend a digit. =head1 REFERENCES TeX FAQ
RFC 142 (v1) Enhanced Pack/Unpack
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Enhanced Pack/Unpack
=head1 VERSION
Maintainer: Edwin Wiles <[EMAIL PROTECTED]>
Date: 22 Aug 2000
Version: 1
Mailing List: [EMAIL PROTECTED]
Number: 142
=head1 ABSTRACT
Pack and Unpack are percieved as being difficult to use, and
possibly missing desirable features.
=head1 DESCRIPTION
The existing pack and unpack methods depend upon a simple
grammar which leads to opaque format specifications, which are
often difficult to get right, and which carry no information
regarding variable names.
A more descriptive grammar, which includes variable name
associations, would make pack and unpack easier to use.
=head1 IMPLEMENTATION
Given the expressed desire to shrink the overall size of the
perl executable, this should be implemented as a seperate
module; included with the core distribution.
=head2 Definition
$foo = new Structure(...definition...);
Define a new structure type. Can use previously defined
user data types. See the section on definitions.
Structure::define( $typename, \&from_sub, \&to_sub );
Define a user data type. The 'from_sub' extracts data
from the packed form. The 'to_sub' puts data back into
the packed form. See the section on user defined types.
=head2 Input
$foo->read();
# sysread binary data from given IO reference.
$foo->set($var);
# accept binary data from normal perl
# variable.
$foo->append($var);
# append binary data to the existing data in
# the structure.
=head2 Output
$foo->write();
# syswrite binary data to given IO reference.
$var = $foo->get();
# output binary data to normal perl variable.
=head2 Maniuplation
$foo->{'name'} = $val; # set "name" to value
$val = $foo->{'name'}; # get value of "name"
[Note: There is an alternative method, using the Class::Class
method of exposing the variables via their names. That is
still a possibility, but this is deemed easier to implement at
this time.]
=head2 Data Definition
DEFINITION := '[' ELEMENTS ']'
ELEMENTS := ELEMENT [',' ELEMENTS]
ELEMENT := NAME '=>' TYPE
NAME := Text used to identify the variable for further use.
You may not use 'array', it is reserved. You may not
embed whitespace.
TYPE := ''' BASETYPE [ '/' MODIFIERS ] '''
| '[' ARRAYDEF ']'
| USERDEFINED [ '/' UDEFARGS ]
BASETYPE := 'short'
| 'long'
| 'int'
| 'double'
| 'float'
| 'char'
| 'byte'
In each of the above, unless otherwise modified, the
type defaults to the signedness, endianness, and bit
length that your system normally uses. The one
exception to this is 'char', which Unicode may cause
to be larger than a single byte, even if your system
normally considers a 'char' to be a single byte.
| 'chars' A null terminated string of characters.
If unicode is used, this may be more
than one byte per character. For use
with indefinite length strings, where
a "count" is not provided. If the
array modifier is used, then you're
expecting that many null terminated
strings.
| 'bytes' A null terminated string of bytes.
If the array modifier is used, then
you're expecting that many null
terminated strings of bytes.
[Note: Other basetypes desired can certainly be
added. It were best if they were added at this
phase. Inform me of any additional base types
desired, with justifications.]
UDEFARGS := UDEFARG [ ',' UDEFARGS ]
UDEFARG := User defined argument, meaning dependent upon user
defined code. Pretty much, any legal Perl
constant. At least, by the time it hits this
module, it better be constant.
USERDEFINED := A user defined type name, see the section on
user defined data types.
ARRAYDEF := 'array' ',' COUNT ',' ELEMENTS
[Note: Since an 'arraydef' already begins with an
otherwise special character (eg. foo => [ 'array',
10, ...]), can we eliminate the apparently redundant
'arr
