Re: Arrays: is computed
Michael Lazzaro wrote: [EMAIL PROTECTED] wrote: Shouldn't access to 'is computed' arrays be read-only? In general, I would hope that 90% of them would be, but it's been stated that it won't be a requirement. If you want such 'is computed' thingy, then tie it or wrap it in your own - IMHO. Everyone seems to need different things, so the simplest and by far the safest way is to make this explicit in your code. Hmm... real vs. fake undef... a difference between null-PMC and PMC-null, autofill with null-PMC, but assigning undef writes PMC-null... is that enough to make it work w/out speed penalty? Dan/Leopold? The array starts filled with zero's. A default value would mean, to fill each allocated array slot with a PerlUndef PMC (or a specific value respectively) which is expensive. On reading a NULL this gets converted to a new PerlUndef on the fly. I don't see, what more is necessary - and: my $val = @a[5] or $my_default; But making C and C<@a[n] = undef> do very different things, that's still scary. Powerful, but scary. People really, really want that, huh? This sould be really the same. But I could imagine to have something like @a.nullify(5); On Thursday, January 30, 2003, at 02:30 PM, Nicholas Clark wrote: I think there is a lot of scope for creating tied objects for all of this complex behaviour. Everyone has different ideas about what would be useful, Yep, exactly. Agreed. Very, very agreed. :-) DAMN, I want to start using this NOW. MikeL leo
Re: arrays, hashes unified indexing syntax impact on futurevariat ion s on other collection types [x-bayes]
Garrett Goebel <[EMAIL PROTECTED]> writes:
> From: Piers Cawley [mailto:[EMAIL PROTECTED]]
>> Garrett Goebel <[EMAIL PROTECTED]> writes:
>> >
>> > And what's to prevent that collection object from handling:
>> >
>> > my $queue = SomeQueue.new;
>> >
>> > $queue.push('foo');
>> > $queue.push('bar');
>> > $queue.push('baz');
>> >
>> > my $index_of_foo = $queue['foo']; # undef if no foo in queue.
>>
>> Because I also want to be able to access
>>
>>$nth_foo = $queue[$n]
>>
>> Which I thought was so blindingly obvious as not to need stating.
>
> Never underestimate blindingly obvious when I'm involved ;)
>
> $idx_of_foo = $queue['foo']; # named lookup
> $nth_foo= $queue[600]; # ordered lookup
>
> One is SvPOK the other SvIOK...
>
> Can't we handle both and still have the ordered lookup be fast?
No. Because in general we don't know what's in the brackets until
runtime. And then we don't know in what context to evaluate what's in
the brackets. Because, in Perl unlike in many other OO languages that
don't have a syntactic distinction between array and hash lookup, a
value can happily have both a numeric *and* a non-numeric value. Which
means that YOU CAN'T USE THE TYPE OF THE 'INDEX' OBJECT TO DETERMINE
WHETHER YOU'RE DOING A HASHLIKE OR AN ARRAYLIKE LOOKUP. As Dan pointed
out ages ago. The only reason I suggested that it didn't matter was
because I'd forgotten about the cases where having both arraylike and
hashlike behaviour was useful.
--
Piers
Re: Arrays: is computed
[EMAIL PROTECTED] wrote: Shouldn't access to 'is computed' arrays be read-only? In general, I would hope that 90% of them would be, but it's been stated that it won't be a requirement. But hey -- note that, for starters, this would mean that you could easily use an array for caching things... you could give a big hairy calculation as the C sub, and immediately store the result in the indexed location -- thus avoiding triggering the computation the next time. Pretty slick. Assuming, again, your C sub didn't return undef. If it might, you still need a separate flag to mean "real undef" vs. "haven't-gotten-around-to-it-yet undef". Which I agree sucks. Hmm... real vs. fake undef... a difference between null-PMC and PMC-null, autofill with null-PMC, but assigning undef writes PMC-null... is that enough to make it work w/out speed penalty? Dan/Leopold? But making C and C<@a[n] = undef> do very different things, that's still scary. Powerful, but scary. People really, really want that, huh? On Thursday, January 30, 2003, at 02:30 PM, Nicholas Clark wrote: I think there is a lot of scope for creating tied objects for all of this complex behaviour. Everyone has different ideas about what would be useful, and they aren't all compatible. Eliminating the speed hit from perl 5 tie and perl 5 overloading is one big reason why parrot should be nicer to work with than any language built on the perl 5 internals. Agreed. Very, very agreed. :-) DAMN, I want to start using this NOW. MikeL
Re: Arrays: Default Values
On Thursday 30 January 2003 06:49 pm, Andrew Rodland wrote: > On Wednesday 29 January 2003 09:52 pm, Rick Delaney wrote: > > On Wed, Jan 29, 2003 at 01:54:10PM -0800, Michael Lazzaro wrote: > > > On Wednesday, January 29, 2003, at 12:38 PM, Smylers wrote: > > I'd also like to point out that ruby has defaults for hashes but > > assigning nil (the equivalent of undef) does not set the default; delete > > does. > > This makes more sense to me. > [yadda yadda] Just to tone it down a bit: * Yes, that is all my "humble opinion". * Whether or not you liked my proposal, I think there's definitely a communication breakdown between people who are thinking more or less the way I am, and people who are thinking the other. And probably we could figure more things out if we quit talking past each other, as I thinl some people definitely are. :) * Yes, Perl tends to be about letting the user decide whether they want to shoot themselves in the foot -- but it's also about letting them decide when they want to be 'safe' from their own potential stupidity, right? Cheers --hobbs
Re: Arrays: Default Values
On Wednesday 29 January 2003 09:52 pm, Rick Delaney wrote: > On Wed, Jan 29, 2003 at 01:54:10PM -0800, Michael Lazzaro wrote: > > On Wednesday, January 29, 2003, at 12:38 PM, Smylers wrote: > > > That would make the rule very simple indeed: > > > > > > Assigning C to an array element causes that element to take > > > the > > > array's default value. > > > > > > The effects of this are: > > > > > > * Assigning a particular integer to an array of int or Int always > > > does > > > what it looks like it's doing, irrespective of whether or not that > > > integer is zero or whether the array happens to have a default. > > > > > > * In an array of Int, attempting to store C will, by default, > > > actually store C. If the array has a different default > > > defined then that will be stored instead. > I'd also like to point out that ruby has defaults for hashes but > assigning nil (the equivalent of undef) does not set the default; delete > does. > This makes more sense to me. Say an array has a default. If we use an uninitialized slot in the array, we should get the default. Fine -- we have to initialize the thing anyway. But I think it's much saner to have this: * Have an 'undef' or 'unset' unary operator that sets the slot to the array's default (if there is one), and if there isn't then do whatever (either set to the 'default default' or undef, or actually delete the item if it's practical -- it's a minor detail, and not really my point.) * If we try to assign undef, or 0, or whatever, to a slot, then we put the closest thing to undef or 0 that we can, and not the default. Yes, there's some merit on checking whether we're actually assigning "real undef", and not just whatever undef converts into, but that also causes some problems with copying arrays and reading data in and out. Basically, I think it amounts to handling defaults on the setting end, rather than the getting end, which seems a lot more practical to me. I think that having @a[1]=0; print @a[1]; not print '0' is scary voodoo no matter what the reason, and I like having to undefine things with something other than assignment. Possible caveat(s): * Copying arrays. If we handle the "set to default" case sloppily, and then try to copy into an array which has a different default, then some items that were supposed to be 'undefined' are now defined and have the default from the source array. Not good. * Might be inconvenient if we want to dump out to some plain-text format and read back in, as we would have to write code that's explicitly aware of the existence of a default. I'm getting long-winded here, but what it seems like is: what some people seem to be thinking has a lot of potential for hidden action and foot-shooting. What I'm saying seems to me to be 'safer' but maybe less convenient in some situations. Hrm... I think both behaviors could be done without too much pain from user code wrapping an array (even an array of primitive types), so maybe it's a moot point anyway -- just give the user the choice whether they want to risk cutting off limbs with the swiss army chainsaw. Anyway, cheers and good discussion --Andrew "hobbs" Rodland < arodland at noln.com >
Re: Arrays: Default Values
On Thu, Jan 30, 2003 at 11:41:04AM -0500, Aaron Sherman wrote: > On Wed, 2003-01-29 at 16:41, Nicholas Clark wrote: > > > And the demonstration was as expected? > > Yes, of course. If you modify a hash, or look at another hash, you > should not expect the same results. Why would you? More importantly, why > would the conversation threat up until now lead to such an example? Nothing explicit. But no-one had not said that hash ordering was the function of something deterministic based on hash keys. ie it was possible to read the thread and assume that for a hash with a given set of keys, one particular implementation would only return the keys in one implementation defined way. Some of the behaviour I demonstrated wasn't actually what I expected, but thinking about it based on how perl5 does hashes it makes sense. Now it's explicit, which hopefully is clear. I know I surprised at least one knowledgeable reader of the list with the demonstration. On Thu, Jan 30, 2003 at 11:41:30AM -0500, Aaron Sherman wrote: > They guarantee (as stated in the docs for keys, in the perlfunc manpage, > go check it out) that keys, each and values will return the elements of > the hash in the same order as each other as long as you don't modify the > hash between calls. > > If Parrot calls rand on the sequencing of returned hash data, that's > fine as long as it saves that seed until the hash is later updated I think all that Dan will want parrot to guarantee is that if you iterate completely without modifying the hash, you will get all the elements out exactly once. But parrot is also designed to remove the speed hit of tie, so if your program needs more predictable hash ordering semantics, it is intended that it be easy *and efficient* to let a custom hash do this. Possibly even a "custom" hash supplied in the core libraries. I am arm waving, but it's extrapolation from what I know the design goals are. It could be that parrot would be allowed to run under a use less 'memory' and have GC shrink hashes were possible. In fact, there's nothing stopping anyone implementing a use less 'memory' for 5.10 that causes such behaviour. Nicholas Clark
Re: Arrays: is computed
(Sorry, deleted Michael's original message, hence this messy quoting interaction) On Thu, Jan 30, 2003 at 03:11:34PM -0500, [EMAIL PROTECTED] wrote: > Shouldn't access to 'is computed' arrays be read-only? > > If you want to be able to consume the elements by shifting, > you can always create a tied object that kees a cursor and > a reference to the underlying array and gives you that > access (and it could die for splicing, etc.)... > Michael Lazzaro <[EMAIL PROTECTED]> > 01/30/2003 02:25 PM > Not saying that's wrong. Just very, very wacky. And yes, it's fixable > if every array has an "offset" number that's always updated to mark how > far the array has been shifted/unshifted from it's starting point. But > I'm not suggesting that. Really. > > MikeL I think there is a lot of scope for creating tied objects for all of this complex behaviour. Everyone has different ideas about what would be useful, and they aren't all compatible. Eliminating the speed hit from perl 5 tie and perl 5 overloading is one big reason why parrot should be nicer to work with than any language built on the perl 5 internals. Nicholas Clark
RE: Sabbatical from the list
Damian Conway:
# This is just to let everybody know that I will be
# unsubscribing from p6-lang for the foreseeable future,
# effective immediately.
I, and I'm sure the rest of the list, am sorry to see you go. Best of
luck with the job hunt and the serious design work.
(I swear, this is the last message I'm sending you from the list! ;^) )
--Brent Dax <[EMAIL PROTECTED]>
@roles=map {"Parrot $_"} qw(embedding regexen Configure)
>How do you "test" this 'God' to "prove" it is who it says it is?
"If you're God, you know exactly what it would take to convince me. Do
that."
--Marc Fleury on alt.atheism
Re: Arrays: Default Values
On Thursday, January 30, 2003, at 12:49 PM, Austin Hastings wrote: undef @a[5]; # undefining the element sets it to the default @a[5]; # 2 @a[5] = undef; # same as above @a[5]; # 2 undef!! @a is an array of Int (not int) and can store undef, so no error occurs when you make the assignment. But now I, the programmer, am saying that of my own volition I want an undef in there, not a 2. If I wanted @a[5] to take on the default value, I'd say so: C<@a[5] = @a.default;> This is operating on Damian's premise that the presence of an undefined value is what causes the default value to be raised. So we don't have two types of undef (undef but undef, etc.)... a cell is either defined, or it's not. The presence of C is what triggers the default value, regardless of how the undef got there. Thus, as Damian said, there is no way to place an undefined value in an array with a default: I'm not compelled by the counter-argument that this makes it impossible to store an C in an array with a default. Because the whole point of an array having a default is to prevent those nasty out-of-range Cs from popping up in the first place. I'll document the behavior as Damian has specified it, since he's the ranking design team member here. If a design team member overrules, we'll change it to match. MikeL
Re: Sabbatical from the list
On Thu, 2003-01-30 at 15:38, Damian Conway wrote: > This is just to let everybody know that I will be unsubscribing from > p6-lang for the foreseeable future, effective immediately. I too will be leaving this list, as I'm concerned that my recent enthusiasm has at least contributed to Damian's withdrawal. Since there's not much I can do on the library front at this stage anyway, I'm off to work on sand. Good luck all! -- Aaron Sherman <[EMAIL PROTECTED]> This message granted to the Public Domain in 2023. Fight the DMCA and copyright extension!
Re: Arrays: Default Values
--- Michael Lazzaro <[EMAIL PROTECTED]> wrote: > Right, we just can't do the 'undef' thing. OK, so let me see if this > is right yet: > > my Int @a is default(2); > @a[5] = 5; > > @a[4]; # 2 (autofilled) > @a[5]; # 5 > @a[6]; # 2 (out-of-bounds) > > undef @a[5]; # undefining the element sets it to the default > @a[5]; # 2 > > @a[5] = undef; # same as above > @a[5]; # 2 undef. I feel like the duck in those AFLAC commercials. undef! undef!! @a is an array of Int (not int) and can store undef, so no error occurs when you make the assignment. But now I, the programmer, am saying that of my own volition I want an undef in there, not a 2. If I wanted @a[5] to take on the default value, I'd say so: C<@a[5] = @a.default;> > my int @a is default(2); > > @a[4]; # 2 (autofilled) > @a[5]; # 5 > @a[6]; # 2 (out-of-bounds) > > undef @a[5]; # 0 (Warning: using undef in int context, autoconv > to 0) Like delete @a[5]. Sets value to @a.default; > @a[5] = undef; # 0 (Warning: using undef in int context, autoconv > to 0) Frankly, I think that this should be a compile time error, while $b = undef; @a[5] = $b; should be a runtime warning. > @a[5]; # 0 > > @a[5] = 0; # nothing special about this > @a[5]; # 0 > > Can everyone buy that? Sure. =Austin
Sabbatical from the list
This is just to let everybody know that I will be unsubscribing from p6-lang for the foreseeable future, effective immediately. I deeply regret that I simply no longer have the time to cope with the volume of messages being generated here. Unfortunately, the exigencies of finding paying work in this woeful economic climate, and the demands of actually moving ahead with the design and implementation of Perl 6 must take priority. I will, of course, still read Piers' excellent summaries, but otherwise I won't be monitoring the list at all from here on. It is likely that I will start reading again after A6 and E6 are released. All the best, Damian
Re: arrays, hashes unified indexing syntax impact on future varia tion s on other collection types
AAron --
I think the point is that C<$x{$foo}> says "Hey C<$x>, y'know that
unordered
mess of stuff you've been keeping track of? Get me the one tagged $foo,
woudja?" while C<$x[$n]> says "yo C<$x>! Grab me the C<$n>-th thingee
in line over there, hey!". And, nothing prevents you wanting to use a
number for a tag in the first instance (so type doesn't disambiguate).
And,
nothing prevents you having a single object that allows both types of
abuse (like the tree stuff I posted about earlier). Thus, we retain two
different
(but related) notations: one for unordered access, one for ordered access.
Any given object may support none, one or both.
Regards,
-- Gregor
Aaron Sherman <[EMAIL PROTECTED]>
01/30/2003 03:15 PM
To: Damian Conway <[EMAIL PROTECTED]>
cc: Perl6 Language List <[EMAIL PROTECTED]>
Subject:Re: arrays, hashes unified indexing syntax impact on future
varia tion s
on other collection types
On Thu, 2003-01-30 at 14:21, Damian Conway wrote:
> People, the whole argument that $a[key] should be a homonym for both
> array-like and hash-like look-ups is
... a really bad argument to have, and I would not presume. When Perl
has tried to unify syntax in that way, it has ultimately failed (as you
note) to be coherent.
My question was, are these two different semantic operations, or are
they one operation with some type-sensitivity? Do curlies actually
resolve some fundamental ambiguity? I think we've demonstrated that they
don't, other than that ambiguity which exists already in the language,
outside of indexing operations.
What was the semantic tie between select and select? Even the tie
between the various gotos was pretty tenuous, and that caused problems.
This is a case where the indexing operator on one container class is
different from the indexing operator on another. Why? Because we had so
much spare syntax lying around? No. It was because a) AWK introduced the
idea and b) Perl1..5 had a "sigle denotes access, not type" model.
Those things are not terribly relevant to Perl 6, and as such, I'm not
sure why you feel that there's an imperative to use the Perl 5 notation.
Please enlighten me, Damian. I respect your deep understanding of this
language, and I'm willing to accept that you're intuitively grasping
something that I don't. All I see now is:
namevalue
namevalue
Which would seem to be easier written as:
value
value
value
Perhaps casting it in non-Perl syntax will free us from the bonds of our
preconceptions
--
Aaron Sherman <[EMAIL PROTECTED]>
This message (c) 2003 by Aaron Sherman,
and granted to the Public Domain in 2023.
Fight the DMCA and copyright extension!
Re: Arrays: is computed
Shouldn't access to 'is computed' arrays be read-only?
If you want to be able to consume the elements by shifting,
you can always create a tied object that kees a cursor and
a reference to the underlying array and gives you that
access (and it could die for splicing, etc.)...
Regards,
-- Gregor
Michael Lazzaro <[EMAIL PROTECTED]>
01/30/2003 02:25 PM
To: [EMAIL PROTECTED]
cc:
Subject:Arrays: is computed
For C arrays, things get more complicated. Since there
are no true 'holes' in a primitive-typed array, the correct behavior
there would seem to be to autofill the array using the computed values.
For example, an empty array:
my int @a is computed { $^index ** 2 }
@a[2]; # 4 (doesn't exist, is computed)
@a[3]; # 9 (doesn't exist, is computed)
@a[4]; # 16 (doesn't exist, is computed)
Now setting an element:
@a[4] = 0;# (setting an element autofills previous elements)
# @a now contains (0,1,4,9,0)
@a[2];# 4
@a[3];# 9
@a[4];# 0
@a[5];# 25 (still doesn't exist, is computed)
@a[1000] = 0 # (calls the computed sub 1000 times, hope ya meant
it)
Again, note the dubious behavior of doing a C or other
manipulation on any C array. The autofilled portion would
shift, but the computed portion would not:
my int @a is computed { $^index ** 2 }
# at first, @a is entirely computed,
(0,1,4,9,16,25,...)
@a[4] = 0; # @a now contains (0,1,4,9,0);
# now (real) + (computed)
shift @a;# (1,4,9,0) + (16,25,...)
shift @a;# (4,9,0) + (9,16,25,...)
shift @a;# (9,0) + (4,9,16,25,...)
shift @a;# (0) + (1,4,9,16,25,...)
shift @a;# () + (0,1,4,9,16,25,...)
Not saying that's wrong. Just very, very wacky. And yes, it's fixable
if every array has an "offset" number that's always updated to mark how
far the array has been shifted/unshifted from it's starting point. But
I'm not suggesting that. Really.
MikeL
Re: arrays, hashes unified indexing syntax impact on future varia tion s on other collection types
On Thu, 2003-01-30 at 14:21, Damian Conway wrote: > People, the whole argument that $a[key] should be a homonym for both > array-like and hash-like look-ups is ... a really bad argument to have, and I would not presume. When Perl has tried to unify syntax in that way, it has ultimately failed (as you note) to be coherent. My question was, are these two different semantic operations, or are they one operation with some type-sensitivity? Do curlies actually resolve some fundamental ambiguity? I think we've demonstrated that they don't, other than that ambiguity which exists already in the language, outside of indexing operations. What was the semantic tie between select and select? Even the tie between the various gotos was pretty tenuous, and that caused problems. This is a case where the indexing operator on one container class is different from the indexing operator on another. Why? Because we had so much spare syntax lying around? No. It was because a) AWK introduced the idea and b) Perl1..5 had a "sigle denotes access, not type" model. Those things are not terribly relevant to Perl 6, and as such, I'm not sure why you feel that there's an imperative to use the Perl 5 notation. Please enlighten me, Damian. I respect your deep understanding of this language, and I'm willing to accept that you're intuitively grasping something that I don't. All I see now is: namevalue namevalue Which would seem to be easier written as: value value value Perhaps casting it in non-Perl syntax will free us from the bonds of our preconceptions -- Aaron Sherman <[EMAIL PROTECTED]> This message (c) 2003 by Aaron Sherman, and granted to the Public Domain in 2023. Fight the DMCA and copyright extension!
Fun with unified collections [was: Re: arrays, hashes unified indexing syntax impact on future varia tion s on other collection types]
A little blue-sky, here...
> > And strictly
> > speaking, its an ordered associative array right? It doesn't really
need
> > the full range of expression offered by $0{...} and $0[...]. All it
> > needs is $0[1] for ordered lookups and $0["1"] for named lookups.
>
> Nope. The array aspect returns $1, $2, $3, etc.
> The hash aspect returns the named captures.
Seems to me this dual-aspectedness could be useful in representing the
sort of tree nodes one would get from parsing XML. The hash aspect
allows access to the (unordered) attributes and the array aspect allows
access to the (ordered) child nodes. With such a collection type built-in,
perhaps embedded XML could be treated as a quote-like construct, yielding
tree values instead of string or regexp values like the other quote-like
constructs...
my $doc =
Howdy!
Hello, strange new world!
;
Not only is this handy for XML, but it may be handy also for parsers
written in Perl.
Some cleverness could be applied to come up with a set of tree-operators.
Roughly,
$doc = tgrep { ref $_ or not $_ =~ m/^\s*$/s } $doc;
would kill the whitespace-only leaf nodes in the above tree.
Perl already does great stuff with scalars and lists, but it would be nice
to see it do some new things with trees (natively).
One crude example would be an 'at' tree-path op (think XPath, I guess) --
although I expect there are superior formulations of this idea:
my $msg = $doc at "/html/body/p"; # Returns first node.
print "$msg\n"; # Prints "Hello, strange new world!\n"
Or, imagining some big HTML document already in $html, this:
my @h = $html at "h1|h2|h3"; # Returns a list of nodes.
foreach my $h (@h) {
my ($level) = $h =~ /^h(\d)$/; # Stringizes to element name
my $title = join " ", tgrep { not ref $_ } $h; # Flatten to list of
strings
print(" " x $level, $title, "\n");
}
would print a heading summary with indentation.
Perl can already do some pretty LISPy things, so why not some TREPpy
things, too?
Regards,
-- Gregor
Re: arrays, hashes unified indexing syntax impact on future varia tion s on other collection types
> X-Original-To: [EMAIL PROTECTED]
> Mailing-List: contact [EMAIL PROTECTED]; run by ezmlm
> From: Garrett Goebel <[EMAIL PROTECTED]>
> Date: Thu, 30 Jan 2003 12:13:22 -0600
> X-SMTPD: qpsmtpd/0.20, http://develooper.com/code/qpsmtpd/
>
> --_=_NextPart_001_01C2C88B.468ED3D0
> Content-Type: text/plain;
> charset="iso-8859-1"
>
> Apologies in advance for beating this dead horse...
>
> Damian Conway wrote:
> > Garrett Goebel wrote:
> >
> > > What was the reason again which Larry rejected unifying the
> > > syntax for array
> > > and hash indexing?
> >
> > Because some things have both, and do different things with each.
>
> Ok $0 is special. But isn't it _the_ special case? And strictly speaking,
> its an ordered associative array right? It doesn't really need the full
> range of expression offered by $0{...} and $0[...]. All it needs is $0[1]
> for ordered lookups and $0["1"] for named lookups.
>
> Or going back to the statement that "some things have both". Silly question
> I'm sure, but can you imagine a collection object that really needs $0[1]
> and $0{1}? And wouldn't it be a fair argument that such a collection object
> is too fancy for its own good?
>
> Hmm... $0[$!]
>
> However isn't that something the collection object should have to deal with?
> It seems like such nice thing to unify collection syntax. Then in Perl6 we'd
> have scalars and containers. We'd still give sigils to arrays and hashes as
> befits their perl heritage. Other collection objects could either be derived
> from arrays and hashes, use some other generic sigil or define their own.
Alright, it's my turn.
There is no I reason why we can't unify hash and array
indexing. It introduces some unavoidable caveats, sure, but on the
ground level, there's no real *problem* with it. We've seen PHP and
ECMAScript do it, so why can't we?
Because the designers of PHP and ECMAScript didn't have quite the
insight Larry did when he wrote Perl, in this respect at least. One
of my favorite quotes that came up here just a little while ago was
"we're not writing a turing machine...".
Why, in English, do we say:
The thing I I tripped over upset me.
but,
The person I tripped me upset me.
It's perfectly clear what is meant if you use "that" in the second
case, but the "who" just makes sure you got it. Perhaps you
mis-heard/-read "person"; the "who" makes you rethink it and
understand better.
Perl is more a natural language than any other programming language to
my knowledge. That's why its one of the only languages in which it's
fun to write. The [] / {} distinction is just a redundant clarifier
that would not be such a good idea to drop.
Those unconvinced, read on.
Consider this bit of code that you wrote 8 months ago
(hypothetically):
for blah blah $n this is too long to comprehend {
print $users{$n};
}
Another case of redundancy in your favor. Through the second line,
you understand several things that [] would never tell you if they've
been unified:
* $users is a hash (or similar data structure)
* $n is probably looping through names, not numbers.
It's about comprehensibility, and this sort of "unnecessary"
redundancy really helps us humans out when we don't have a perfect
Perl 6 parser working for our brains. Which we never do.
Luke
Re: arrays, hashes unified indexing syntax impact on future variation s on other collection types
--- Damian Conway <[EMAIL PROTECTED]> wrote:
> > What was the reason again which Larry rejected unifying the syntax
> for array
> > and hash indexing?
>
> Because some things have both, and do different things with each.
> And because some built-in redundancy is useful for error checking,
> especially on complex nested data structures.
>
>
> > As Piers said, we know whether $a is an array or hash reference
> when we do:
> >
> > print $a->{foo};
>
> No we don't. Especially if $a is $0 (i.e. the result of a pattern
> match).
> See Exegesis 5 for details.
$0 has more baggage than a gaggle of New York matrons on an extended
vacation. Please don't tell me that you want that to be the reference
definition for all arrays/hashes?
And it's neither an array nor a hash -- it's a "result", according to
A5. I'm assuming that's a magic class, no?
=Austin
RE: arrays, hashes unified indexing syntax impact on future varia tion s on other collection types
On Thu, 2003-01-30 at 13:13, Garrett Goebel wrote:
> Hmm... $0[$!]
>
> However isn't that something the collection object should have to deal with?
> It seems like such nice thing to unify collection syntax.
Actually, that's a great example, and there are certainly others.
According to Larry, that object will have both a Buddha nature and a...
er that is, a string and numeric representation. Other objects will be
able to behave in this context-sensitive manner as well.
Let me switch that one around for you:
class MyContainer {
method index($object) { ... } # index by any scalar object
method index(int $ind) { ... } # index by a number
}
my MyContainer $x;
$x.index($!);
What does *that* do? Ultimately, C<$x[$!]> is no different, and if we
have a resolution for one, we have a resolution for the other.
What's more, even if we do decide not to unify arrays and hashes (as I'm
assuming we will), I'm pretty sure we still need to answer this
question.
Options include:
* Run-time error
* Default to most generic type with warning
* Default to most generic type without warning
* Default to most specific type (huh?) with warning
* Default to most specific type without warning
I'm not sure what I meant by "most specific", but it sounded like that
should be one of the options. Can anyone else read my mind better than I
can? :)
> > And because some built-in redundancy is useful for error checking,
> > especially on complex nested data structures.
>
> I'm no one to argue with that...
True, true. And, joy of joys, that error checking is available. We can
allow a warning mode where variables with undeclared types cause
warnings like so:
module strict 'types';
my @a; # Warning/error due to lack of type
my hash @a; # No problem
I would be very distressed if we did not allow for this. We already have
warning modes in Perl 5 for auto-vivification of undefined references,
don't we? So, that case is taken care of.
Is there any other ambiguity that we should be concerned about?
About the dead-horse thing... Others have asked why we should pursue
this. My feeling is that we're grasping in the dark at some core beliefs
that we don't really have good reasons for. I'm hoping that as we poke
deeper at this, we'll find more and more of those core beliefs either
have good reasons or can be given a different form without shaking our
faith (as with the above polymorphism example). If I was willing to
"just take it on faith", I'd be programming in Java. Perl is ultimately
a deconstructionist language (as Larry has pointed out), which leads me
down the path of deconstructing *it*.
Hmm... why is it that Perl brings out the religious and social metaphors
for me? ;)
--
Aaron Sherman <[EMAIL PROTECTED]>
This message (c) 2003 by Aaron Sherman,
and granted to the Public Domain in 2023.
Fight the DMCA and copyright extension!
Re: arrays, hashes unified indexing syntax impact on future variation s on other collection types
On Thu, Jan 30, 2003 at 09:11:10AM -0800, Damian Conway wrote:
> >What was the reason again which Larry rejected unifying the syntax for
> >array
> >and hash indexing?
>
> Because some things have both, and do different things with each.
> And because some built-in redundancy is useful for error checking,
> especially on complex nested data structures.
>
>
> >As Piers said, we know whether $a is an array or hash reference when we do:
> >
> >print $a->{foo};
>
> No we don't. Especially if $a is $0 (i.e. the result of a pattern match).
> See Exegesis 5 for details.
>
>
> >Someone correct me when I go astray...
>
> See above. ;-)
>
>
> Damian
I like very much that a reference can point to an object that has
scalar, array and hash natures at once. With the current (non unified
syntax), we can very elegantly munge any kind of attributed tree: XML,
parsing tree...
In the case of XML. if the node is a leaf, the referenced entity would
be a regular scalar. Otherwise, it would be the multifacetted object
of type (say) TagNd; the scalar would be the tag name, the hash would contain the
key/attribute pairs, the array would contain the sons if any.
Example: suppose that $t is the root node of such a tree obtained by parsing:
e
f
print $t{a} ;# prints "c"
print $t[0][1]; # prints "f"
This tree (simplified) deparsing would be done like that:
sub deparseNd($n) {
return $$n if ref($n) ne 'TagNd'; # returns text of leaf node
return "<$$n" ~
(join '', map { qq|$_="$n{$_} "| } keys %$n) ~
">" ~
(join '', deparseNd $_ for @$n) ~ # should I protect for the
# possible autoinstanciation of
# of the sons array @$n (when no son?)
"
}
print deparseNd($t);
Does it make any sense?
Someone correct me where I go astray... :)
Probably there is a more elegant way to concatenate all the chunks.
BTW: Can I write "for $t" instead of "for @$t", same for "keys $t"?
Will Perl6 smart enough to autodereference when needed?
--
stef
Arrays: is computed
For C arrays, things get more complicated. Since there
are no true 'holes' in a primitive-typed array, the correct behavior
there would seem to be to autofill the array using the computed values.
For example, an empty array:
my int @a is computed { $^index ** 2 }
@a[2]; # 4 (doesn't exist, is computed)
@a[3]; # 9 (doesn't exist, is computed)
@a[4]; # 16 (doesn't exist, is computed)
Now setting an element:
@a[4] = 0;# (setting an element autofills previous elements)
# @a now contains (0,1,4,9,0)
@a[2];# 4
@a[3];# 9
@a[4];# 0
@a[5];# 25 (still doesn't exist, is computed)
@a[1000] = 0 # (calls the computed sub 1000 times, hope ya meant
it)
Again, note the dubious behavior of doing a C or other
manipulation on any C array. The autofilled portion would
shift, but the computed portion would not:
my int @a is computed { $^index ** 2 }
# at first, @a is entirely computed,
(0,1,4,9,16,25,...)
@a[4] = 0; # @a now contains (0,1,4,9,0);
# now (real) + (computed)
shift @a;# (1,4,9,0) + (16,25,...)
shift @a;# (4,9,0) + (9,16,25,...)
shift @a;# (9,0) + (4,9,16,25,...)
shift @a;# (0) + (1,4,9,16,25,...)
shift @a;# () + (0,1,4,9,16,25,...)
Not saying that's wrong. Just very, very wacky. And yes, it's fixable
if every array has an "offset" number that's always updated to mark how
far the array has been shifted/unshifted from it's starting point. But
I'm not suggesting that. Really.
MikeL
Re: arrays, hashes unified indexing syntax impact on future varia tion s on other collection types
Garrett Goebel wrote:
Ok $0 is special. But isn't it _the_ special case?
Nope. Pretty much any built-in that returns more than a single
piece of information (e.g. C, C, C, etc.)
will do the same kind of thing.
And strictly
speaking, its an ordered associative array right? It doesn't really need
the full range of expression offered by $0{...} and $0[...]. All it
needs is $0[1] for ordered lookups and $0["1"] for named lookups.
Nope. The array aspect returns $1, $2, $3, etc.
The hash aspect returns the named captures.
Or going back to the statement that "some things have both". Silly
question I'm sure, but can you imagine a collection object that really
needs $0[1] and $0{1}?
Sure. Imagine an object that stores frequency counts for input strings. It's
very likely that the frequency count for the second most common string (i.e.
$freq[1]) isn't the same thing as the frequency count for the string "1" (i.e.
$freq{1}).
And wouldn't it be a fair argument that such a
collection object is too fancy for its own good?
Not to me, no. Nor to Larry apparently, since he deliberately set up the
$0, $1, $2, etc. variables that way.
Hmm... $0[$!]
Indeed.
It seems like such nice thing to unify collection syntax.
Not to me.
See http://www.csse.monash.edu.au/~damian/papers/PDF/SevenDeadlySins.pdf
Specifically, the sections entitled "Grammatical traps" and
"Differentiate semantics with syntax".
People, the whole argument that $a[key] should be a homonym for both
array-like and hash-like look-ups is the same argument that it's
good to have two C functions, two Cs, two Cs,
two Cs, or three Cs. That has proved *not* to be a great
thing in perl 5 and Perl 6 is clearly moving away from it.
Let's move on too.
Damian
Re: Arrays: Default Values
At 10:54 AM -0800 1/30/03, Mark Biggar wrote: and if we define a prop "is no_default" then you get what ever junk happens to be in memory. (this for even more speed) That's not going to happen. It's too unsafe, and too open to corruption attacks. -- Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Arrays: Default Values
On Thursday, January 30, 2003, at 10:56 AM, Austin Hastings wrote: There is no reason why primitive-typed arrays can't have a default. It is the confusion of "default" with "undef" that is causing this problem. Yes, I misspoke. You can have a default, which it will use for autofill & out-of-range values. You just can't use undef to do it. MikeL
Re: Arrays: Default Values
Austin Hastings wrote: There is no reason why primitive-typed arrays can't have a default. It is the confusion of "default" with "undef" that is causing this problem. If I have: my int @a; print @a[4]; What comes out? Notice, there's no "is default(woo-woo)" in there. Just a plain old primitive array. I imagine that each primative type will have a default default :-) int0 str'' num0.0 etc. and if we define a prop "is no_default" then you get what ever junk happens to be in memory. (this for even more speed) -- Mark Biggar [EMAIL PROTECTED]
Re: Arrays: Default Values
--- Michael Lazzaro <[EMAIL PROTECTED]> wrote: > > On Thursday, January 30, 2003, at 12:03 AM, Leopold Toetsch wrote: > > Why do you then use a primitive type in the first place? > > > > IMHO: > > > > 1) primitive types are what they are - no undef, no attributes, > just > > e.g. plain integers (or shorts or bits ...) > > > > 2) if you want to store additional information use a "normal" perl > > variable i.e. a parrot PMC. > > > > Why on earth would we want to take advantage of primitive types - > when > > then people additionally want to tuck their birthdate on it? > > > > The array of 1e6 ints takes 1e6 words, the same array of PerlInts > > allocates ~10 times the memory and causes additional a lot of GC > > overhead. > > > > And finally, if you a need a few more bits of information for your > > IntArray[1e6], then wrap it into your own array class - we are > > speaking of perl here - or do we? > > > I think this is a tremendously valuable point. The idea behind > primitive types is that they are "small" and "fast" compared to full > types. If you ask for them, you are explicitly saying you're willing > > to give up a lot of functionality in order to gain maximum > efficiency. > > It's not that we want to avoid making Perl6 too slow. It's that we > want to actively try and make it *fast*. When dealing with primitive > > types -- for large image manipulation, for example -- every spent > clock > cycle matters. We MUST allow some mechanism in Perl6 -- short of > escaping to C -- by which algorithms can be tweaked to have some > degree > of efficiency. > > This is leading me to the conclusion that primitive-typed arrays > should > not be allowed to have defaults, period, and that attempting to place > > one should be a compile-time error. If you want a default, use > C instead of an C, and it will work fine. There is no reason why primitive-typed arrays can't have a default. It is the confusion of "default" with "undef" that is causing this problem. If I have: my int @a; print @a[4]; What comes out? Notice, there's no "is default(woo-woo)" in there. Just a plain old primitive array. =Austin
RE: arrays, hashes unified indexing syntax impact on futurevariat ion s on other collection types [x-bayes]
From: Piers Cawley [mailto:[EMAIL PROTECTED]]
> Garrett Goebel <[EMAIL PROTECTED]> writes:
> >
> > And what's to prevent that collection object from handling:
> >
> > my $queue = SomeQueue.new;
> >
> > $queue.push('foo');
> > $queue.push('bar');
> > $queue.push('baz');
> >
> > my $index_of_foo = $queue['foo']; # undef if no foo in queue.
>
> Because I also want to be able to access
>
>$nth_foo = $queue[$n]
>
> Which I thought was so blindingly obvious as not to need stating.
Never underestimate blindingly obvious when I'm involved ;)
$idx_of_foo = $queue['foo']; # named lookup
$nth_foo= $queue[600]; # ordered lookup
One is SvPOK the other SvIOK...
Can't we handle both and still have the ordered lookup be fast?
--
Garrett Goebel
IS Development Specialist
ScriptPro Direct: 913.403.5261
5828 Reeds Road Main: 913.384.1008
Mission, KS 66202 Fax: 913.384.2180
www.scriptpro.com [EMAIL PROTECTED]
Re: Arrays: Default Values
On Thursday, January 30, 2003, at 09:55 AM, Dan Sugalski wrote: At 9:53 AM -0800 1/30/03, Michael Lazzaro wrote: This is leading me to the conclusion that primitive-typed arrays should not be allowed to have defaults, period, and that attempting to place one should be a compile-time error. If you want a default, use C instead of an C, and it will work fine. This isn't necessarily an issue for low-level arrays/hashes. We've got to fill the new elements with something when we extend internal structures, so there's no reason not to set the default. Doesn't mean the default should be a value that can fall outside the range that's OK for the low-level type, but... Right, we just can't do the 'undef' thing. OK, so let me see if this is right yet: my Int @a is default(2); @a[5] = 5; @a[4]; # 2 (autofilled) @a[5]; # 5 @a[6]; # 2 (out-of-bounds) undef @a[5]; # undefining the element sets it to the default @a[5]; # 2 @a[5] = undef; # same as above @a[5]; # 2 my int @a is default(2); @a[4]; # 2 (autofilled) @a[5]; # 5 @a[6]; # 2 (out-of-bounds) undef @a[5]; # 0 (Warning: using undef in int context, autoconv to 0) @a[5] = undef; # 0 (Warning: using undef in int context, autoconv to 0) @a[5]; # 0 @a[5] = 0; # nothing special about this @a[5]; # 0 Can everyone buy that? MikeL
Re: arrays, hashes unified indexing syntax impact on futurevariat ion s on other collection types [x-bayes]
Garrett Goebel <[EMAIL PROTECTED]> writes:
> Piers Cawley wrote:
>> Garrett Goebel <[EMAIL PROTECTED]> writes:
>> >
>> > What was the reason again which Larry rejected unifying the
>> > syntax for array and hash indexing? As Piers said, we know
>> > whether $a is an array or hash reference when we do:
>> >
>> > print $a->{foo};
>>
>> But as someone else pointed out, there may be classes that have both
>> hashlike and arraylike interfaces. For instance:
>>
>>my $queue = SomeQueue.new;
>>
>>$queue.push('foo');
>>$queue.push('bar');
>>$queue.push('baz');
>>
>>my $index_of_foo = $queue{'foo'}; # undef if no foo in queue.
>
> And what's to prevent that collection object from handling:
>
> my $queue = SomeQueue.new;
>
> $queue.push('foo');
> $queue.push('bar');
> $queue.push('baz');
>
> my $index_of_foo = $queue['foo']; # undef if no foo in queue.
Because I also want to be able to access
$nth_foo = $queue[$n]
Which I thought was so blindingly obvious as not to need stating.
--
Piers
RE: arrays, hashes unified indexing syntax impact on futurevariat ion s on other collection types [x-bayes]
Piers Cawley wrote:
> Garrett Goebel <[EMAIL PROTECTED]> writes:
> >
> > What was the reason again which Larry rejected unifying the
> > syntax for array and hash indexing? As Piers said, we know
> > whether $a is an array or hash reference when we do:
> >
> > print $a->{foo};
>
> But as someone else pointed out, there may be classes that have both
> hashlike and arraylike interfaces. For instance:
>
>my $queue = SomeQueue.new;
>
>$queue.push('foo');
>$queue.push('bar');
>$queue.push('baz');
>
>my $index_of_foo = $queue{'foo'}; # undef if no foo in queue.
And what's to prevent that collection object from handling:
my $queue = SomeQueue.new;
$queue.push('foo');
$queue.push('bar');
$queue.push('baz');
my $index_of_foo = $queue['foo']; # undef if no foo in queue.
--
Garrett Goebel
IS Development Specialist
ScriptPro Direct: 913.403.5261
5828 Reeds Road Main: 913.384.1008
Mission, KS 66202 Fax: 913.384.2180
www.scriptpro.com [EMAIL PROTECTED]>
RE: arrays, hashes unified indexing syntax impact on future varia tion s on other collection types
Apologies in advance for beating this dead horse...
Damian Conway wrote:
> Garrett Goebel wrote:
>
> > What was the reason again which Larry rejected unifying the
> > syntax for array
> > and hash indexing?
>
> Because some things have both, and do different things with each.
Ok $0 is special. But isn't it _the_ special case? And strictly speaking,
its an ordered associative array right? It doesn't really need the full
range of expression offered by $0{...} and $0[...]. All it needs is $0[1]
for ordered lookups and $0["1"] for named lookups.
Or going back to the statement that "some things have both". Silly question
I'm sure, but can you imagine a collection object that really needs $0[1]
and $0{1}? And wouldn't it be a fair argument that such a collection object
is too fancy for its own good?
Hmm... $0[$!]
However isn't that something the collection object should have to deal with?
It seems like such nice thing to unify collection syntax. Then in Perl6 we'd
have scalars and containers. We'd still give sigils to arrays and hashes as
befits their perl heritage. Other collection objects could either be derived
from arrays and hashes, use some other generic sigil or define their own.
> And because some built-in redundancy is useful for error checking,
> especially on complex nested data structures.
I'm no one to argue with that...
--
Garrett Goebel
IS Development Specialist
ScriptPro Direct: 913.403.5261
5828 Reeds Road Main: 913.384.1008
Mission, KS 66202 Fax: 913.384.2180
www.scriptpro.com [EMAIL PROTECTED]
Re: Arrays: Default Values
At 9:53 AM -0800 1/30/03, Michael Lazzaro wrote: This is leading me to the conclusion that primitive-typed arrays should not be allowed to have defaults, period, and that attempting to place one should be a compile-time error. If you want a default, use C instead of an C, and it will work fine. This isn't necessarily an issue for low-level arrays/hashes. We've got to fill the new elements with something when we extend internal structures, so there's no reason not to set the default. Doesn't mean the default should be a value that can fall outside the range that's OK for the low-level type, but... -- Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Arrays: Default Values
On Thursday, January 30, 2003, at 12:03 AM, Leopold Toetsch wrote: Why do you then use a primitive type in the first place? IMHO: 1) primitive types are what they are - no undef, no attributes, just e.g. plain integers (or shorts or bits ...) 2) if you want to store additional information use a "normal" perl variable i.e. a parrot PMC. Why on earth would we want to take advantage of primitive types - when then people additionally want to tuck their birthdate on it? The array of 1e6 ints takes 1e6 words, the same array of PerlInts allocates ~10 times the memory and causes additional a lot of GC overhead. And finally, if you a need a few more bits of information for your IntArray[1e6], then wrap it into your own array class - we are speaking of perl here - or do we? I think this is a tremendously valuable point. The idea behind primitive types is that they are "small" and "fast" compared to full types. If you ask for them, you are explicitly saying you're willing to give up a lot of functionality in order to gain maximum efficiency. It's not that we want to avoid making Perl6 too slow. It's that we want to actively try and make it *fast*. When dealing with primitive types -- for large image manipulation, for example -- every spent clock cycle matters. We MUST allow some mechanism in Perl6 -- short of escaping to C -- by which algorithms can be tweaked to have some degree of efficiency. This is leading me to the conclusion that primitive-typed arrays should not be allowed to have defaults, period, and that attempting to place one should be a compile-time error. If you want a default, use C instead of an C, and it will work fine. MikeL
Re: arrays, hashes unified indexing syntax impact on future variation s on other collection types
Garrett Goebel <[EMAIL PROTECTED]> writes:
> Joseph F. Ryan wrote:
>> Stéphane Payrard wrote:
>> >
>> >I think that arrays and associative tables are very
>> >different entities for two reasons:
>> > -type of keys. array keys are integers
>> > -cost of insertion and deletion operations: O(n) and
>> > lower for associative table ( O(1) if you don't care
>> > for key ordering, O(log(n)) if you care for ordering).
>> >
>> >This is enough to warrant different syntaxes for arrays and hash.
>>
>> I'm sure I'll get shot for saying this, but no it doesn't.
>> PHP arrays are simply associative arrays with a integer as
>> the key value.
>
> What was the reason again which Larry rejected unifying the syntax for array
> and hash indexing? As Piers said, we know whether $a is an array or hash
> reference when we do:
>
> print $a->{foo};
But as someone else pointed out, there may be classes that have both
hashlike and arraylike interfaces. For instance:
my $queue = SomeQueue.new;
$queue.push('foo');
$queue.push('bar');
$queue.push('baz');
my $index_of_foo = $queue{'foo'}; # undef if no foo in queue.
--
Piers
Re: arrays, hashes unified indexing syntax impact on future variation s on other collection types
What was the reason again which Larry rejected unifying the syntax for array
and hash indexing?
Because some things have both, and do different things with each.
And because some built-in redundancy is useful for error checking,
especially on complex nested data structures.
As Piers said, we know whether $a is an array or hash reference when we do:
print $a->{foo};
No we don't. Especially if $a is $0 (i.e. the result of a pattern match).
See Exegesis 5 for details.
Someone correct me when I go astray...
See above. ;-)
Damian
Re: Arrays: Default Values
At 11:41 AM -0500 1/30/03, Aaron Sherman wrote: On Wed, 2003-01-29 at 17:12, Dan Sugalski wrote: At 12:40 PM -0500 1/29/03, Aaron Sherman wrote: >Elements of a has ARE ordered, just not the way you may expect. Just to nip this one in the bud... The bud was back that-a-way about 3 days I was trying a different tack. Apparently the "Larry said we're not changing brace notation" one wasn't effective. But, I've long since decided that we're not going to re-think those symbols because they're part of the root language, not the dialect. Then why persist in bringing it up, or not leaving it be when it does get brought up? -- Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
arrays, hashes unified indexing syntax impact on future variation s on other collection types
Joseph F. Ryan wrote:
> Stéphane Payrard wrote:
> >
> >I think that arrays and associative tables are very
> >different entities for two reasons:
> > -type of keys. array keys are integers
> > -cost of insertion and deletion operations: O(n) and
> > lower for associative table ( O(1) if you don't care
> > for key ordering, O(log(n)) if you care for ordering).
> >
> >This is enough to warrant different syntaxes for arrays and hash.
>
> I'm sure I'll get shot for saying this, but no it doesn't.
> PHP arrays are simply associative arrays with a integer as
> the key value.
What was the reason again which Larry rejected unifying the syntax for array
and hash indexing? As Piers said, we know whether $a is an array or hash
reference when we do:
print $a->{foo};
Someone correct me when I go astray...
Currently in Perl6 you can assign an anonymous array or hash to a scalar as
follows:
$a = [1,2,3];
$b = {a => 1, b => 2};
or
$a = array(1,2,3);
$b = hash(a => 1, b => 2);
If arrays and hashes both settled on []:
$a = [1,2,3];
$b = [a => 1, b => 2];
or
$a = array(1,2,3);
$b = hash(a => 1, b => 2);
It'd mess up the explicit list and hash composer syntax [] and {}. After all
if unified, what's:
$b = [a => 1, b => 2];
An anonymous array of ordered key/value pairs or an anonymous hash?
If this could be resolved in a way which would allow us to translate our
expectations of Perl5 arrays and hashes into Perl6... Wouldn't it give us a
standard syntax for working with collections? So we could punt on Bags,
Sets, Dictionaries, OrderedCollections, etc. and all the variations on
arrays and hashes that people are suggesting. I.e., Deliver a version of
standard Perl arrays and hashes... and make provisions for, but leave the
rest out of the core.
$bag = bag(1,2,1);
print "ok" if 2 == scalar $bag->[1];
@a = (1,2,3);
%h = (a => 1);
%oh is ordered = (a => 1);
©c is bag = (1,2,1); # (C) symbol or some other sigil
Re: Arrays: Default Values
On Wed, 2003-01-29 at 17:50, Spider Boardman wrote: > On 29 Jan 2003 14:29:52 -0500, Aaron Sherman wrote (in part): > > ajs> As for the argument that testing for true non-existentness is a > ajs> burden, check out the way Perl5 does this. Hint: there's a central > ajs> sv_undef, and that's not what array buckets are initialized to > > Either you're dead wrong, or you typo'd there. After > > my @a; > $a[4] = 1; > > The array buckets @a[0..3] most certainly ARE initialized to &PL_sv_undef This has changed since I last (long ago) looked at the source for av.c. It once was the case that av_fetch could return NULL for uninitialized cells, which is why it returns an C instead of an C. It now looks like you're right and newly allocated cells are given a default "undeffing". None the less, the point is valid. We do not HAVE to fill newly allocated arrays with undef. That yeilds a perfectly respectable non-existent case. The question is, do we *want* to do that and is it suitable to the current Parrot implementation? -- Aaron Sherman <[EMAIL PROTECTED]> This message (c) 2003 by Aaron Sherman, and granted to the Public Domain in 2023. Fight the DMCA and copyright extension!
Re: Arrays: Default Values
On Wed, 2003-01-29 at 17:12, Dan Sugalski wrote: > At 12:40 PM -0500 1/29/03, Aaron Sherman wrote: > >Elements of a has ARE ordered, just not the way you may expect. > > Just to nip this one in the bud... The bud was back that-a-way about 3 days > If people start assuming that there's *any* ordering to hashes, I > promise I *will* make sure that parrot's external hash class starts > returning keys and values in random order. > Hashes have no guarantee of ordering, and perl 5 (as Nick > demonstrated) delivers on that lack of guarantee. They guarantee (as stated in the docs for keys, in the perlfunc manpage, go check it out) that keys, each and values will return the elements of the hash in the same order as each other as long as you don't modify the hash between calls. If Parrot calls rand on the sequencing of returned hash data, that's fine as long as it saves that seed until the hash is later updated No one has suggested, as far as I can tell, that hashes should order their values internally in any particular way. What I have suggested (and I think culture shock is a bad, but sufficient reason to say that Perl isn't going this way) is that arrays and hashes and trees and funny macaroni pictures don't need separate funky tokens to identify their naming and indexing. Indexing is easy, as far as I can tell. C<%a["fire"]> is totally non-ambiguous. C<$a["fire"]> depends on the type of reference in C<$a>. If C<$a> is undefined, then you need a default, but defaulting auto-vivification based on the type of the index seems pretty intuitive to me. PHP does something like this, though I don't think that it implements actual arrays at the lowest level, it just fakes them with hashes. Perl is ok with context, so there's less concern about having arrays and hashes behave differently. No biggie. On the naming side, I like the idea of tossing C<%>, but I'm not sure you can. C<%> and C<@> have a unique and interesting behavior that is hard to manage otherwise. That is, they determine how assignments between containers behave. The idea that C<@a=%b> and C<%a=%b> are non-ambiguous is actually rather clever, and I'm not sure how to get that cleanly without ending up in a bit of a pickle over C<@a=(@b=(%c=@d))> But, I've long since decided that we're not going to re-think those symbols because they're part of the root language, not the dialect. It would be like suggesting that regular expressions should be delimited by a function-call interface instead of matched tokens. Perl programmers just don't think that way. No matter the merits of the suggestion, it's not a debate over how it *should* be done, but rather over how it *is* done. I know I sound a little shouty, here. Sorry, it's my style. I respect you all a great deal, and that's why I think this debate was worth spending a couple of days on. Thanks all. -- Aaron Sherman <[EMAIL PROTECTED]> This message (c) 2003 by Aaron Sherman, and granted to the Public Domain in 2023. Fight the DMCA and copyright extension!
Re: Arrays: Default Values
On Wed, 2003-01-29 at 16:41, Nicholas Clark wrote: > And the demonstration was as expected? Yes, of course. If you modify a hash, or look at another hash, you should not expect the same results. Why would you? More importantly, why would the conversation threat up until now lead to such an example? -- Aaron Sherman <[EMAIL PROTECTED]> This message (c) 2003 by Aaron Sherman, and granted to the Public Domain in 2023. Fight the DMCA and copyright extension!
Re: Arrays: Default Values
On 29 Jan 2003 14:29:52 -0500, Aaron Sherman wrote (in part): ajs> As for the argument that testing for true non-existentness is a ajs> burden, check out the way Perl5 does this. Hint: there's a central ajs> sv_undef, and that's not what array buckets are initialized to Either you're dead wrong, or you typo'd there. After my @a; $a[4] = 1; The array buckets @a[0..3] most certainly ARE initialized to &PL_sv_undef in p5. That's how C knows to return false (&PL_sv_no) instead of true (&PL_sv_yes). And, yes, C re-sets that slot to point to the one true central undef again. This is different from what happens on C -- that actually makes a new SV which is a *copy* of the central undef and makes that the new value in that slot. Thus, even with just the above sequence, C would now be true in p5. Please, folks, this discussion's getting complicated enough without making mistaken claims about what p5 currently does, even when that's by accident. -- Spider Boardman (at home) [EMAIL PROTECTED] The management (my cats) made me say this.http://users.rcn.com/spiderb/ PGP public key fingerprint: 96 72 D2 C6 E0 92 32 89 F6 B2 C2 A0 1C AB 1F DC
Re: Arrays: Default Values
Jonathan Scott Duff wrote: The solution I advocate is to allow even "primitive" types to hold undef. Why do you then use a primitive type in the first place? IMHO: 1) primitive types are what they are - no undef, no attributes, just e.g. plain integers (or shorts or bits ...) 2) if you want to store additional information use a "normal" perl variable i.e. a parrot PMC. Why on earth would we want to take advantage of primitive types - when then people additionally want to tuck their birthdate on it? The array of 1e6 ints takes 1e6 words, the same array of PerlInts allocates ~10 times the memory and causes additional a lot of GC overhead. And finally, if you a need a few more bits of information for your IntArray[1e6], then wrap it into your own array class - we are speaking of perl here - or do we? -Scott leo
