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 belg4mit
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 belg4mit at MIT dot EDU
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 belg4mit
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 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
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 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 belg4mit at MIT dot EDU
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 currentSNIP
Say what?
--tom
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 currentSNIP
:
: 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 belg4mit at MIT dot EDU
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 belg4mit at MIT dot EDU
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
Casey R. Tweten wrote:
Removing intermediate data structures is easy in Perl, but not this case,
Ceach, 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 Ceach, Ckeys, and Cvalues 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
[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 Barray 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 Barray context An archaic expression for what is more correctly referred to as Ilist context =item Bhash An unordered association of Ikey/Ivalue pairs, stored such that you can easily use a string Ikey to look up its associated data value. 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 Bhash table A data structure used internally by Perl for implementing associative arrays (hashes) efficiently. See also Ibucket. =item BLIST A syntactic construct representing a comma-separated list of expressions, evaluated to produce a Ilist value. Each Iexpression in a RLIST is evaluated in a Ilist context and interpolated into the list value. =item Blist An ordered set of scalar values, =item Blist context The situation in which an Iexpression is expected by its surroundings (the code calling it) to return a list of values rather than a single value. Functions that want a RLIST of arguments tell those arguments that they should produce a list value. See also Icontext. 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: functions that deal with hash should be more libera
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: Mon, 21 Aug 2000 19:04:27 EDT
From: Jerrad Pierce belg4mit
No. keys() expects something that starts with a %, not
something that starts with a .
That's lame though because I can do stuff like:
print join(' ', splice(@{[1,2,3,4,5,6,7,8,9,0]}, 3, 3));
Unless perl is internally checking that splice is a CORE
function and thusly deemed magical, (seems unlikely, bad and un-perl like),
join will allow me to give it something that "starts with "
And
sub foo { return (1,2,3,4); };
print join(' ', foo);
certainly seems to work.
So bascially my point is:
If a hash array function is handed a list, it should treat that list
as though it is the hash or array it would like it to be.
You know, that inherrent sense of Doing The Right 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 Pungenday, the 14th of Bureaucracy, in the YOLD 3166:
``How did it get so late so soon? It's night before it's afternoon. December is here
before it's June. My goodness how the time has flewn. How did it get so late so
soon?'' -Dr. Seuss
