"RA" == Russ Allbery [EMAIL PROTECTED] writes:
RA Damien Neil [EMAIL PROTECTED] writes:
Arrays are ordered. Hashes are not. Sure, you can iterate over a hash,
but add an element to one and you can change the order of everything in
it.
RA Formally, I believe it's permissable for
On Tue, Aug 15, 2000 at 11:46:04PM -0400, Stephen P. Potter wrote:
Why is it silly? Hashes and arrays are *conceptually* very similar (even
if they are extremely different implementation-wise). One of them has
implicit key, the other has an explicit key. They both provide some sort
of
Damien Neil [EMAIL PROTECTED] writes:
Arrays are ordered. Hashes are not. Sure, you can iterate over a hash,
but add an element to one and you can change the order of everything in
it.
Formally, I believe it's permissable for a hash implementation to return a
different order the second
Lightning flashed, thunder crashed and "Jeremy Howard" [EMAIL PROTECTED] whispered:
| No, neither proposal makes sense. Arrays can be stored compactly and
|
| $a[1_000_000_000] = 'oh, really?' # :-)
|
| my int @a: sparse;
| $a[1_000_000_000] = 'Yes, really!' # :P
|
| OK, so I cheated...
Stephen P. Potter wrote:
Lightning flashed, thunder crashed and "Jeremy Howard" [EMAIL PROTECTED]
whispered:
| No, neither proposal makes sense. Arrays can be stored compactly and
|
| $a[1_000_000_000] = 'oh, really?' # :-)
|
| my int @a: sparse;
| $a[1_000_000_000] = 'Yes,
At 11:46 PM 8/15/00 -0400, Stephen P. Potter wrote:
Lightning flashed, thunder crashed and Dan Sugalski [EMAIL PROTECTED] whispered:
| Doesn't it make more sense to get rid of arrays and just use hashes?
|
| I guess it depends on what you think makes sense; but it seems to me
| that an array
Lightning flashed, thunder crashed and Russ Allbery [EMAIL PROTECTED] whispere
d:
| Arrays are ordered. Hashes are not. Sure, you can iterate over a hash,
| but add an element to one and you can change the order of everything in
| it.
|
| Formally, I believe it's permissable for a hash
"Stephen P. Potter" [EMAIL PROTECTED] writes:
Lightning flashed, thunder crashed and Russ Allbery [EMAIL PROTECTED] whispere
d:
| Arrays are ordered. Hashes are not. Sure, you can iterate over a hash,
| but add an element to one and you can change the order of everything in
| it.
|
Nathan Torkington wrote:
Perl makes easy things easy. Hashes are bloody useful, as the last
decade of Perl has borne out. They deserve syntactic support because
they're used a lot and are worthy of a shorthand.
my @aa :assoc;
$aa['foo'] = 'bar';
Is no one getting my
Jarkko Hietaniemi wrote:
Arrays can be stored compactly and
$a[1_000_000_000] = 'oh, really?' # :-)
But that is far less common than
@a{ 0..100 } = (...);
which, if stored in a hash, would not only be significantly less
efficient than an array, but could generally be expected to elicit
At 11:09 AM 8/16/00 -0400, John Porter wrote:
Dan Sugalski wrote:
Numbers and strings really aren't different things, at least not as far as
people are concerned. They are for machines, but computer languages
ultimately aren't for machines, they're for people.
I guess I can't fault you
On Wed, Aug 16, 2000 at 12:48:12PM -0400, Dan Sugalski wrote:
At 11:09 AM 8/16/00 -0400, John Porter wrote:
The difference between numbers and strings is analogous to --
or, on further reflection, IDENTICAL to -- the difference between
arrays and associative arrays. (The former are
* John Porter ([EMAIL PROTECTED]) [17 Aug 2000 03:02]:
Nathan Torkington wrote:
John Porter writes:
I really don't feel that strongly about it!
If you think something is good, then argue for it. If you don't,
don't.
I *do* think it's good. I'm arguing for it because it's
[EMAIL PROTECTED] (Nathan Torkington) wrote on 15.08.00 in
[EMAIL PROTECTED]:
Stephen P. Potter writes:
Why is it silly? Hashes and arrays are *conceptually* very similar
(even if they are extremely different implementation-wise).
If that were the case, I think students would have an
At 09:49 PM 8/16/00 +0200, Kai Henningsen wrote:
[EMAIL PROTECTED] (Dan Sugalski) wrote on 15.08.00 in
[EMAIL PROTECTED]:
At 06:04 PM 8/15/00 -0400, John Porter wrote:
Dan Sugalski wrote:
Generality good.
For many things, yes. For computers, say. For people, no. Generality
Dan Sugalski writes:
Unfortunately, I think you're somewhat under-informed as to the inherent
capabilities of people's brains.
Ok, at this point I think all parties have to step away and let the
RFCs fall where they will.
It's obvious that there are two types of people: those who don't mind
Well said!
Nathan Torkington wrote:
Dan Sugalski writes:
Unfortunately, I think you're somewhat under-informed as to the inherent
capabilities of people's brains.
Ok, at this point I think all parties have to step away and let the
RFCs fall where they will.
It's obvious that there
"KH" == Kai Henningsen [EMAIL PROTECTED] writes:
KH Hashes and arrays, OTOH, really aren't different for people. The concept
KH of an index needing to be a nonnegative number is a computer concept.
I don't know about that. Good old PL/I had arbitrary ranges for array
indices.
Hmm, I feel an
Chaim Frenkel wrote:
"KH" == Kai Henningsen [EMAIL PROTECTED] writes:
KH Hashes and arrays, OTOH, really aren't different for people. The
concept
KH of an index needing to be a nonnegative number is a computer concept.
I don't know about that. Good old PL/I had arbitrary ranges for array
Stephen P. Potter wrote:
Lightning flashed, thunder crashed and John Porter [EMAIL PROTECTED] whispered
:
| Here's a counter-proposal: throw out hashes as a separate internal
| data type, and in its place define a set of operators which treat
| (properly constructed) arrays as associative
At 03:53 PM 8/15/00 -0400, John Porter wrote:
Stephen P. Potter wrote:
Lightning flashed, thunder crashed and John Porter [EMAIL PROTECTED]
whispered
:
| Here's a counter-proposal: throw out hashes as a separate internal
| data type, and in its place define a set of operators which
Dan Sugalski wrote:
Generality good.
For many things, yes. For computers, say. For people, no. Generality bad.
Specificity and specialization good. People aren't generalists. They're a
collection of specialists. The distinction is important.
I'm sorry if I don't find this argument
At 06:04 PM 8/15/00 -0400, John Porter wrote:
Dan Sugalski wrote:
Generality good.
For many things, yes. For computers, say. For people, no. Generality bad.
Specificity and specialization good. People aren't generalists. They're a
collection of specialists. The distinction is important.
Stephen P. Potter wrote:
Lightning flashed, thunder crashed and John Porter [EMAIL PROTECTED]
whispered
:
| Here's a counter-proposal: throw out hashes as a separate internal
| data type, and in its place define a set of operators which treat
| (properly constructed) arrays as associative
On Wed, Aug 16, 2000 at 08:37:21AM +1000, Jeremy Howard wrote:
Stephen P. Potter wrote:
Lightning flashed, thunder crashed and John Porter [EMAIL PROTECTED]
whispered
:
| Here's a counter-proposal: throw out hashes as a separate internal
| data type, and in its place define a set of
Jarkko Hietaniemi wrote:
On Wed, Aug 16, 2000 at 08:37:21AM +1000, Jeremy Howard wrote:
Stephen P. Potter wrote:
Lightning flashed, thunder crashed and John Porter [EMAIL PROTECTED]
whispered
:
| Here's a counter-proposal: throw out hashes as a separate internal
| data type, and
At 05:41 PM 8/15/00 -0500, Jarkko Hietaniemi wrote:
No, neither proposal makes sense. Arrays can be stored compactly and
$a[1_000_000_000] = 'oh, really?' # :-)
Now, now, there have been credible proposals for sparse arrays, you know
that...
--
Peter Scott
Pacific Systems Design
No, neither proposal makes sense. Arrays can be stored compactly and
$a[1_000_000_000] = 'oh, really?' # :-)
my int @a: sparse;
I see: you have a time machine and I don't. So very unfair...
$a[1_000_000_000] = 'Yes, really!' # :P
OK, so I cheated... I haven't submitted my RFC
John Porter writes:
I think as long as equivalent (and better!) functionality is available,
through equivalently terse syntax, who's to care? Why is
$h{'foo'} = 'bar';
instrinsically preferable to
assoc( %h, 'foo', 'bar' );
I'm horrified you have to ask this question.
Lightning flashed, thunder crashed and Dan Sugalski [EMAIL PROTECTED] whispered:
| Doesn't it make more sense to get rid of arrays and just use hashes?
|
| I guess it depends on what you think makes sense; but it seems to me
| that an array is a more fundamental data type; that it's easier
Stephen P. Potter writes:
Why is it silly? Hashes and arrays are *conceptually* very similar
(even if they are extremely different implementation-wise).
If that were the case, I think students would have an easier time
grasping hashes. It seems very common (yes yes, you all got them
Dan Sugalski wrote:
At 05:55 PM 8/15/00 -0500, Jarkko Hietaniemi wrote:
No, neither proposal makes sense. Arrays can be stored compactly
and
$a[1_000_000_000] = 'oh, really?' # :-)
my int @a: sparse;
I see: you have a time machine and I don't. So very unfair...
Need
Piers Cawley wrote:
$ints_from = ^1 = sub {$ints_from-(^1+1)};
$ints = $ints_from-(1);
I think pairs should use array range syntax ".." and be folded
into the array generator RFC (or at least referenced in that RFC).
In particular, using a pair in an array context should interpret
the
I think the idea that = is "just another comma" is pretty widespread
now.
Just for the record I've always thought this was stupid. That's just my
opinion, true, but there's a fine line between TMTOWTDI and pure
confusion.
IMO, if you're going to have a different operator, make it do something
Peter Scott [EMAIL PROTECTED] writes:
At 07:29 PM 8/10/00 -0700, Glenn Linderman wrote:
Thanks for the clarification in your intentions, but isn't _any_ bareword is
converted to a string, unless it is in some particular context where a
bareword is
meaningful (such as filehandle)? So that seems
=head1 TITLE
Replace = (stringifying comma) with = (pair constructor)
=head1 VERSION
Maintainer: Damian Conway [EMAIL PROTECTED]
Date: 10 August 2000
Version: 1
Mailing List: [EMAIL PROTECTED]
Number: 84
I like this a lot, especially the way it deals with subroutine
On Thu, 10 Aug 2000 17:59:52 -0700, Glenn Linderman wrote:
I find nothing in the documentation that suggests that = is anything other than a
plain comma operator, yet you call it a "first-argument-stringifying comma
operator". In fact, the documentation explicitly claims "=" is a synonym of ","
On Thu, Aug 10, 2000 at 10:21:37PM -, Perl6 RFC Librarian wrote:
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Replace = (stringifying comma) with = (pair constructor)
=head2 Pairs and arrays
When a pair reference is assigned (in)to an
On Fri, Aug 11, 2000 at 11:24:48AM +1000, Damian Conway wrote:
This can be correctly handled. The named parameter's context specifier
would be propagated to the right operand of the =. So:
sub demo ( $name, \%options ) {...}
will accept:
demo(options=%myopts, name='my
"Glenn" == Glenn Linderman [EMAIL PROTECTED] writes:
Glenn No, but the documentation for strict is some of what I reread
Glenn before making a fool of myself arguing with Damian, and it says
Glenn nothing about barewords, as far as I could read.
Even this part? ...
strict subs
On Fri, 11 Aug 2000 11:01:30 -0400 (EDT), Simply Hao wrote:
What about with -w:
read = $value
What warning?
Oh, you're probably using a pre-5.005 Perl. 5.004 (the latest MacPerl,
for example) still had that warning. 5.005 and later, do not, any more.
--
Bart.
I kinda like it. It's... intuitive. It makes named sub arguments rather
straightforward, apart from that prefix thing.
Should (name = 'Bart') really stuff 'Bart' into a lexical variable
$name? That's... odd.
Not really. If (name='Bart') is an arg list, it probably stuffs
@array = ( a=1, b=2, 'c', 3 );
assigns four elements (not six) to @array.
But won't this cause breakage to existing scripts
No. p52p6 will simply translate:
x = 'y'
to
'x', 'y'
Note that these semantics still support the popular:
But... would it be possible to exten this proposal so that, if the right
hand operand is an array or hash variable, it will create a reference to
this variable?
That would allow subroutine calls like:
foo('names' = @names, 'size' = 'A4', 'labels' = %labels)
to do
[EMAIL PROTECTED] writes:
: p52p6 would handle it (by translating all Perl 5 Cx="y"'s to Perl 6
: C'x',"y"'s.
:
: I *must* put this in the RFC!
I think most of the RFCs could use a MIGRATION POLICY section, or
some such.
Larry
Nathan Wiger wrote:
...if the "key" and "value" builtins were the only ways to
get to the data. You should be able to get to the data directly.
How about:
$array[0].k
$array[0].v
--
John Porter
Damian Conway [EMAIL PROTECTED]:
This RFC proposes the introduction of a new data type -- the Ipair -- and
the co-opting of the = operator to act as a pair constructor. Most existing
uses of = would be preserved.
[etc.]
%hash = ( a=1, b=2, 'c', 3 );
does what it does in Perl 5,
On Fri, 11 Aug 2000 15:27:03 +0200, Bart Lateur wrote:
I kinda like it.
I'm not sure any more if I still like it as much. As proposed, it seems
very unperlish (as we know Perl today). It would virtually turn Perl
into a whole different language. Well, half a different language. ;-)
I, too,
I guess I shouldn't use printed docs for anything in these discussions. I looked that
up on paper, and it really does (did) say "synonym". But things change. I'd tell you
what version of paper I looked it up on, but the paper doesn't seem to have recorded
its version number. Perl 5.something.
Piers Cawley [EMAIL PROTECTED] writes:
Damian Conway [EMAIL PROTECTED] writes:
Are the two values of a pair restricted in anyway? All your examples
were scalar.
Yes. The two components must be scalars.
The key is stringified iff it's a bareword.
Otherwise no restrictions.
Perl6 RFC Librarian wrote:
[...]
This RFC proposes the introduction of a new data type -- the Ipair
[...]
I hereby propose that all current Perl 6 Project Plan deadlines
be extended 3 months so that Damian has more time to come up
with gems like this. I have no idea if it ultimately makes
Damian Conway wrote:
When a pair reference is assigned (in)to an array, it remains a
single scalar (referential) value. So:
@array = ( a=1, b=2, 'c', 3 );
assigns four elements (not six) to @array.
The proposed Ckey and Cvalue built-ins (or the
Shades of LISP, batman.
tongue in cheek
I can see it now, the '=' operator will be called cons-ing.
And the new keword for accessing a pair will be CAR and CDR.
/tongue in cheek
Are the two values of a pair restricted in anyway? All your examples
were scalar. What about a plural whatzit or a
Are the two values of a pair restricted in anyway? All your examples
were scalar.
Yes. The two components must be scalars.
The key is stringified iff it's a bareword.
Otherwise no restrictions.
What about a plural whatzit or a reference to a plural
whatzit?
References are
I find nothing in the documentation that suggests that = is
anything other than a plain comma operator, yet you call it a
"first-argument-stringifying comma operator". In fact, the
documentation explicitly claims "=" is a synonym of "," (see
perldata).
The Perl documentation
Glenn Linderman wrote:
Thanks for the clarification in your intentions, but isn't _any_ bareword
is
converted to a string, unless it is in some particular context where a
bareword is
meaningful (such as filehandle)? So that seems to be nothing unique to
=. You
could just as well say
56 matches
Mail list logo
