Re: Spare brackets :-)
On 28 Jan 2003, Aaron Sherman wrote:
> I'm not sure I recall the sufficient, yet irrelevant technical reasons.
> I certainly can't think of anything. It also helps in the case of
> objects that are non truly arrayish or hashish:
>
> my SuperTree $foo;
> $foo["Munge"]; # Returns the node whose value is "Munge"
> $foo[0]; # Returns a node based on tree-position
>
> The only remaining behavior of braces that I can think of as different
> from brackets is auto-quoting, and is there a good reason that brackets
> could not auto-quote?
I think you are still overlooking the autovivification behavior.
i.e. What is the difference between these:
1) $a{1234567} = 1;
2) $a[1234567] = 1;
Answer: #1 creates 1 element. #2 creates 1,234,567 elements!
I think that is a big enough difference that perl should not be asked
to guess.
Similar precendents are + vs ~, == vs eq, etc.
~ John Williams
Re: Spare brackets :-)
On Tue, Jan 28, 2003 at 12:11:18PM +1300, [EMAIL PROTECTED] wrote: > This may sound like a silly idea but ... > > Has anyone considered removing with the syntactic distinction between > numeric and string indexing -- that is, between array and hash lookup? PHP works this way. http://www.php.net/manual/en/language.types.array.php So that makes a nice case study to investigate. -- Michael G. Schwern <[EMAIL PROTECTED]>http://www.pobox.com/~schwern/ Perl Quality Assurance <[EMAIL PROTECTED]> Kwalitee Is Job One
Re: Spare brackets :-)
>> In particular, it would seem that
>> %foo[$key]
>> would be just as easy for the compiler to grok as
>> %foo{$key}
On Mon, 27 Jan 2003 15:39:19 -0800, Damian Conway <[EMAIL PROTECTED]> wrote:
> Sure. But then is this:
>
> $ref[$key]
>
> an array or hash look-up???
Yes, well I suppose that could be considered one of the things I hadn't figured
out yet.
But is seems to me that if we're changing "$X[$n]" to "@X[$n]", then it would
be more consistent to change "$ref->[$key]" to "@$ref[$key]". Except of course
that mixing prefix and postfix notation is horrible, so perhaps "$ref@[$key]" and
"$ref%[$key]". (I'd assumed that "%[" and "@[" would be single symbols?)
> Decided at runtime?
That might be OK, except (as others have pointed out) for auto-vivification,
where the object doesn't exist before we operate on it.
Maybe we would get away with the shorthand "$ref[$index]" *except* where
autovivification is desired, and then we'd have to use the long-hand
"$ref@[$index]" and "$ref%[$index]" versions?
Hm, actually, I think I could class that as a feature, if the reader --
human or compiler -- could know just by looking whether auto-viv is expected.
-Martin
Re: Spare brackets :-)
On Wed, 29 Jan 2003 18:04, Michael G Schwern wrote:
> On Tue, Jan 28, 2003 at 12:11:18PM +1300, [EMAIL PROTECTED] wrote:
> > This may sound like a silly idea but ...
> >
> > Has anyone considered removing with the syntactic distinction between
> > numeric and string indexing -- that is, between array and hash lookup?
>
> PHP works this way.
> http://www.php.net/manual/en/language.types.array.php
>
> So that makes a nice case study to investigate.
Stick this in yer pipe n smoke it. I haven't actually written the module
yet, just the man page. But I think it might just be crazy enough to
implement :-).
The restriction that a key is a scalar and a value is a blessed object
could be removed, but it was a useful pre-condition for my use.
The DWIMy function that tells the difference between an int and a string is
at the end.
=head1 NAME
Container::Object - set/array/hash/bag/whatever of objects
=head1 SYNOPSIS
use Container::Object;
$coll = Container::Object->new();
push @$coll, foo => (bless { }, "bar");
print ref $coll{foo}; # prints "bar"
print ref $coll[0]; # prints "bar"
print ref( ($coll->members)[0] ); # prints "bar"
=head1 DESCRIPTION
This modules implements a generic container of objects, that is, an
unordered, ordered, or keyed collection of objects, with or without
duplication of items.
This means that depending on how you treat your container, it
automagically behaves like a Set, Bag, Array, Hash or some perverse
combination of a subset of the above.
=head2 EH?
In the beginning, there was the array. Then Larry empowered the Hash
with Perl. Some other geezer followed up with C, hashes
that also retain ordering. Jean-Louis Leroy wrote C,
which was a bit like an array but without the ordering, and no
duplicate elements. And Java as well as PHP have a poorly considered
bastard half and half mix of the two.
This container class tries to implement as many of the above classes
as possible, with DWIM and no more than O(log n) execution time being
the overriding principle.
=head2 Keys vs Values
Keys to objects in Container::Objects MUST be unblessed,
non-overloaded, scalar values. You can supply a tied scalar wherever
a key is accepted, but the value is read once.
Values MUST be blessed objects. They can be scalars, hashes,
references, whatever. It doesn't really matter.
=head2 Indexes vs Keys
A very DWIMy function is used to tell the difference between a string
that is intended for use as a hash key, and a whole number that is
intended for use as an index lookup.
This is required to get correct behaviour from looking up the element
at index 0, versus the item with hash key "0".
=head2 Duplicate Items
It is possible to have two objects with the same hash key, or even
indeed an object may appear twice in the container with a single hash
key.
However, if objects are to be fetched by (hash) key, and duplicate
objects are found, the I object inserted with that key is
returned (that is, the one with the highest numerical index). This
emulates the behaviour of a hash.
To avoid unnecessary, stale or duplicate entries in the container
lying around, you can use the C method instead of C
to put your objects in.
=head2 Key Fabrication
If objects are inserted without hash keys, they are inserted with an
empty hash key (from a user's perspective; internally a hash is
computed from the object's address in memory for objects with
undefined keys so the container is still well balanced).
If objects are inserted with hash keys, they are added to the logical
end of the container.
=head2 Algorithms and execution time
Simple N-bucket hashing with complete re-indexing is used for
simplicity of the code and speed for the general target case.
Each bucket contains a series of hash table entries, which is an array
of pointers to C structures and Cs. Each entry also contains
a reference to the next entry in the numerical index, and copy of its
hash key to fill the bucket entry to four CPU words.
The bucket index is a flat array of pointers, plus a flat array of
C<(index # => pointer)> pairs to various points in the index array
chain; so that inserts can be performed in near constant time (the
index is merely updated).
=head1 CLASS METHODS
=head2 new( [ [ I =E ] I] ... )
Return a new C containing the elements passed in
I. The elements must be objects. Keys are optional.
=head1 INSTANCE METHODS
=head2 insert( [ [ I =E ] I] ... )
Add objects to the C.
Adding the same object several times is not an error, but any
C will contain at most one occurance of the same
hash key/object pair, and the numeric index always remains continuous,
no holes, starting at zero. Returns the number of elements that were
actually added.
When adding elements to the collection's numerical index, inserts into
the list at the decided (or given) position.
=head2 replace( [ [ I =E ] I] ... )
Replaces objects in the C.
Virtually identical to C, but likes to replace element
Re: Spare brackets :-)
John Williams wrote:
I think you are still overlooking the autovivification behavior.
i.e. What is the difference between these:
1) $a{1234567} = 1;
2) $a[1234567] = 1;
Answer: #1 creates 1 element. #2 creates 1,234,567 elements!
Not currently: 2) does
- generate a sparse hole between old size and up to ~index
- generate one data chunk near index
- store the PerlInt at index
Reading non existent data in the hole generates then PerlUndef's on the fly.
~ John Williams
leo
Re: Arrays: Default Values
On Tue, 2003-01-28 at 19:24, Paul Johnson wrote:
> > If that's not the case, I need to get my head around why, since Perl
> > *does* distinguish between defined and exists.
>
> But I wish it wouldn't for arrays. That only came about to support
> pseudo-hashes which are going / have gone away.
>
> Are you suggesting that hashes should also have a default? That would
> seem consistent and at least as useful as arrays having a default.
Yes, I would expect that. In my opinion there is no difference between
an array and a hash other than the underlying storage and the
type-management of the key. I'm increasingly of the opinion that a)
there should be no @ vs %, there should be no {} vs [], there should be
a keys, values, defined, delete, exists, push, pop, shift, unshift for
every container and foreach shouldn't give a damn.
But, that would be a different language, and Perl has hashes and arrays.
So, the most we can do is make them not work too differently.
--
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 2003-01-29 at 09:44:27, Aaron Sherman wrote:
> Yes, I would expect that. In my opinion there is no difference between
> an array and a hash other than the underlying storage and the
> type-management of the key.
Perhaps it is your opinion that those should be the only differences,
but the actual differences, at least in existing languages, are
a matter of fact. :) Every language I know of which supports both
types distinguishes between them - even those which use the same
subscripting syntax for both. So the distinctions must be important.
1. Ordering. The elements of an array have a defined order. The elements
of a hash do not.
2. Contents. Arrays are a collection of values. Hashes are a collection
of key/value associations. The indices in an array are just a by-product
of the above fact that the values are ordered; there is no intrinsic
association between, say, the number 1 and the second element.
A consequence is that, even when the underlying implementation
allows them to be sparse, arrays conceptually do not have any missing
elements. If you create a brand new array by giving it a 5,000th
item, then the first 4,999 items are logically there even if they're
not taking up any memory. (What their value should be is the subject of the
parallel thread on array defaults).
For example: People keep bringing up JavaScript, so let's look
at that language. It is true that JavaScript arrays are implemented
on top of hashes. Every object in JavaScript, including an array, is
an associative array/hash. But Arrays are a special class because they have
the concept of a length. You can give any object properties
associated with numeric keys, but only Arrays have their length
field automatically updated; furthermore, this is magic that cannot be
duplicated by user code:
a = new Array
a[2] = 'baz'
a.length=> 3
o = new Object
o[2] = 'baz'
o.length=> undefined
> I'm increasingly of the opinion that a)
> there should be no @ vs %, there should be no {} vs [], there should be
> a keys, values, defined, delete, exists, push, pop, shift, unshift for
> every container and foreach shouldn't give a damn.
Okay, let's look at adding hash operators to arrays first.
1. keys. Easy enough - return 0..a.length
2. values. Easy, if redundant. a.values is identical to a itself.
3. defined. Sure. Any value in Perl may be defined or not, no matter
what sort of container it's in.
4. delete. No reason you can't remove an element from an array,
but it's effectively a splice - the later elements move
down.
5. exists. exists(a[i]) ::== 0 <= i < a.length
Now let's look at array operators on hashes.
1. push.As long as the argument is a Pair, I guess this
makes sense. h.push( k => v ) ::= h{k} = v
2. pop. Problem: no ordering. There is no "last" value.
which one should this remove?
3. shift. ditto.
4. unshift. identical to push.
My point boils down to this: the semantics are fundamentally different no
matter how similar or different the syntax is.
--
Mark REED| CNN Internet Technology
1 CNN Center Rm SW0831G | [EMAIL PROTECTED]
Atlanta, GA 30348 USA | +1 404 827 4754
Re: Arrays: Default Values
On 2003-01-29 at 10:32:58, Mark J. Reed wrote: > (What their value should be is the subject of the > parallel thread on array defaults). Whups, that would be THIS thread, actually. The sidebar on removing the syntactic distinction between arrays and hashes made me think I was over in the "Spare brackets" thread. Sorry. -- Mark REED| CNN Internet Technology 1 CNN Center Rm SW0831G | [EMAIL PROTECTED] Atlanta, GA 30348 USA | +1 404 827 4754
Re: Spare brackets :-)
--- Sam Vilain <[EMAIL PROTECTED]> wrote:
> =head2 includes( [ I, ] [ I ])
Where the and/or are obviously junctions.
if ($container.includes(any("ant", "beaver", "cow", "duck"))(
...
This is *SO* cool.
=Austin
Re: Arrays: Default Values
--- Jonathan Scott Duff <[EMAIL PROTECTED]> wrote: > Can I flame you for being too preemptive? :-) In all honesty, I just wanted to be able to use "absquatulate" in a real post. ;-) =Austin
Re: More Array Behaviors
--- Nicholas Clark <[EMAIL PROTECTED]> wrote: > On Tue, Jan 28, 2003 at 09:17:36AM -0800, Damian Conway wrote: > > Errno. That's rather the whole point of C properties [*]. > > > [*] People, we just *have* to find better names for these things! > > I'd suggest we henceforth call them "value" properties (for > C) > > and "referent" properties (for C). > > Over on [EMAIL PROTECTED] there seemed to be confusion about > attributes > and properties, given that some languages use one where we use the > other. > I had a dig in a thesaurus, I suggested that "chattels" and "virtues" > were interesting words that unambiguously describe respectively extra > data > you've attached to a thing, and an extra qualities you've given it. > But that's still only one (controversial) word for properties, and we > need two. > And I don't really like "chattels", whereas"virtues" sits nicely with > "bless". > Obviously, values are pure and therefrom spring "virtues," while objects are but vile clay -- fallible constructs of a sinful man, pathetically trying to recreate an envisioned ideal. Ergo, they have naught but "vices." Can I get an "Amen," brothers and sisters? =Austin
Re: More Array Behaviors
On Wed, Jan 29, 2003 at 07:46:43AM -0800, Austin Hastings wrote: > Obviously, values are pure and therefrom spring "virtues," while > objects are but vile clay -- fallible constructs of a sinful man, > pathetically trying to recreate an envisioned ideal. Ergo, they have > naught but "vices." > > Can I get an "Amen," brothers and sisters? I'm not sure. I thought about vices, but I can remember that Larry doesn't like the idea of a "curse" function to un-bless things, so I suspect that "vices" aren't going to see much favour. "flaws", maybe. There's always scope for redeeming your flaws. :-) Nicholas Clark
Re: More Array Behaviors
--- Nicholas Clark <[EMAIL PROTECTED]> wrote:
> On Wed, Jan 29, 2003 at 07:46:43AM -0800, Austin Hastings wrote:
> > Obviously, values are pure and therefrom spring "virtues," while
> > objects are but vile clay -- fallible constructs of a sinful man,
> > pathetically trying to recreate an envisioned ideal. Ergo, they
> have
> > naught but "vices."
> >
> > Can I get an "Amen," brothers and sisters?
>
> I'm not sure. I thought about vices, but I can remember that Larry
> doesn't
> like the idea of a "curse" function to un-bless things, so I suspect
> that "vices" aren't going to see much favour. "flaws", maybe. There's
> always scope for redeeming your flaws. :-)
>
> Nicholas Clark
Of course not. The opposite of bless in this case would be
"excommunicate."
Can we replace croak and carp with "damn" and "darn"?
Can I say:
CATCH {
when mortal { ... }
when venal { ... }
}
I think that having "begone" and "exorcise" as keywords would probably
rock. Plus, we could write "Perl Catechism"(*). How cool would that be?
(I'm going to "heck" for this, I'm sure. :-) :-) :-)
=Austin
(*) That title is MINE.
Re: Arrays: Default Values
Ok, I'll respond to a couple of points, below, but I think a lot of
folks are confusing some operational concepts here, and it's getting
hard to un-peel them.
A container has many attributes, even if Perl won't let us control them.
Those include:
1. Storage
2. Conversion of the whole container to another type
3. Type assigned to keys (array: int, hash: scalar)
3.5 Type used to compare/order keys (array: int, hash: string)
4. Type assigned to values
5. Value which keys default to
6. Value which values default to
7. Behavior on normal instantiation (@a=(1,2,3))
8. Behavior on sparse instantiation (@a[2]=3)
9. Behavior on lazy instantiation (@a=(1..Inf))
10. How other types are converted on input
11. Syntax for indexing
12. Syntax for listifying
13. Syntax for holistic container access
14. Methods available
3 and 4 vs 5 and 6 are an interesting thing to get your brain around.
When you talk about an array having a default value, I don't think of
that as controlling 1..5, 7 or 10..14. I do see it having an effect on 6
and possibly an effect on 8 and 9 depending on implementation.
That is to say that C<@a[10] = $mumble> shouldn't care about the default
value for that array. I'm not defaulting it. If the default TYPE for
that array doesn't handle the value that I'm trying to store, then type
conversion comes into play, and as someone pointed out and undef might
become 0 for arrays of ints. But if the default value for my array of
ints is 100, then why on earth would assigning it undef result in 100
and not 0?!
I could see defining an atomic type which has an alternate conversion
for an undefined value. So, for example, you might have an alternate
type of int that converts undef to 100. Then, of course, assigning undef
to an element of an array of such values should give you 100, AND
assigning undef to an element of an array of such values that defaults
to 200 should still yield 100!
Now again, we have to ask how much of this Perl is going to let us do. I
have no idea, and don't want to suggest one way or the other. But, to
mash them together into one operation restricts future expansion far too
much.
On Wed, 2003-01-29 at 10:32, Mark J. Reed wrote:
> 1. Ordering. The elements of an array have a defined order. The elements
>of a hash do not.
I mentioned storage. Unless your container semantics demand a sort
before searching or listing, the underlying storage impacts ordering.
Elements of a has ARE ordered, just not the way you may expect.
> 2. Contents. Arrays are a collection of values. Hashes are a collection
>of key/value associations. The indices in an array are just a by-product
>of the above fact that the values are ordered; there is no intrinsic
>association between, say, the number 1 and the second element.
Arrays are a collection of key/value pairs, where the key is stored by
virtue of positioning in order to save space and increase access time.
Don't start thinking that that information is lost! Of course there's an
association between 1 and the second element. What you meant to say is
that there's no storage allocated to the number 1, because we can infer
the key's value based on position.
> 4. delete. No reason you can't remove an element from an array,
> but it's effectively a splice - the later elements move
> down.
I disagree. This would un-exists an item, and leave it in a state that
would require auto-vivification if it were accessed in future.
> 5. exists. exists(a[i]) ::== 0 <= i < a.length
This is a mistake, since you're going to end up claiming that something
exists when it literally does not.
> Now let's look at array operators on hashes.
>
> 1. push.As long as the argument is a Pair, I guess this
> makes sense. h.push( k => v ) ::= h{k} = v
Well, the argument would be a list of Pairs, actually.
> 2. pop. Problem: no ordering. There is no "last" value.
> which one should this remove?
There is no problem. It will pop the Pair that would be last if you
converted to a list. That might be massively expensive to determine, but
as long as the documentation warns the same way it does for converting
to a list, then you're not causing any new problems.
You keep asserting that there's no ordering to Hashes, but that's not
true. I don't blame you, even the Perl docs get it wrong sometimes.
>From the P5 docs:
perldata: "Hashes are unordered collections of scalar values
indexed by their associated string key."
perlfunc/keys: "order is subject to change in future versions of
perl, but it is guaranteed to be the same order as either the
"values" or "each" function produces"
So, they're not "unordered". They just have an ordering that you can't
rely on if you
Re: More Array Behaviors
On Wed, Jan 29, 2003 at 03:52:22PM +, Nicholas Clark wrote: > On Wed, Jan 29, 2003 at 07:46:43AM -0800, Austin Hastings wrote: > > Obviously, values are pure and therefrom spring "virtues," while > > objects are but vile clay -- fallible constructs of a sinful man, > > pathetically trying to recreate an envisioned ideal. Ergo, they have > > naught but "vices." > > > > Can I get an "Amen," brothers and sisters? > > I'm not sure. I thought about vices, but I can remember that Larry doesn't > like the idea of a "curse" function to un-bless things, so I suspect > that "vices" aren't going to see much favour. "flaws", maybe. There's > always scope for redeeming your flaws. :-) What about appendage or adjunct then: Appendage \Ap*pend"age\, n. 1. Something appended to, or accompanying, a principal or greater thing, though not necessary to it, as a portico to a house. [1913 Webster] Adjunct \Ad"junct`\, n. 1. Something joined or added to another thing, but not essentially a part of it. [1913 Webster] andrew -- Aries: (March 21 - April 19) You will come very close to acting heroically when you push an old lady out of the way of a hurtling bus and underneath a cement truck. msg13218/pgp0.pgp Description: PGP signature
Re: Arrays: Default Values
OK, I think we agree that 'default' refers to what to put in the 'holes' of an array (or hash, but that's a separate discussion.) When you overlay a real hash on top of your default values, the default values "show through the holes". So now we just have to define what "holes" are. An assertion: The 'is default' property overrides the default 'empty' value of the given underlying type. For a normal array of scalars, that 'empty' value is C. But some scalar types can be set to undef, and some can't: my @a; # 'empty' value of a scalar is undef my int @a_int; # 'empty' value of an 'int' is 0 my str @a_str; # 'empty' value of a 'str' is '' my Int @a_Int; # 'empty' value of an 'Int' is undef (right?) my Str @a_Str; # 'empty' value of a 'Str' is undef (right?) So C> is defining the value to use as the 'empty value' of the _underlying cell type_. There are two credible choices, AFAICT: Solution 1: If you attempt to SET a cell to it's 'empty value', it will be set to it's default: my int @a is default(5); # @a[5] = 0;# actually sets it to it's 'empty value', 5 @a[5] = undef;# autocnv to 0, + warning, still sets to 5 my Int @a is default(5); # NOTE difference in type! @a[5] = 0;# THIS really does set it to 0 @a[5] = undef;# and this sets it to 5 So you can't set something to its type's own empty value, because it will, by definition, thereafter return it's "overloaded" empty value, . Solution 2: _ANY_ other solution would require the introduction of 'fake empty' and 'really empty', and require arrays to keep track of the difference. my Int @a is default(5); @a[3] = 3; # there are now 4 items in the array @a[2]; # was autoset to undef, so returns 5 @a[4]; # doesn't exist, so returns 5 @a[2] = undef; # well, it's still undef, but now mark it # as a 'real' undef, so don't return 5. This is essentially adding another layer of defined-ness on each cell, and therefore requires an additional flag be kept & checked for each array element. While this is certainly a possibility, I worry about the complexity it introduces. - In spite of the perhaps surprising nature of solution 1, I think it is probably the more correct solution, if you really insist on putting a default value on a primitive-typed array. As it points out, you can still get both behaviors, simply by choosing int vs. Int, str vs. Str, etc. If you want behavior more complicated than that, I think you probably should be creating a custom Array subclass. Comments? MikeL
Re: Arrays: Default Values
> Solution 1: If you attempt to SET a cell to it's 'empty value', it
> will be set to it's default:
>
> my int @a is default(5); #
> @a[5] = 0;# actually sets it to it's 'empty value',
>
> 5
> @a[5] = undef;# autocnv to 0, + warning, still sets to
> 5
>
> my Int @a is default(5); # NOTE difference in type!
> @a[5] = 0;# THIS really does set it to 0
> @a[5] = undef;# and this sets it to 5
>
> So you can't set something to its type's own empty value, because it
> will, by definition, thereafter return it's "overloaded" empty value,
> .
> -
>
> In spite of the perhaps surprising nature of solution 1, I think it is
> probably the more correct solution, if you really insist on putting a
> default value on a primitive-typed array. As it points out, you can
> still get both behaviors, simply by choosing int vs. Int, str vs. Str,
> etc.
OK, it sounds reasonable to me, for those cases where the 'empty value' is
undef ...
but if I have an array of #s ...
I have the list of people I invited to my wedding.
I default the # of people attending to 2 (inviting couples or "& Friend") ...
Joe responds, he's coming alone (ok, so i set him to a 1)
Karen is bringing her kids (so 4)
Fred can't come. That's a 0. Which is a 2. But he's not coming, so the
2 is really a 0, but I can't say 0, b/c 0 is "empty" and becomes "default"
2 ...
Likewise for strings. I default it to explicitly say "UNKNOWN" so I know
what's not known, but now when I find out it doesn't exist ("What's John
Doe's middle name?") I can't say that. The answer then is "UNKNOWN" so
"John Doe" became "John UNKNOWN Doe" due to a flawed (IMO) functional
limitation ...
This is also why i (somewhat facetiously) suggested "undef but really",
although it doesn't help in this case b/c I'm wanting to set it to 0, and
saying "attendees[23] = 0 but really" looks wrong ... so maybe the "but
really" would be for setting to default ('empty value') if you had need
and used it in assignment (but undef @attendees[23] would, i think, still
make it 'empty val' b/c i'm not assigning a value to it, i'm unassigning
the value I've given it, which is a distinction that I think may be
relevant ...)
--attriel
Re: Arrays: Default Values
--- Michael Lazzaro <[EMAIL PROTECTED]> wrote:
>
> OK, I think we agree that 'default' refers to what to put in the
> 'holes' of an array (or hash, but that's a separate discussion.)
> When
> you overlay a real hash on top of your default values, the default
> values "show through the holes". So now we just have to define what
> "holes" are.
>
> An assertion: The 'is default' property overrides the default
> 'empty'
> value of the given underlying type. For a normal array of scalars,
> that 'empty' value is C. But some scalar types can be set to
> undef, and some can't:
>
> my @a; # 'empty' value of a scalar is undef
> my int @a_int; # 'empty' value of an 'int' is 0
> my str @a_str; # 'empty' value of a 'str' is ''
I understand these, and they seem to make sense.
> my Int @a_Int; # 'empty' value of an 'Int' is undef
> (right?)
> my Str @a_Str; # 'empty' value of a 'Str' is undef
> (right?)
It's going to be "undef but 0" or "undef but ''", but since type
promotion will handle that automatically, yes.
> So C> is defining the value to use as the 'empty
> value' of the _underlying cell type_.
And therefore, if you try to specify an invalid for the
_underlying cell type_, you should get an error, either compile time or
run-time, as soon as it gets noticed.
my int @a is default "foo"; # Compile time error.
my int @a is default $param1; # Run time error if $param1 is bogus.
> There are two credible choices, AFAICT:
>
> Solution 1: If you attempt to SET a cell to it's 'empty value', it
> will be set to it's default:
>
> my int @a is default(5);
> @a[5] = 0;# actually sets it to it's 'empty value', 5
> @a[5] = undef;# autocnv to 0, + warning, still sets to 5
>
> my Int @a is default(5); # NOTE difference in type!
> @a[5] = 0;# THIS really does set it to 0
> @a[5] = undef;# and this sets it to 5
>
> So you can't set something to its type's own empty value, because it
> will, by definition, thereafter return it's "overloaded" empty value,
> .
I believe that I completely understand what you are saying. I am sure
that I absolutely disagree with what I believe I understand you to be
saying.
my $answer is (";-)" but true);
[[ This is quoted out of order, but addresses 1, above. --agh ]]
> In spite of the perhaps surprising nature of solution 1, I think it
> is probably the more correct solution, if you really insist on
> putting a default value on a primitive-typed array. As it
> points out, you can still get both behaviors, simply by choosing
> int vs. Int, str vs. Str, etc.
> Solution 2: _ANY_ other solution would require the introduction of
> 'fake empty' and 'really empty', and require arrays to keep track of
> the difference.
>
> my Int @a is default(5);
>
> @a[3] = 3; # there are now 4 items in the array
> @a[2]; # was autoset to undef, so returns 5
> @a[4]; # doesn't exist, so returns 5
>
> @a[2] = undef; # well, it's still undef, but now mark it
> # as a 'real' undef, so don't return 5.
>
> This is essentially adding another layer of defined-ness on each
> cell, and therefore requires an additional flag be kept & checked
> for each array element. While this is certainly a possibility, I
> worry about the complexity it introduces.
You're confusing specification with implementation, again.
I don't propose to require "really empty" and "fake empty". What I
propose is that:
1- If a range of values gets "strongly implied", like @a[2] in your
example, then they should be populated with the default value. After
all, it's the default.
2- If a range of values are "waekly implied", as in the examples
provided by Leopold Tesch:
@a[12345678] = 1;
@a[12000];
The "interior" values haven't actually been created because the array
is in "sparse" mode.
Any read from them will return @a.default, in your example 5.
3- Any action which serves to destroy, delete, defenestrate, or
absquatulate (I love that word!) the value will cause the value to
return the default value once again, whether it's
allocated-but-destroyed (@a[2]) or unallocated (@a[12000]).
4- Any explicit action by the programmer is taken as gospel, or as
close to it as possible via promotion:
my int @a is default(5);
@a[2] = undef; # Warning: 'undef' used where primitive 'int' expected.
@a[2]; # 0, because int(undef) is 0.
delete @a[2];
@a[2]; # 5, because deleting restores the default.
my Int @a is default(5); # NOTE: type change.
@a[2] = undef; # undef, because according to you this is okay.
# (I'm not being sarcastic -- you're the
# "edge cases" guy.)
@a[2]; # undef, because that's what the programmer told me.
delete @a[2];
@a[2]; # 5, because it's the default, as above.
Now: Does this require a "fake undef" and a "real undef"?
WHO CARES?
That's p6-internals. I think that it coul
Re: Arrays: Default Values
On Wed, Jan 29, 2003 at 10:23:26AM -0800, Michael Lazzaro wrote:
> OK, I think we agree that 'default' refers to what to put in the
> 'holes' of an array (or hash, but that's a separate discussion.) When
> you overlay a real hash on top of your default values, the default
> values "show through the holes". So now we just have to define what
> "holes" are.
Holes are undefined things.
> An assertion: The 'is default' property overrides the default 'empty'
> value of the given underlying type. For a normal array of scalars,
> that 'empty' value is C. But some scalar types can be set to
> undef, and some can't:
>
> my @a; # 'empty' value of a scalar is undef
> my int @a_int; # 'empty' value of an 'int' is 0
> my str @a_str; # 'empty' value of a 'str' is ''
>
> my Int @a_Int; # 'empty' value of an 'Int' is undef (right?)
> my Str @a_Str; # 'empty' value of a 'Str' is undef (right?)
>
> So C> is defining the value to use as the 'empty
> value' of the _underlying cell type_.
I'd say that "undef" is the universal out-of-bounds value that can be
applied to any type or aggregate to show the absense of value
("empty"). It's just that undef autovivifies to different things
depending on how the thing was declared.
> There are two credible choices, AFAICT:
>
> Solution 1: If you attempt to SET a cell to it's 'empty value', it
> will be set to it's default:
>
> my int @a is default(5); #
> @a[5] = 0;# actually sets it to it's 'empty value',
> 5
> @a[5] = undef;# autocnv to 0, + warning, still sets to 5
>
> my Int @a is default(5); # NOTE difference in type!
> @a[5] = 0;# THIS really does set it to 0
> @a[5] = undef;# and this sets it to 5
>
> So you can't set something to its type's own empty value, because it
> will, by definition, thereafter return it's "overloaded" empty value,
> .
Looks like a maintenance nightmare to me. If you always think of
undef as the empty value, then @a[5] = 0 gives the sixth element in
the array the value of 0 and @a[5] = undef gives the sixth element the
undefined value (or the default value if defaulting applies).
> Solution 2: _ANY_ other solution would require the introduction of
> 'fake empty' and 'really empty', and require arrays to keep track of
> the difference.
>
> my Int @a is default(5);
>
> @a[3] = 3; # there are now 4 items in the array
> @a[2]; # was autoset to undef, so returns 5
> @a[4]; # doesn't exist, so returns 5
>
> @a[2] = undef; # well, it's still undef, but now mark it
> # as a 'real' undef, so don't return 5.
Strange. I was thinking of the default value as what you get when you
don't know what goes there (how do you know when you don't know? Easy:
if it's undef, you don't know)
my int @a is default(5);# "int" could be *any* type
@a[3] = 3;
print @a[2];# prints 5, exists but undefined
@a[3] = undef;
print @a[3];# again, prints 5
Why would you want to put a "real undef" in your array of default
values? The whole point of defaulting is to change what "undef"
means for the array/hash/whatever.
MHO,
-Scott
--
Jonathan Scott Duff
[EMAIL PROTECTED]
Re: Arrays: Default Values
On Wednesday, January 29, 2003, at 11:02 AM, Jonathan Scott Duff wrote: So you can't set something to its type's own empty value, because it will, by definition, thereafter return it's "overloaded" empty value, . Looks like a maintenance nightmare to me. Agreed, it's not pretty. The fundamental problem is that a primitive like an C simply cannot be undefined... there's no flag for that (which is they're primitive.)So it having a 'default value' at all is perhaps a bit of a misnomer. A simple solution is perhaps to say that C can only be applied to types that can be undef (scalar,ref,Int,Str...) and can't be used on things that have no undefined state (bit,int,str...). That would neatly sidestep the problem, and would _force_ you to use Int instead of int when you wanted a default-instead-of-undefined case. MikeL
Re: Arrays: Default Values
Ok, stepping back...
there are three questions:
* Can a type be undefined
* What does an array say when asked for an element that doesn't exist
* What happens when you try to undefine something
I really think you need an attribute to clarify these.
For example, you would not say:
my int @a
but, rather
my @a is of(int)
or some such ("of" is a place-holder here that I don't much like because
it looks like "if"). In other words, the array itself is not an int. It
just contains them. You could have said:
my FunkyArray is of(int)
no?
Now, when you ask for an int that doesn't exist what do you get? By
default, I would suppose 0, but couldn't I want an integer-only data
type that *can* be undef?
If so, isn't that:
my @a is of(int but undefinable)
Ok, now we get to the meat of the matter:
my @a is of(int but undefinable), default(100)
here we have a perfectly valid thing to want. A list whose elements can
be undef or an integer, and which default to 100 when read
uninitialized.
As for the argument that testing for true non-existentness is a burden,
check out the way Perl5 does this. Hint: there's a central sv_undef, and
that's not what array buckets are initialized to
--
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: Spare brackets :-)
On Wed, 2003-01-29 at 05:29, Leopold Toetsch wrote:
> John Williams wrote:
>
> > I think you are still overlooking the autovivification behavior.
> > i.e. What is the difference between these:
> >
> >1) $a{1234567} = 1;
> >
> >2) $a[1234567] = 1;
> >
> > Answer: #1 creates 1 element. #2 creates 1,234,567 elements!
> Not currently: 2) does
> - generate a sparse hole between old size and up to ~index
> - generate one data chunk near index
> - store the PerlInt at index
I covered this under the term "storage". The storage is different for
arrays and hashes. This we know.
But, why do I need to waste a set of balanced tokens to indicate that
difference? Historical compatibility with Perl5? Perhaps. That's not a
bad reason actually, given how much this could wig people out (just look
at the response on this list :)
Also, you don't always pre-declare in Perl, and the following would be
ambiguous:
$x[7] = 8;
That could auto-vivify an array ref or a hash ref, and choosing one or
the other is kind of scary. I think you could work around that, but it
would require a real dedication to the IDEA that Perl has a generic
container type.
--
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
Michael Lazzaro <[EMAIL PROTECTED]> writes: > Solution 1: If you attempt to SET a cell to it's 'empty value', it > will be set to it's default: > > > my int @a is default(5); # > @a[5] = 0;# actually sets it to it's 'empty > value', 5 > > @a[5] = undef;# autocnv to 0, + warning, still sets to 5 > > my Int @a is default(5); # NOTE difference in type! > @a[5] = 0;# THIS really does set it to 0 > @a[5] = undef;# and this sets it to 5 > > So you can't set something to its type's own empty value, because it > will, by definition, thereafter return it's "overloaded" empty value, > . AAARGH, *runs for shelter* Setting an element to a leagal value, results in a different value to be stored, making it impossible to store this value. And this is even the most prominent value of the underlying type. > Solution 2: _ANY_ other solution would require the introduction of > 'fake empty' and 'really empty', and require arrays to keep track of > the difference. > > > my Int @a is default(5); > > @a[3] = 3; # there are now 4 items in the array > @a[2]; # was autoset to undef, so returns 5 > @a[4]; # doesn't exist, so returns 5 > > @a[2] = undef; # well, it's still undef, but now mark it > # as a 'real' undef, so don't return 5. > > This is essentially adding another layer of defined-ness on each cell, > and therefore requires an additional flag be kept & checked for each > array element. While this is certainly a possibility, I worry about > the complexity it introduces. Solution 3: The autoset sets the value to the default value. my Int @a is default(5); @a[3] = 3; # there are now 4 items in the array @a[2]; # was autoset 5 so returns 5 @a[4]; # doesn't exist, so returns 5 @a[2] = undef; # set to undef, so returns undef @a[5] = @a.default # if you really want to reset something to # default. BTW there are now 6 items in # the array. returns 5 @a[4]; # is now autoset to 5 so it remains 5 The default default value is the empty value of the base type. my Int @a; is the same as my Int @a is default(undef); bye b. -- Juergen Boemmels[EMAIL PROTECTED] Fachbereich Physik Tel: ++49-(0)631-205-2817 Universitaet Kaiserslautern Fax: ++49-(0)631-205-3906 PGP Key fingerprint = 9F 56 54 3D 45 C1 32 6F 23 F6 C7 2F 85 93 DD 47
Re: Arrays: Default Values
--- Michael Lazzaro <[EMAIL PROTECTED]> wrote: > > On Wednesday, January 29, 2003, at 11:02 AM, Jonathan Scott Duff > wrote: > >> So you can't set something to its type's own empty value, because > it > >> will, by definition, thereafter return it's "overloaded" empty > value, > >> . > > > > Looks like a maintenance nightmare to me. > > Agreed, it's not pretty. The fundamental problem is that a primitive > > like an C simply cannot be undefined... there's no flag for that > > (which is they're primitive.)So it having a 'default value' at > all > is perhaps a bit of a misnomer. > > A simple solution is perhaps to say that C can only be > applied to types that can be undef (scalar,ref,Int,Str...) and can't > be > used on things that have no undefined state (bit,int,str...). > Wait a minute. Leaving out the whole "is default()" bit, what happens when I: my int @a; @a[4] = 100; @a[2]; What does @a[2] return? It must return something, and that something can't be undef, because ... So, what is it? Whatever it is, that's the default. =Austin
Re: Arrays: Default Values
On Wed, Jan 29, 2003 at 08:49:42PM +0100, Juergen Boemmels wrote: > Solution 3: The autoset sets the value to the default value. > > my Int @a is default(5); > > @a[3] = 3; # there are now 4 items in the array > @a[2]; # was autoset 5 so returns 5 > @a[4]; # doesn't exist, so returns 5 > > @a[2] = undef; # set to undef, so returns undef Can someone give me a realish world example of when you would want an array that can store both undefined values and default values and those values are different? -Scott -- Jonathan Scott Duff [EMAIL PROTECTED]
Re: Arrays: Default Values
On Wed, Jan 29, 2003 at 11:32:53AM -0800, Michael Lazzaro wrote: > > On Wednesday, January 29, 2003, at 11:02 AM, Jonathan Scott Duff wrote: > >> So you can't set something to its type's own empty value, because it > >> will, by definition, thereafter return it's "overloaded" empty value, > >> . > > > > Looks like a maintenance nightmare to me. > > Agreed, it's not pretty. The fundamental problem is that a primitive > like an C simply cannot be undefined... there's no flag for that > (which is they're primitive.) The solution I advocate is to allow even "primitive" types to hold undef. I don't have an implementation, but that's just a detail I'll leave to those actually doing the implementation :-) > A simple solution is perhaps to say that C can only be > applied to types that can be undef (scalar,ref,Int,Str...) and can't be > used on things that have no undefined state (bit,int,str...). That works too (probably better depending on who you ask :) -Scott -- Jonathan Scott Duff [EMAIL PROTECTED]
Re: Arrays: Default Values
Jonathan Scott Duff <[EMAIL PROTECTED]> writes: > On Wed, Jan 29, 2003 at 08:49:42PM +0100, Juergen Boemmels wrote: > > Solution 3: The autoset sets the value to the default value. > > > > my Int @a is default(5); > > > > @a[3] = 3; # there are now 4 items in the array > > @a[2]; # was autoset 5 so returns 5 > > @a[4]; # doesn't exist, so returns 5 > > > > @a[2] = undef; # set to undef, so returns undef > > Can someone give me a realish world example of when you would want an > array that can store both undefined values and default values and those > values are different? Ok, here is one my float @weight_factor is default (1.0); $weighted_sum = sum (@weight_factor »*« @a); $weight_factor[4711] = 0.0; bye b. -- Juergen Boemmels[EMAIL PROTECTED] Fachbereich Physik Tel: ++49-(0)631-205-2817 Universitaet Kaiserslautern Fax: ++49-(0)631-205-3906 PGP Key fingerprint = 9F 56 54 3D 45 C1 32 6F 23 F6 C7 2F 85 93 DD 47
Re: Arrays: Default Values
In my opinion, default values for arrays should only come into play for array elements that have NEVER been assigned to or that have been explicity undef'ed. If an assigment is made to an array element then the array element should end up the assigned value (modulo necessary type conversions) and the array's default value should not play any part in the assignment. After an explisit assignment of an array element the only way that the array's default value should magically reappear is if an undef of the element is done. Any other way to handle things, like some of the other ways proposed will only lead to mysterious bugs and programmer missunderstandings. -- Mark Biggar [EMAIL PROTECTED]
Re: Arrays: Default Values
On Wed, Jan 29, 2003 at 12:00:33PM -0800, Mark Biggar wrote: > In my opinion, default values for arrays should only come into play > for array elements that have NEVER been assigned to or that have > been explicity undef'ed. If an assigment is made to an array element > then the array element should end up the assigned value (modulo > necessary type conversions) and the array's default value should > not play any part in the assignment. After an explisit assignment > of an array element the only way that the array's default value > should magically reappear is if an undef of the element is done. Exactly! > Any other way to handle things, like some of the other ways > proposed will only lead to mysterious bugs and programmer > missunderstandings. Exactly! * 2 -Scott -- Jonathan Scott Duff [EMAIL PROTECTED]
Re: Arrays: Default Values
On Wed, Jan 29, 2003 at 09:07:37PM +0100, Juergen Boemmels wrote: > Jonathan Scott Duff <[EMAIL PROTECTED]> writes: > > Can someone give me a realish world example of when you would want an > > array that can store both undefined values and default values and those > > values are different? > > Ok, here is one > > my float @weight_factor is default (1.0); > > $weighted_sum = sum (@weight_factor »*« @a); > > $weight_factor[4711] = 0.0; I see no undefined things there. -Scott -- Jonathan Scott Duff [EMAIL PROTECTED]
Re: Spare brackets :-)
Michael G Schwern wrote:
> On Tue, Jan 28, 2003 at 12:11:18PM +1300, [EMAIL PROTECTED] wrote:
>
> > Has anyone considered removing with the syntactic distinction
> > between numeric and string indexing -- that is, between array and
> > hash lookup?
>
> PHP works this way.
Well, for some definition of "work", anyway.
> http://www.php.net/manual/en/language.types.array.php
>
> So that makes a nice case study to investigate.
The manual is strangely quiet on how this duality fits together, but
through using PHP I've managed to work some of it out.
Basically in PHP there are just hashes, but hashes retain the order in
which elements are stored. When iterating with C or C you
get elements back in the order you put them in:
$colour = array('grass' => 'green', 'sky' => 'blue',
'orange' => 'orange');
print_r($colour);
# output:
Array
(
[grass] => green
[sky] => blue
[orange] => orange
)
If you add an element that doesn't have a key, then PHP finds the
maximum key that looks like a non-negative integer, adds one to it, and
uses that as the key for the new element, or uses zero if no elements
have such keys.
This means that if you never assign any explicit keys you can make it
seem like the hash is a 'normal' array:
$colour = array('purple', 'black', 'silver');
print_r($colour);
Array
(
[0] => purple
[1] => black
[2] => silver
)
But it isn't. Remember that elements retain the order in which they
were stored. So if you set them not in numerical order then they remain
in that order:
$colour = array();
$colour[1] = 'taupe';
$colour[3] = 'red';
$colour[0] = 'zephyr';
$colour[2] = 'pink';
print_r($colour);
Array
(
[1] => taupe
[3] => red
[0] => zephyr
[2] => pink
)
And if you remove an element from the middle of an array, the existing
elements keep their previous indices, so the indices are no longer
consecutive:
$colour = array('purple', 'black', 'silver', 'gold');
unset($colour[2]);
print_r($colour);
Array
(
[0] => purple
[1] => black
[3] => gold
)
And if you put that element back, well it doesn't go there but appears
at the end:
$colour = array('purple', 'black', 'silver', 'gold');
unset($colour[2]);
$colour[2] = 'bronze';
print_r($colour);
Array
(
[0] => purple
[1] => black
[3] => gold
[2] => bronze
)
The ordering means that it's possible to shift elements off the
beginning of a hash, which is fine:
$colour = array('grass' => 'green', 'sky' => 'blue',
'orange' => 'orange');
array_shift($colour);
print_r($colour);
Array
(
[sky] => blue
[orange] => orange
)
There's also something in there which checks for non-negative integer
keys, and if so renumbers them after shifting. This helps keep up the
pretence that the hash can be used as an array:
$colour = array('purple', 'black', 'silver', 'gold');
array_shift($colour);
print_r($colour);
Array
(
[0] => black
[1] => silver
[2] => gold
)
But this can have surprising consequences if you are trying to associate
numbers with particular elements:
$days = array(1 => 'day', 7 => 'week', 14 => 'fortnight',
365 => 'year');
array_shift($days);
print_r($days);
Array
(
[0] => week
[1] => fortnight
[2] => year
)
Zero days in a week? And the same thing happens even if the keys are
quoted, so that they are strings that happen to look like integers but
not actual integers:
$days = array('1' => 'day', '7' => 'week', '14' => 'fortnight',
'365' => 'year');
Trying that on a hash where some of the keys happen to look like
integers and some don't results in the former being renumbered and the
latter being left alone.
Is that enough?
The amazing thing is that most of the time, despite the above, what PHP
calls arrays do actually work well enough. But really PHP has hashes
with elements that retain their storage order plus some awkward hacks
that may make them seem more like arrays in certain circumstances. It's
messy. It's bordering on evil.
And I've never found it to have any advantage over the Perl way of
allowing the programmer to specify which data structure is required
rather than making the interpreter guess.
I cannot think of a worse example for Perl to follow.
Smylers
Re: Arrays: Default Values
--- Jonathan Scott Duff <[EMAIL PROTECTED]> wrote: > On Wed, Jan 29, 2003 at 08:49:42PM +0100, Juergen Boemmels wrote: > > Solution 3: The autoset sets the value to the default value. > > > > my Int @a is default(5); > > > > @a[3] = 3; # there are now 4 items in the array > > @a[2]; # was autoset 5 so returns 5 > > @a[4]; # doesn't exist, so returns 5 > > > > @a[2] = undef; # set to undef, so returns undef > > Can someone give me a realish world example of when you would want an > array that can store both undefined values and default values and > those > values are different? Sure. Implement an array that "is computed" such that it automatically invokes a function to interpolate values that haven't been explicitly stored. (Possibly using "keys @arry", but that's a different thread.) Use that to hold values of an arbitrary function. When the function divides by zero, or does certain types of unnatural math with Inf, the value is "undefined." Likewise, when the interpolator doesn't have enough data, or the points are too far apart for confidence, the value may be "undefined". =Austin
Re: Arrays: Default Values
On Wed, 2003-01-29 at 14:54, Jonathan Scott Duff wrote:
> Can someone give me a realish world example of when you would want an
> array that can store both undefined values and default values and those
> values are different?
my @send_partner_email is default(1);
while $websignups.getline {
($id) = /UserID: (\d+)/;
if /Source: External DB With No Privacy Policy/ {
@send_partner_email[$id] = undef; # No answer given
} elsif /Spam Me: Yes/ {
@send_partner_email[$id] = 1;
} else {
@send_partner_email[$id] = 0;
}
}
# If you were not in the websignups list, you signed up before privacy
# policy, so we spam you (default=1)
In this case, there's a true "shrug" answer, which is hard to deal with.
We need to do something later on with the undefined case (no answer was
given, and no spam warning issued). This sort of logic deferral is
common to many uses of undefined values (or "NULL") in databases, even
when columns have defaults that are non-null.
--
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, Jan 29, 2003 at 03:29:57PM -0500, Aaron Sherman wrote:
> On Wed, 2003-01-29 at 14:54, Jonathan Scott Duff wrote:
>
> > Can someone give me a realish world example of when you would want an
> > array that can store both undefined values and default values and those
> > values are different?
>
> my @send_partner_email is default(1);
> while $websignups.getline {
> ($id) = /UserID: (\d+)/;
> if /Source: External DB With No Privacy Policy/ {
> @send_partner_email[$id] = undef; # No answer given
> } elsif /Spam Me: Yes/ {
> @send_partner_email[$id] = 1;
> } else {
> @send_partner_email[$id] = 0;
> }
> }
> # If you were not in the websignups list, you signed up before privacy
> # policy, so we spam you (default=1)
But aren't those values arbitrary? Couldn't you just have
easily used -1 instead of undef? Why would undef be necessary or
preferred?
-Scott
--
Jonathan Scott Duff
[EMAIL PROTECTED]
Re: Arrays: Default Values
> Agreed, it's not pretty. The fundamental problem is that a primitive > like an C simply cannot be undefined... there's no flag for that > (which is they're primitive.) Certainly there's no way of _storing_ C. > So it having a 'default value' at all is perhaps a bit of a misnomer. Why does that follow? I'd say the opposite is true: it's because the type _can't_ store C that a _valid_ default is required. > A simple solution is perhaps to say that C can only be > applied to types that can be undef (scalar,ref,Int,Str...) and can't > be used on things that have no undefined state (bit,int,str...). But what's the disadvantage of permitting things of int to have non-zero default values? And, just because C can't be stored in an int, why does it mean that _trying_ to store an C can't be the action that triggers the default being stored there? For an int variable with a default of 5, you seem to have gone from the suggestion that attempting to store either zero or undef would result in 5 being stored, to the suggestion that either would result in zero being stored. Why can't zero and undef do different things? People obviously want to be able to store zeros in integer variables and having code that looks like it stores zero -- a valid integer -- actually store some other integer is ridiculous. So have zero store zero always. But storing C denotes clearing the element out of a particular value, which seems like a good time to use the default. Damian yesterday argued in favour of C, the value which is used when no other value is known, not being permitted in Int arrays which have a specific (integer) default, and hence that marking an element as C should put the default value there. That would make the rule very simple indeed: Assigning C to an array element causes that element to take the array's default value. That's it. It's what I assumed Damian meant yesterday, but I could be mistaken. 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. * In an array of int, attempting to store C will, by default, store zero. If the array has a different default defined then that will be stored instead. Smylers
Re: Arrays: Default Values
On Wed, 2003-01-29 at 14:53, Austin Hastings wrote: > Leaving out the whole "is default()" bit, what happens when I: > > my int @a; > @a[4] = 100; > @a[2]; > > What does @a[2] return? It must return something, and that something > can't be undef, because ... So, what is it? Whatever it > is, that's the default. That's an interesting question. At first, I was ready to say "zero, of course", but the more I thought about it, the more I realized that an array whose storage is not ultimately a collection of scalars can do one of three things: * Initialize new array sections to * Only default such arrays when elements are "off-the-end" * Not allow default on such arrays the second one seems to be a cruel joke to play on a programmer. The first is only slightly better. I'm beginning to go with the third... However, there is always the idea of using the SQL-like null/not null concept to allow simple types to be undefined. It makes sense to me the programmer to constrain data to be integer type, but allow undefined values. Even if there's no savings in terms of storage, I think it should be allowed. Perhaps I'm overreacting to the first option. It's not so bad. undef should still probably keep its old semantics when being converted to an integer and go to zero, though. -- 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
At 10:59 AM -0800 1/29/03, Austin Hastings wrote: Now: Does this require a "fake undef" and a "real undef"? WHO CARES? Very good answer. Leave the details to me and the p6i folks. (Though do please, everyone, pay attention when we tell you that what you want is slow or awkward) -- 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 Wed, Jan 29, 2003 at 03:48:18PM -0500, Dan Sugalski wrote: > (Though do please, everyone, pay attention when we tell you that what > you want is slow or awkward) Just be sure to reiterate in case we miss it the first time :-) -Scott -- Jonathan Scott Duff [EMAIL PROTECTED]
Re: Arrays: Default Values
On Wed, Jan 29, 2003 at 12:40:21PM -0500, Aaron Sherman wrote:
> Elements of a has ARE ordered, just not the way you may expect.
Quite:
$ perl5.8.0 -le '%a = (small => 1, large =>2); %b = %a; print foreach keys %a; print
"--"; print foreach keys %b'
large
small
--
small
large
$ perl5.8.0 -le '%a = (small => 1, large =>2); print foreach keys %a; print "--"; @a =
(0..1e3); $a{$_}=1 foreach @a; delete $a{$_} foreach @a; print foreach keys %a'
large
small
--
small
large
> There is no problem. It will pop the Pair that would be last if you
> converted to a list. That might be massively expensive to determine, but
> as long as the documentation warns the same way it does for converting
> to a list, then you're not causing any new problems.
>
> You keep asserting that there's no ordering to Hashes, but that's not
> true. I don't blame you, even the Perl docs get it wrong sometimes.
And the demonstration was as expected?
(I don't know two strings that clash for the hash algorithms used in 5.6 and
in 5.005 and earlier, hence why I'm specifying 5.8.0
pie => 1 , good => 1 works for the first example in 5.8.0 and 5.6.1,
perl => 1, rules => 1 for the second in both)
Nicholas Clark
Re: Arrays: Default Values
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. * In an array of int, attempting to store C will, by default, store zero. If the array has a different default defined then that will be stored instead. That has merit. One question -- with this approach, attempting to store an C in an array of int therefore silently succeeds (there's no longer any "converting undef to 0" warning, right, since it would be triggered constantly by this mechanism?) MikeL
Re: Arrays: Default Values
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... 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. -- Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Arrays: Default Values
--- Dan Sugalski <[EMAIL PROTECTED]> wrote: > At 10:59 AM -0800 1/29/03, Austin Hastings wrote: > >Now: Does this require a "fake undef" and a "real undef"? > > > >WHO CARES? > > Very good answer. Leave the details to me and the p6i folks. (Though > do please, everyone, pay attention when we tell you that what you > want is slow or awkward) Usually, I'm assuming that anything we ask for, you'll be unable, due to "geek pride", to stand up and say "I can't implement that." I feel slightly guilty about that, but then I eat an M&M, and whatever miniscule guilt I feel goes away... :-) :-) :-) But yeah, "spec" != "code". =Austin
Re: Arrays: Default Values
On Wed, Jan 29, 2003 at 02:13:34PM -0600, Jonathan Scott Duff wrote: > On Wed, Jan 29, 2003 at 12:00:33PM -0800, Mark Biggar wrote: > > In my opinion, default values for arrays should only come into play > > for array elements that have NEVER been assigned to or that have > > been explicity undef'ed. If an assigment is made to an array element > > then the array element should end up the assigned value (modulo > > necessary type conversions) and the array's default value should > > not play any part in the assignment. After an explisit assignment > > of an array element the only way that the array's default value > > should magically reappear is if an undef of the element is done. > > Exactly! This means that C<@a[2] = undef> is different to C. This is undesirable, but could be solved by using C. So, there appear to be two internally consistent ways of doing this: 1. There is a difference between an undefined element and a non existent element. Elements are autovivified to the default value, their existence may be tested for with C and they may be deleted with C. Undefined values may be read and written. 2. Attempting to read or write undef will substitute the default value. Both approaches seem valid. Choose one. Or two. No, one. Note that both approaches are consistent with the way things are in Perl 5 now if you consider the default value always to be undef. Both approaches can also be extended to hashes. I think the question of what to do with int arrays is somewhat separate. Might I suggest that storing undef in an int array is not appropriate, and thus having a (user defined) default value in an int array is also not appropriate. If you want power, you have to pay for it. -- Paul Johnson - [EMAIL PROTECTED] http://www.pjcj.net
Ordering is not what distinguish array from associative tables
On Wed, Jan 29, 2003 at 09:44:27AM -0500, Aaron Sherman wrote:
>
> Yes, I would expect that. In my opinion there is no difference between
> an array and a hash other than the underlying storage and the
> type-management of the key. I'm increasingly of the opinion that a)
> there should be no @ vs %, there should be no {} vs [], there should be
> a keys, values, defined, delete, exists, push, pop, shift, unshift for
> every container and foreach shouldn't give a damn.
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.
This is one of the main things that attracted me to Perl, variable names ($a,
@a, %a) were a clear indication of behavior.
Perl6 should also support associative tables with ordered keys.
The default type of associative tables should be hashes.
# hash based associative table metonymically called hash
my %assoctbl1;
# tree based associative tables.
properties should specify the tree algo used and possibly the ordering function.
my %assoctbl2 is redblack;
my %assoctbl3 is ordered( &sortfun);
>
> But, that would be a different language, and Perl has hashes and arrays.
> So, the most we can do is make them not work too differently.
>
--
stef
Re: Ordering is not what distinguish array from associative tables
Stéphane Payrard wrote:
On Wed, Jan 29, 2003 at 09:44:27AM -0500, Aaron Sherman wrote:
Yes, I would expect that. In my opinion there is no difference between
an array and a hash other than the underlying storage and the
type-management of the key. I'm increasingly of the opinion that a)
there should be no @ vs %, there should be no {} vs [], there should be
a keys, values, defined, delete, exists, push, pop, shift, unshift for
every container and foreach shouldn't give a damn.
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.
Of course, this doesn't mean I like the idea, but I just wanted to
point out that there are some languages that do it this way. However,
I hope that we are not going to be one of those.
Joseph F. Ryan
[EMAIL PROTECTED]
Re: Arrays: Default Values
At 2:18 PM -0800 1/29/03, Austin Hastings wrote: --- Dan Sugalski <[EMAIL PROTECTED]> wrote: At 10:59 AM -0800 1/29/03, Austin Hastings wrote: >Now: Does this require a "fake undef" and a "real undef"? > >WHO CARES? Very good answer. Leave the details to me and the p6i folks. (Though do please, everyone, pay attention when we tell you that what you want is slow or awkward) Usually, I'm assuming that anything we ask for, you'll be unable, due to "geek pride", to stand up and say "I can't implement that." Oh, I can implement almost anything, and the quantum ninja take care of anyone who suggests things I can't implement. That's not the issue--it's efficiency, that's the issue. :) -- Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: More Array Behaviors
> Date: Mon, 27 Jan 2003 13:24:23 -0800 > From: Damian Conway <[EMAIL PROTECTED]> > > Dave Whipp suggested: > > > The size constraints are probably C properties, as is C. The > > exception behavior probably deserves to remain an C property. > > Nope. They're all C properties. C properties only apply to *values*. > Variable such as Arrays always take C properties. I'm getting flashbacks of the whole ser/estar discrepancy from my spanish years. So, as a clarification, can (almost) any property act as both a referent and a value property? That is, in: my @foo is bar; my $baz = [] but bar; @foo and @$foo are equivalent in all but a few cases? So that C is just a designator of where to put the property, not where the property is seen. Um, I think I could have been clearer in that question, but people get my gist, I hope. Luke
Re: Arrays: Default Values
On Wed, Jan 29, 2003 at 02:37:04PM -0600, Jonathan Scott Duff wrote:
> On Wed, Jan 29, 2003 at 03:29:57PM -0500, Aaron Sherman wrote:
> > On Wed, 2003-01-29 at 14:54, Jonathan Scott Duff wrote:
> >
> > > Can someone give me a realish world example of when you would want an
> > > array that can store both undefined values and default values and those
> > > values are different?
> >
> > my @send_partner_email is default(1);
> > while $websignups.getline {
> > ($id) = /UserID: (\d+)/;
> > if /Source: External DB With No Privacy Policy/ {
> > @send_partner_email[$id] = undef; # No answer given
> > } elsif /Spam Me: Yes/ {
> > @send_partner_email[$id] = 1;
> > } else {
> > @send_partner_email[$id] = 0;
> > }
> > }
> > # If you were not in the websignups list, you signed up before privacy
> > # policy, so we spam you (default=1)
>
> But aren't those values arbitrary? Couldn't you just have
> easily used -1 instead of undef? Why would undef be necessary or
> preferred?
Sure, they're arbitrary but undef is is preferred because it indicates
the decision is undefined. You seem to have snipped this:
> In this case, there's a true "shrug" answer, which is hard to deal with.
> We need to do something later on with the undefined case (no answer was
> given, and no spam warning issued). This sort of logic deferral is
> common to many uses of undefined values (or "NULL") in databases, even
> when columns have defaults that are non-null.
The reference to databases is salient. There are surely many examples
to be found in SQL books.
--
Rick Delaney
[EMAIL PROTECTED]
Re: Arrays: Default Values
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.
Wouldn't that mean that this would loop forever?
my @a is default("foo");
#...
# please excuse my garbled perl5/6 syntax
print "@a" while $a[0] = ;
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.
> > * In an array of int, attempting to store C will, by default,
> > store zero. If the array has a different default defined then that
> > will be stored instead.
>
> That has merit. One question -- with this approach, attempting to
> store an C in an array of int therefore silently succeeds
> (there's no longer any "converting undef to 0" warning, right, since it
> would be triggered constantly by this mechanism?)
It seems to me that the conversion of undef is separate from the notion
of a default.
my int @a;
is like
my int @a is undef_to(0).
There is no default here, only a rule saying what assignment of undef
stores. Accessing an uninitialized element should raise an exception,
not give zero.
In the case where people want assigning undef to set the default (i.e.
treat undef the same as uninitialized) then they would set both
properties to the same value.
my int @a is default(1) is undef_to(1);
--
Rick Delaney
[EMAIL PROTECTED]
Re: Arrays: Default Values
"Jonathan Scott Duff" <[EMAIL PROTECTED]> wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... > On Wed, Jan 29, 2003 at 11:32:53AM -0800, Michael Lazzaro wrote: > > > > Agreed, it's not pretty. The fundamental problem is that a primitive > > like an C simply cannot be undefined... there's no flag for that > > (which is they're primitive.) > > The solution I advocate is to allow even "primitive" types to hold > undef. I don't have an implementation, but that's just a detail I'll > leave to those actually doing the implementation :-) > > > A simple solution is perhaps to say that C can only be > > applied to types that can be undef (scalar,ref,Int,Str...) and can't be > > used on things that have no undefined state (bit,int,str...). C++ had a design principle: you only pay for what you ask for. From a different perspective: if you ask for it, then you're willing to pay. So if you ask for a default on an array of primitive types, then the implementation assumes that you're willing to pay for it: but only for those arrays that have defaults. The fact of the default is a property of the array, not of the elements it stores. There's no need to add undef values to primitive types. The most obvious solution (obvious =/=> best) is a boolean (bit) array whose elements are associated with elements in the data array. Yes, there's a cost, but if the programmer asks for something, then they pay for it. But the implementation guys aren't allowed to play bait-and-switch! Dave. -- http://dave.whipp.name
