Re: More Array Behaviors
Damian Conway [EMAIL PROTECTED] writes: Dave Whipp wrote: OK, I've assimilated all that (though it still feels wrong). I think you are saying that of the following, the 4th is an error. my @d = @x but Foo; # error: no values involved in this assignment Correct. Although presumably this: my @d = @x »but« Foo; is okay. I think that the thing that confused is that Cis Vs Cbut distinction was introduced as compile-time vs run-time. It seems that this distinction is not relevant. Let's say it's an approximation to the true. Lets see if I apply this to objects. Objects are variables Yes. (they contain attributes). Yes. All access to objects is via (scalar) references: Yes. these references, being values, can have Cbut properties. Yes. When a method is invoked on an object, that method has an invocant, which enables the method to see the Cbut properties on that reference. Yes. If an object wants to have properties that apply to all references (to a given instance), then that property must be defined as an attribute of the object. Yes. At least, for the new opaque objects. Because there's no way to ascribe the necessary Cis property to them. Bugger. I was hoping that Perl 6 was going to make a Pixie like Object database easier to write; looks like I'm wrong. One of the things Pixie does is to attach its control data by magic to the object itself (rather than any particular variable pointing to it). This lets us do all sorts of useful stuff without invading the object since we know that it will carry our metadata around it. Please, consider making but properties attach to the target of a pointer rather than to the pointer itself. And if you don't want to do that, I'd say that there is a need to be able to specify some new kind of property that does attach to the target. -- Piers
Re: Spare brackets :-)
Damian Conway [EMAIL PROTECTED] writes:
This may sound like a silly idea
It's been suggested previously.
Has anyone considered removing with the syntactic distinction between
numeric and string indexing -- that is, between array and hash lookup?
Yes. We rejected the idea.
In particular, it would seem that
%foo[$key]
would be just as easy for the compiler to grok as
%foo{$key}
Sure. But then is this:
$ref[$key]
an array or hash look-up???
Decided at runtime?
--
Piers
Re: Spare brackets :-(
ECMAscript already tried this.
Bad idea.
If your hash keys happen to look like large numbers (e.g. you
have 7-digit product codes) as soon as you store one of them, it says:
Oh, this looks like a number, so we'll store it like an array and
happily creates a million empty array entries for you.
~ John Williams
On Tue, 28 Jan 2003 [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?
In particular, it would seem that
%foo[$key]
would be just as easy for the compiler to grok as
%foo{$key}
but would mean that we could stop worrying about the precedence of
postfix/infix {, and things like
if %test { $count++ }
would not require whitespace before the { to be disambiguated.
I don't have a complete solution as anonymous array and hash construction would
still need different syntaces, but has anyone else thought about this?
- Martin
Re: Spare brackets :-)
Sure. But then is this: $ref[$key] an array or hash look-up??? Decided at runtime? Doesn't help if $ref refers to a type that has both hash-like and array-like accessability. And that will be very common, since all Perl 6 regexes return such objects. Damian
Re: More Array Behaviors
At 8:46 AM + 1/28/03, Piers Cawley wrote: Bugger. I was hoping that Perl 6 was going to make a Pixie like Object database easier to write; looks like I'm wrong. One of the things Pixie does is to attach its control data by magic to the object itself (rather than any particular variable pointing to it). This lets us do all sorts of useful stuff without invading the object since we know that it will carry our metadata around it. Please, consider making but properties attach to the target of a pointer rather than to the pointer itself. And if you don't want to do that, I'd say that there is a need to be able to specify some new kind of property that does attach to the target. Given the current implementation (And I hear rumors that you lurk on the internals list, Piers... :) I think we can manage something like this. Might require a drop to assembly somewhere, perhaps hidden behind a function rather than with syntax, but it should be doable... -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Spare brackets :-)
At 8:47 AM + 1/28/03, Piers Cawley wrote: Damian Conway [EMAIL PROTECTED] writes: Sure. But then is this: $ref[$key] an array or hash look-up??? Decided at runtime? How? People use strings as array indices and ints/floats as hash indices, and count on autoconversion to Make It Work. -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: More Array Behaviors
Piers Cawley wrote:
Bugger. I was hoping that Perl 6 was going to make a Pixie like Object
database easier to write; looks like I'm wrong. One of the things
Pixie does is to attach its control data by magic to the object itself
(rather than any particular variable pointing to it). This lets us do
all sorts of useful stuff without invading the object since we know
that it will carry our metadata around it. Please, consider making
but properties attach to the target of a pointer rather than to the
pointer itself.
Errno. That's rather the whole point of Cbut properties [*].
However, if your class returns a reference to an object and that reference
has the appropriate value properties ascribed to it (i.e. stuck on the
*reference*), then any access through that reference (or through any
subsequent copy of it) will see those properties.
So your magic Pixie would look something like
class Pixie {
method new($class: %args) {
return $class.SUPER::new(%args)
but Magic('whatever');
}
# etc.
}
Damian
[*] People, we just *have* to find better names for these things!
I'd suggest we henceforth call them value properties (for Cbut)
and referent properties (for Cis).
Re: Spare brackets :-)
--- Dan Sugalski [EMAIL PROTECTED] wrote: At 8:47 AM + 1/28/03, Piers Cawley wrote: Damian Conway [EMAIL PROTECTED] writes: Sure. But then is this: $ref[$key] an array or hash look-up??? Decided at runtime? How? People use strings as array indices and ints/floats as hash indices, and count on autoconversion to Make It Work. On the one hand: Java/ECMA/J-script does it. All objects are associative arrays. All arrays can be associative, on demand. Ca[foo] = 1; Presto. Associative array. On the other hand: This gets dangerous really quickly, since Perl's autoconversion works differently. Specifically, since we treat things as strings unless they need to be otherwise rather than treating them as the type that they were when you created them. (Javascript doesn't have much in the way of I/O, so the act of getting data in is a bit of an effort, and that effort usually has the side effect of providing type data.) Writing a roulette game may get challenging: @colors[0] = Green; @colors[00] = Green; @colors[000] = Green; Do those get autoconverted to numbers? (They can, obviously. But they shouldn't.) This kind of thing points back at a discussion we had once before about more kinds of context -- meaning at the time numeric versus string versus ... whatever. I think that if we do this we'd better know more about what we're expecting versus what we're losing. On the losing side, the difference between lowercase-array and lowercase-hash is probably significant, performance-wise. Merging the array and hash notions may cost a lot of speed for a lot of people. On the gaining/expecting side is ... what? Freeing up curly braces? Improving the syntax? Other stuff not obvious to me right now? If we go that route, we could certainly include a new pure array type: my @trough = slop(); my PureArray @pa = ducks(); my PureHash @ph = dictionary(); =Austin
Re: More Array Behaviors
Dan Sugalski [EMAIL PROTECTED] writes: At 8:46 AM + 1/28/03, Piers Cawley wrote: Bugger. I was hoping that Perl 6 was going to make a Pixie like Object database easier to write; looks like I'm wrong. One of the things Pixie does is to attach its control data by magic to the object itself (rather than any particular variable pointing to it). This lets us do all sorts of useful stuff without invading the object since we know that it will carry our metadata around it. Please, consider making but properties attach to the target of a pointer rather than to the pointer itself. And if you don't want to do that, I'd say that there is a need to be able to specify some new kind of property that does attach to the target. Given the current implementation (And I hear rumors that you lurk on the internals list, Piers... :) Nah, that's someone else with the same name and writing style. I think we can manage something like this. Might require a drop to assembly somewhere, perhaps hidden behind a function rather than with syntax, but it should be doable... Breaths sigh of relief -- Piers
Re: Spare brackets :-)
Dan Sugalski [EMAIL PROTECTED] writes: At 8:47 AM + 1/28/03, Piers Cawley wrote: Damian Conway [EMAIL PROTECTED] writes: Sure. But then is this: $ref[$key] an array or hash look-up??? Decided at runtime? How? People use strings as array indices and ints/floats as hash indices, and count on autoconversion to Make It Work. Nope. The count on the fact that, at runtime you'll know whether $ref is a hash or an array. But I'm not actually arguing for this, just pointing out that it's not necessarily impossible (just way harder to optimize). -- Piers
Re: More Array Behaviors
Damian Conway [EMAIL PROTECTED] writes:
Piers Cawley wrote:
Bugger. I was hoping that Perl 6 was going to make a Pixie like Object
database easier to write; looks like I'm wrong. One of the things
Pixie does is to attach its control data by magic to the object itself
(rather than any particular variable pointing to it). This lets us do
all sorts of useful stuff without invading the object since we know
that it will carry our metadata around it. Please, consider making
but properties attach to the target of a pointer rather than to the
pointer itself.
Errno. That's rather the whole point of Cbut properties [*].
However, if your class returns a reference to an object and that reference
has the appropriate value properties ascribed to it (i.e. stuck on the
*reference*), then any access through that reference (or through any
subsequent copy of it) will see those properties.
So your magic Pixie would look something like
class Pixie {
method new($class: %args) {
return $class.SUPER::new(%args)
but Magic('whatever');
}
# etc.
}
[*] People, we just *have* to find better names for these things!
I'd suggest we henceforth call them value properties (for Cbut)
and referent properties (for Cis).
Hmm... Here's Pixie's interface:
my $pixie = Pixie.new.connect('dbi:foo:bar', $user, $pass);
...
my $cookie = $pixie.insert($some_arbitrary_object);
# Time passes, we forget everything but the value of $cookie
my $pixie = Pixie.new.connect('dbi:foo:bar', $user, $pass);
my $locked_object =
$pixie.get_with_locking_strategy( $cookie,
Strategy::ExclusiveLock.new );
When $locked_object is collected, Pixie unlocks it in the
database. If, while $locked_object is in scope something else tries to
fetch an object with the same cookie (from within the same thread)
then Pixie hands 'em a reference to the same object. Right now Pixie
keeps a handle on everything by attaching 'ObjectInfo' objects to
every object that comes under its control so it can keep track of
what's going on (it's a two way link, the object has a normal ref
(via magic) to the objectinfo, which has a weakref back to the object
itself, so when the object goes out of scope, the objectinfo goes out
of scope too, triggering unlocking and other such stuff).
So, if Pixie::get_with_locking_strategy looks something like:
method get_with_locking_strategy( $self: $oid,
Strategy $lock_strategy ) {
return $self.cache_get($oid);
CATCH Exception::NotInCache {
my $flattened_object =
$self.store.get_with_locking_strategy($oid, $lock_strategy);
my $obj_info = ObjectInfo.new.set_pixie($self)
.set_oid($oid)
.set_lock_strategy($lock_strategy);
my $real_obj =
Storable::retrieve($flattened_object) but PixieInfo($obj_info);
$obj_info.set_real_object($real_obj);
$self.cache_insert($obj_info);
return $real_obj;
}
}
method cache_get( $oid ) {
my $info = %.cache{$oid} // die Exception::NotInCache.new;
return $info.real_object;
}
Will every copy of the value of $real_obj have the PixieInfo property?
Am I going mad, or is order really that important? My initial idea was
to do the Cset_real_object and Ccache_insert and then just do
Creturn $real_obj but PixieInfo($obj_info), but then, if I
understand you correctly, the Info object's back reference to the real
object wouldn't have a PixieInfo property, which would in turn mean
that cache_get's return value wouldn't have the property and Bad
Things would happen. It seems counterintuitive that the order of
operations in this case should be so important.
Or am I missing something?
--
Piers
More Array Behaviors (Take 2)
OK, here are the answers so far -- or more accurately, strawman interpretations of those answers that should be objected to if they're wrong. 1) Edge cases in array indexing: my int @a = (1,2,3); @a[0] # 1 @a[1] # 2 @a[2] # 3 @a[3] # undef (warning: index out-of-bounds) @a[2**128]# EXCEPTION: index is above max allowed index @a[ Inf ] # undef (warning: can't use Inf as array index) @a[ undef ] # 1 (warning: undefined index) @a['foo'] # 1 (warning: non-numeric index) @a[ NaN ] # EXCEPTION: can't use NaN as array index @a[-1]# 3 @a[-2]# 2 @a[-3]# 1 @a[-4]# undef (warning: index out-of-bounds) @a[-Inf] # undef (warning: can't use Inf as array index) 2) There is a platform-dependent maximum array size, ((2**32)-1 for 32-bit platforms.) Attempting to access an index outside that range throws an exception. Note that this applies to both 'real' and 'sparse' arrays. If these are incorrect statements, please correct me. --- The other two questions are less definitively answered, so far. I shall attempt to disambiguate them... MikeL
Re: More Array Behaviors (Take 2)
At 10:13 AM -0800 1/28/03, Michael Lazzaro wrote: OK, here are the answers so far -- or more accurately, strawman interpretations of those answers that should be objected to if they're wrong. I think some of this is incorrect which, because Damian thinks otherwise, will need some hashing out from Larry on how he wants perl arrays to behave. Because... 1) Edge cases in array indexing: my int @a = (1,2,3); @a[3] # undef (warning: index out-of-bounds) Or a real 0, since you said @a can only return integers. @a[2**128]# EXCEPTION: index is above max allowed index Except we can manage this internally, so I don't know that it's a problem @a[ Inf ] # undef (warning: can't use Inf as array index) I'd throw an exception here. @a[-4]# undef (warning: index out-of-bounds) @a[-Inf] # undef (warning: can't use Inf as array index) Or zero, since it's an int array. 2) There is a platform-dependent maximum array size, ((2**32)-1 for 32-bit platforms.) Attempting to access an index outside that range throws an exception. Note that this applies to both 'real' and 'sparse' arrays. But since we've got big(int|float|rat)s there's no real reason for that to be a problem. If you want to use 10**100**100 as an array index, you could just throw an awful lot of memory at us... -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: More Array Behaviors (Take 2)
On Tuesday, January 28, 2003, at 10:20 AM, Dan Sugalski wrote:
At 10:13 AM -0800 1/28/03, Michael Lazzaro wrote:
1) Edge cases in array indexing:
my int @a = (1,2,3);
@a[3] # undef (warning: index out-of-bounds)
Or a real 0, since you said @a can only return integers.
Thanks -- I stand corrected, you're almost certainly right. Arrays
defined with a cell type that can't be undefined should never return
undef, regardless of index. They should instead return the default
for that type... int(0), num(0.0), str(''), whatever...
I also agree @a[Inf] is worthy of an exception. Without objection, so
documented.
MikeL
Re: More Array Behaviors (Take 2)
On Tue, 28 Jan 2003, Dan Sugalski wrote: At 10:13 AM -0800 1/28/03, Michael Lazzaro wrote: @a[ Inf ] # undef (warning: can't use Inf as array index) I'd throw an exception here. @a[-4]# undef (warning: index out-of-bounds) @a[-Inf] # undef (warning: can't use Inf as array index) Or zero, since it's an int array. If you throw an exception for +Inf, you should throw it for -Inf too. ~ John Williams
Arrays: Default Values
There has been discussion of allowing a default value for array cells
-- that is, one aside from Cundef or whatever the type-specific
default is. Questions, in order of increased evilness:
1) What's the final decided syntax? Two possibilities:
my @a is Array( default = 'foo' ); # attrib?
my @a is default('foo');# property?
2) Assume the default value is a simple value, e.g. 'foo'.
my @a is Array( default = 'foo' );
@a[5] = 'bar';
@a[4]; # 'foo'
@a[5]; # 'bar'
@a[6]; # 'foo'
@a[-1];# 'bar' *NOTE!*
@a[-3];# 'foo'
@a[-10]; # 'foo'
Correct?
2a) When a cell is explicitly re-undefined, does the default value take
effect?
my @a is Array( default = 'foo' ) = (1,2,3);
@a[1] = undef;
@a[1]; # undef, or 'foo'?
STRAWMAN ANSWER: 'foo'.
2b) Primitive-typed arrays: Given the behavior of (2a), and the fact
that primitive-typed arrays can't store undef, what happens here?
my int @a is Array( default = 5 );
@a[0] = 0;
@a[0]; # 0, or 5?
@a[0] = undef;
@a[0]; # 0, or 5?
STRAWMAN ANSWER: 5, in both cases. So don't do that unless you
mean it.
3) Can the default value be a closure, based on index location?
my @a is Array( default = { $_ ** 2 });
STRAWMAN ANSWER: Yes, because it's cool.
3a) NOTE that closure-based defaults effectively render the array
infinite. Therefore -- If the requested index is negative, what
happens?
@a[-5];
STRAWMAN ANSWER: The closure just gets a negative number as the
requested index.
It's up to you to make it work, if you want it to.
3b) Does an infinite array still get an exception thrown when trying
to access an infinite [Inf] or [-Inf] index?
STRAWMAN ANSWER: Yes, it does.
MikeL
Re: Arrays: Default Values
On Tue, Jan 28, 2003 at 11:15:26AM -0800, Michael Lazzaro wrote:
2) Assume the default value is a simple value, e.g. 'foo'.
my @a is Array( default = 'foo' );
@a[5] = 'bar';
@a[4]; # 'foo'
@a[5]; # 'bar'
@a[6]; # 'foo'
@a[-1];# 'bar' *NOTE!*
Um ... why?
2a) When a cell is explicitly re-undefined, does the default value take
effect?
my @a is Array( default = 'foo' ) = (1,2,3);
@a[1] = undef;
@a[1]; # undef, or 'foo'?
STRAWMAN ANSWER: 'foo'.
This makes sense to me.
2b) Primitive-typed arrays: Given the behavior of (2a), and the fact
that primitive-typed arrays can't store undef, what happens here?
my int @a is Array( default = 5 );
@a[0] = 0;
@a[0]; # 0, or 5?
0, definitely. @a[0] was defined so the default doesn't come into
play.
@a[0] = undef;
@a[0]; # 0, or 5?
5, because undefined things get the default value.
3) Can the default value be a closure, based on index location?
my @a is Array( default = { $_ ** 2 });
STRAWMAN ANSWER: Yes, because it's cool.
Heh. I'd want different syntax for default values vs. default
generators though.
3a) NOTE that closure-based defaults effectively render the array
infinite. Therefore -- If the requested index is negative, what
happens?
@a[-5];
STRAWMAN ANSWER: The closure just gets a negative number as
the requested index. It's up to you to make it work, if you
want it to.
Sounds good to me.
3b) Does an infinite array still get an exception thrown when trying
to access an infinite [Inf] or [-Inf] index?
STRAWMAN ANSWER: Yes, it does.
Based on 3a, I'd say that the closure should get Inf (or -Inf) and
do the appropriate thing. In your example above, Inf**2 would be Inf,
so the closure would return Inf (assuming I've got the Inf math right
and it's not really NaN)
-Scott
--
Jonathan Scott Duff
[EMAIL PROTECTED]
Re: More Array Behaviors
--- Damian Conway [EMAIL PROTECTED] wrote: [*] People, we just *have* to find better names for these things! I'd suggest we henceforth call them value properties (for Cbut) and referent properties (for Cis). Hmm. According to this, Creturn 0 is true; would therefore be a malvalapropism, no? =Austin
Re: Arrays: Default Values
Michael Lazzaro said:
There has been discussion of allowing a default value for array cells
-- that is, one aside from Cundef or whatever the type-specific
default is. Questions, in order of increased evilness:
1 and 2 seem fine to me.
2a) When a cell is explicitly re-undefined, does the default value take
effect?
my @a is Array( default = 'foo' ) = (1,2,3);
@a[1] = undef;
@a[1]; # undef, or 'foo'?
STRAWMAN ANSWER: 'foo'.
Seems right to me. Anything else would be very confusing, I think.
2b) Primitive-typed arrays: Given the behavior of (2a), and the fact
that primitive-typed arrays can't store undef, what happens here?
my int @a is Array( default = 5 );
@a[0] = 0;
@a[0]; # 0, or 5?
0. Being unable to store 0 would seem to be a major limitation.
@a[0] = undef;
@a[0]; # 0, or 5?
An exception or 5.
Maybe undefining an element could always set it to the default value.
3) Can the default value be a closure, based on index location?
my @a is Array( default = { $_ ** 2 });
STRAWMAN ANSWER: Yes, because it's cool.
No, because it's unnecessary. You can always do
my $value = @a[$x] //= $x ** 2;
or skip the = depending on how you are trading memory / speed.
Yes, I know that just about everything is unnecessary to someone. To me,
default values as a whole seem a little unnecessary, in fact.
--
Paul Johnson - [EMAIL PROTECTED]
http://www.pjcj.net
Re: Arrays: Default Values
--- Michael Lazzaro [EMAIL PROTECTED] wrote:
1) What's the final decided syntax? Two possibilities:
my @a is Array( default = 'foo' ); # attrib?
my @a is default('foo');# property?
Since we want arrays (lowercase) to support them, too, it should be a
property.
my @a is default('foo');
2) Assume the default value is a simple value, e.g. 'foo'.
my @a is Array( default = 'foo' );
@a[5] = 'bar';
@a[4]; # 'foo'
@a[5]; # 'bar'
@a[6]; # 'foo'
@a[-1];# 'bar' *NOTE!*
@a[-3];# 'foo'
@a[-10]; # 'foo'
1) What if I *WANT* an array with negative indices? Case in point, the
compare interface returns negative/zero/positive results, so I may want
to use those. (Granted, using the -1 as from-end is cool. But writing a
hand-optimized table of index values for use in a Shell/Metzner sort is
also cool, and depends on quickly getting the results of the carry
bit.)
2a) When a cell is explicitly re-undefined, does the default value
take effect?
No. If I wanted that, I'd say my @a[5] = @a.default;
my @a is Array( default = 'foo' ) = (1,2,3);
@a[1] = undef;
@a[1]; # undef, or 'foo'?
STRAWMAN ANSWER: 'foo'.
No, undef. OTOH, deleting @a[1] would reset it to default.
2b) Primitive-typed arrays: Given the behavior of (2a), and the fact
that primitive-typed arrays can't store undef, what happens here?
my int @a is Array( default = 5 );
@a[0] = 0;
@a[0]; # 0, or 5?
@a[0] = undef;
This should cause a blip of some kind. If storing an explicit undef (as
opposed to undef but 0 or C$v = undef; @a[0] = $v; there should be
an exception. If storing an implicit undef: convert to int (IOW: 0) and
emit a warning.
@a[0]; # 0, or 5?
STRAWMAN ANSWER: 5, in both cases. So don't do that unless you
mean it.
Again, this is wrong. Storing undef is storing undef. If it's an error,
treat it as such. If it's not an error, then let me store it. If I want
to store the default value, I have access to the default value and can
store it.
3) Can the default value be a closure, based on index location?
my @a is Array( default = { $_ ** 2 });
STRAWMAN ANSWER: Yes, because it's cool.
No, because defaulting method may be independent of default value. It
should be called default_method instead:
my @a is default_method( {$_ ** 2} );
3a) NOTE that closure-based defaults effectively render the array
infinite. Therefore -- If the requested index is negative, what
happens?
@a[-5];
STRAWMAN ANSWER: The closure just gets a negative number as the
requested index.
It's up to you to make it work, if you want it to.
Another question: If you ask for a value and get it, does the array
grow? Or does that happen only on assignment? (I favor assignment, but
if the closure isn't a pure function, what happens? Can we support
differentiating between Cis cached subs (meaning: don't allocate
storage for this array element) and not (meaning: you'll want to
allocate storage, because this value isn't reproducible)?
3b) Does an infinite array still get an exception thrown when
trying to access an infinite [Inf] or [-Inf] index?
STRAWMAN ANSWER: Yes, it does.
No, it doesn't. Like negative numbers in 3a, Inf gets passed to the
default_method, which may itself throw the exception. But since Inf and
NaN are floating-point things, they should be easy to recognize. (In
fact, I'd say just provide a default sub and show people what it looks
like.)
::Array.default_method :=
::array.default_method :=
sub - ($this: $index)
{
die(Invalid array index)
unless $index.isa('int');
# Not setting the array[index] here, since this is cached.
return defined($this.default)
? $this.default
: undef;
} is cached;
PS: If the .default changes, the cached values are wrong. How to I tell
Perl to clear a function's return cache? Or do we just not cache the
function and allocate memory on an index-by-index basis?
=Austin
Re: More Array Behaviors (Take 2)
Michael Lazzaro wrote: OK, here are the answers so far -- or more accurately, strawman interpretations of those answers that should be objected to if they're wrong. 1) Edge cases in array indexing: my int @a = (1,2,3); @a[0] # 1 @a[1] # 2 @a[2] # 3 @a[3] # undef (warning: index out-of-bounds) @a[2**128]# EXCEPTION: index is above max allowed index I would have thought that for SparseArrays (which require index remapping anyway), BigInt indices should be allowed. @a[ Inf ] # undef (warning: can't use Inf as array index) I would have though the behaviour of out-of-range indices like @a[2**128] and @a[Inf] ought to be consistent. Hence I'd have expected an exception here. @a[ undef ] # 1 (warning: undefined index) @a['foo'] # 1 (warning: non-numeric index) @a[ NaN ] # EXCEPTION: can't use NaN as array index @a[-1]# 3 @a[-2]# 2 @a[-3]# 1 @a[-4]# undef (warning: index out-of-bounds) @a[-Inf] # undef (warning: can't use Inf as array index) Another exception, I'd have thought. 2) There is a platform-dependent maximum array size, ((2**32)-1 for 32-bit platforms.) Attempting to access an index outside that range throws an exception. Which is why I'd expect that CInf as an index should be fatal. Note that this applies to both 'real' and 'sparse' arrays. Given the implicit promotion of ints to BigInts everywhere else, this seems inconsistent. At least for SparseArrays, where indices are remapped anyway. Damian
Re: Arrays: Default Values
--- Austin Hastings [EMAIL PROTECTED] wrote: No, undef. OTOH, deleting @a[1] would reset it to default. Ere someone flames my for using a hash keyword in an array context: s/deleting/absquatulating (e.g., via pop, shift, or splice)/ =Austin
More Array Behaviors (Take 3)
Corrected in accordance with design team member feedback. These should be solid, now. Thanks much for the responses. 1) Edge cases in array indexing: my @a = (1,2,3); @a[0] # 1 @a[1] # 2 @a[2] # 3 @a[3] # def (warning: index out-of-bounds) @a[2**128]# def (warning: index out-of-bounds) @a[ Inf ] # EXCEPTION: can't use +Inf as array index @a[ undef ] # 1 (warning: undefined index) @a['foo'] # 1 (warning: non-numeric index) @a[ NaN ] # EXCEPTION: can't use NaN as array index @a[-1]# 3 @a[-2]# 2 @a[-3]# 1 @a[-4]# def (warning: index out-of-bounds) @a[-Inf] # EXCEPTION: can't use -Inf as array index Where def is whatever the type-specific default is, typically Cundef, C0, or C''. 2) There is NO platform-dependent maximum array size. If it's not a sparse array, you'll run out of memory long before you run out of indexes, but using bigints as indexes for sparse arrays is OK. MikeL
Re: Arrays: Default Values
I think this debate is easier if you think of defaults as overriding and
auto-vivification method on a container.
On Tue, 2003-01-28 at 14:47, Paul Johnson wrote:
Michael Lazzaro said:
2a) When a cell is explicitly re-undefined, does the default value take
effect?
my @a is Array( default = 'foo' ) = (1,2,3);
@a[1] = undef;
@a[1]; # undef, or 'foo'?
STRAWMAN ANSWER: 'foo'.
Seems right to me. Anything else would be very confusing, I think.
This would be very confusing to me. In fact, it seems WRONG to me unless
we're saying that such arrays can simply never hold an undefined
value... which again seems wrong.
my @a is Array ( default = 'foo' );
@a[1] = undef;
Should yield the following, I would think:
('foo', undef, 'foo' x Inf)
Though, obviously there's no such thing as @a[2], but if you reference
it, that's how it would auto-vivify.
If that's not the case, I need to get my head around why, since Perl
*does* distinguish between defined and exists.
2b) Primitive-typed arrays: Given the behavior of (2a), and the fact
that primitive-typed arrays can't store undef, what happens here?
my int @a is Array( default = 5 );
@a[0] = 0;
@a[0]; # 0, or 5?
0. Being unable to store 0 would seem to be a major limitation.
But of course.
@a[0] = undef;
@a[0]; # 0, or 5?
An exception or 5.
The first assignment would attempt to convert undef to type int. That's
either an exception or zero, no? The is Array is a constraint on the
container, and should not be entering into the conversion at hand until
you try to STORE the result.
Maybe undefining an element could always set it to the default value.
3) Can the default value be a closure, based on index location?
my @a is Array( default = { $_ ** 2 });
STRAWMAN ANSWER: Yes, because it's cool.
No, because it's unnecessary. You can always do
my $value = @a[$x] //= $x ** 2;
Again, different. You're looking for something like Cifexists=, not
C//=
--
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
Austin Hastings wrote:
--- Austin Hastings [EMAIL PROTECTED] wrote:
No, undef. OTOH, deleting @a[1] would reset it to default.
Ere someone flames my for using a hash keyword in an array context:
s/deleting/absquatulating (e.g., via pop, shift, or splice)/
Unfortunately, I don't think we can base defaultitude on the (non)existence of
an array element. You end up with some rather nasty action-at-a-distance.
Consider:
my @a is default(666);
print @a[2]; # prints 666
@[4] = 1;
print @a[2]; # now prints undef :-(
I think of Cis default as specifying a mapping from an implicit or explicit
Cundef to something else.
I'm not compelled by the counter-argument that this makes it impossible to
store an Cundef in an array with a default. Because the whole point of an
array having a default is to prevent those nasty out-of-range Cundefs from
popping up in the first place.
And thinking of defaults as mappings leads me to conclude that it's
entirely reasonable to allow sub refs as default specifiers, as a means of
creating computed arrays. But I'd expect that the property name is different
in that case (probably Cis computed), so as to distinguish:
# array of subroutine refs
# (default value returned is reference to identity function)
my @funcs is default { return $^arg } = (
{ return 1 },
{ return $^arg ** 2 },
{ return $^arg ** 3 },
# etc.
);
from:
# array of data values
# (default value returned is square of requested index minus 1)
my @vals is computed { return $^index**2-1 } = (
2,
3,
7,
# etc.
);
Damian
Re: More Array Behaviors
On Tue, Jan 28, 2003 at 09:17:36AM -0800, Damian Conway wrote: Errno. That's rather the whole point of Cbut properties [*]. [*] People, we just *have* to find better names for these things! I'd suggest we henceforth call them value properties (for Cbut) and referent properties (for Cis). 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, whereasvirtues sits nicely with bless. I got one private reply, and summarised. But nothing further. Warnock's Dilemma? (Message ID [EMAIL PROTECTED] if that helps - I don't have an archive link). Nicholas Clark
Re: More Array Behaviors
On Mon, Jan 27, 2003 at 01:02:28PM -0800, Austin Hastings wrote: --- Nicholas Clark [EMAIL PROTECTED] wrote: On Mon, Jan 27, 2003 at 11:00:17AM -0800, Michael Lazzaro wrote: locked = 1, # read-only, can't store new values There was a discussion on p5p about restricted hashes, and what one might want. Even for arrays I can think of at least 2 levels. Er, I think I meant I can think of 2 levels, and there may be more 1: everything locked - no new elements, existing elements treated as read only 2: size locked - you can't extend (or shrink) the array, but you can add/remove elements How bizarre. When you said you could think of two levels, I immediately thought of two levels, but mine and yours aren't the same. I thought of totally read-only and content-locked -- expanding/contracting is okay, but no updates. (Think of implementing a stack, say.) Maybe this is my C background coming out. The difference between Hmm. I have a C background too. Anyway, I guess locked means different things to different folks. Probably this shouldn't be core -- it should be easy enough to code up a standard set of permutations. Yes, although it may be useful to have the functionality in core. Then again, perl5 has to do restricted hashes in core to have any hope of doing it with usable speed, whereas parrot is designed to allow perl5 slow perl5 goodies such as tieing and overloading to have no additional calling overhead. (OTOH, it's not unreasonable to talk about a standard set of methods for this stuff, so that all those post-facto implementations speak the same language. Yes, although I suspect that the details of the concepts, let alone the names, can be deferred until later on. Having subroutines and objects would be nicer. Nicholas Clark
Re: Arrays: Default Values
On Tue, Jan 28, 2003 at 12:30:41PM -0800, Austin Hastings wrote: --- Michael Lazzaro [EMAIL PROTECTED] wrote: my int @a is Array( default = 5 ); @a[0] = undef; This should cause a blip of some kind. If storing an explicit undef (as opposed to undef but 0 or C$v = undef; @a[0] = $v; there should be an exception. If storing an implicit undef: convert to int (IOW: 0) and emit a warning. @a[0]; # 0, or 5? I'm not sure. I think I like the idea of @a[0] = undef; being a blip, but undef @a[0]; resetting the value to the default. Conceptually perl5 already has a distinction between assigning undef to an aggregate, and passing an aggregate to the undef operator: $ perl -le '@a = %ENV; print scalar @a; undef @a; print scalar @a' 42 0 $ perl -le '@a = %ENV; print scalar @a; @a = undef; print scalar @a' 42 1 so it's not a great leap to extend this difference to scalar values. Although it may be one leap too far. Nicholas Clark
Re: Spare brackets :-)
On Tue, 2003-01-28 at 11:49, Dan Sugalski wrote:
At 8:47 AM + 1/28/03, Piers Cawley wrote:
Damian Conway [EMAIL PROTECTED] writes:
Sure. But then is this:
$ref[$key]
an array or hash look-up???
Decided at runtime?
How? People use strings as array indices and ints/floats as hash
indices, and count on autoconversion to Make It Work.
And it would. I'm not on one-side or another here, but I do see the
proposal working just fine.
$ref.fetch($key)
works even when $key is a string and $ref is an ARRAY ref.
$ref[$key]
is shorthand for
$ref.[$key]
which is in turn shorthand for
$ref.fetch($key)
and/or
$ref.store($key)
depending on how it's used.
Allowing $ref to be a hash reference doesn't change anything because
HASH's fetch and store methods (no matter how builtin or pre-optimized
they may be) will do the conversion.
You still need C{} vs. C[] for anonymous types, but I don't think
you NEED them for indexing. Now the question becomes, do you WANT them
for readability?
--
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: More Array Behaviors (Take 3)
Michael Lazzaro wrote: Where def is whatever the type-specific ...or user specified... default is, typically Cundef, C0, or C''. Damian
Re: Arrays: Default Values
Austin Hastings wrote:
Another question: If you ask for a value and get it, does the array
grow? Or does that happen only on assignment? (
Arrays (or hashes) don't grow on reading - never.
And another anser from current low level (list.c classes/Array.pmc)
*Return value
*
*
*List get functions return a (void*) pointer to the location of the
*stored data. The caller has to extract the value from this
*pointer.
*
*For non existent data beyond the dimensions of the
*array a NULL pointer is returned.
*
*For non existing data inside sparse holes, a pointer (void*)-1
*is returned.
*The caller can decide to assume these data as undef or 0 or
*whatever is appropriate.
As the returned ptr is a PMC ** you/the class interface can do what is
appropriate:
if (ret == 0)
internal_exception(OUT_OF_BOUNDS, Array index out of bounds!\n);
/* XXX getting non existant value, exception or undef?
* current is for perlarray */
if (ret == (void*) -1)
value = undef(interp);
else {
value = *(PMC**) ret;
if (value == NULL) /* XXX same here */
value = undef(interp);
}
leo
Re: Arrays: Default Values
On Tue, 2003-01-28 at 16:23, Leopold Toetsch wrote: Austin Hastings wrote: Another question: If you ask for a value and get it, does the array grow? Or does that happen only on assignment? ( Arrays (or hashes) don't grow on reading - never. Never say never. You're correct for pure reading like so: $x = @a[0]; But for less pure forms of reading: foo(@a[0]); auto-vivification will have to happen in some cases. e.g. if foo requires a lvalue parameter. You can't know if an actual write will happen, so you have to auto-vivify in order to pass a reference. Or did I miss something there? -- 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 :-)
At 4:17 PM -0500 1/28/03, Aaron Sherman wrote: Now the question becomes, do you WANT them for readability? Given that Larry's answer has been a resounding yes all along, the technical reasons (Which are, themselves, sufficient) are pretty irrelevant. -- 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 Tuesday, January 28, 2003, at 01:14 PM, Damian Conway wrote:
I'm not compelled by the counter-argument that this makes it
impossible to store an Cundef in an array with a default. Because
the whole point of an array having a default is to prevent those nasty
out-of-range Cundefs from popping up in the first place.
And thinking of defaults as mappings leads me to conclude that it's
entirely reasonable to allow sub refs as default specifiers, as a
means of creating computed arrays. But I'd expect that the property
name is different in that case (probably Cis computed), so as to
distinguish:
The next (oft-asked) question is whether or not Cis computed denotes
read-only, or if you can store to an Cis computed array.
my @a is computed { $^index**2 };
@a[4] = 'something completely different';
And things like this would be downright hysterical:
my @a is computed { $^index**2 };
pop @a;
:-)
MikeL
Re: Spare brackets :-)
On Tue, 2003-01-28 at 16:34, Dan Sugalski wrote: At 4:17 PM -0500 1/28/03, Aaron Sherman wrote: Now the question becomes, do you WANT them for readability? Given that Larry's answer has been a resounding yes all along, I'm not sure that this specific case was brought up. I remember Larry weighing in on the thread about using [] as the only list constructor, but that's a different issue. Granted, I've been away focusing on work, so I may have missed it. the technical reasons (Which are, themselves, sufficient) are pretty irrelevant. 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? -- 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 Tuesday, January 28, 2003, at 01:01 PM, Nicholas Clark wrote: On Tue, Jan 28, 2003 at 12:30:41PM -0800, Austin Hastings wrote: --- Michael Lazzaro [EMAIL PROTECTED] wrote: my int @a is Array( default = 5 ); @a[0] = undef; This should cause a blip of some kind. If storing an explicit undef (as opposed to undef but 0 or C$v = undef; @a[0] = $v; there should be an exception. If storing an implicit undef: convert to int (IOW: 0) and emit a warning. Hmm. I don't have a strong preference either way, but I'm not sure why (given Cmy int @a): @a[ undef ] Cundef should be autoconverted to 0 with warning, but in: @a[0] = undef; Cundef should _not_ be autoconverted to 0, but instead trigger an exception. They're both in Cint context, unless we want to make a special int being used as an array index context that's different from normal Cint context. Seems like Cundef should be treated like 0 (plus warning) in numeric context either everywhere, or nowhere. (?) MikeL
Re: Spare brackets :-)
At 5:07 PM -0500 1/28/03, Aaron Sherman wrote: On Tue, 2003-01-28 at 16:34, Dan Sugalski wrote: At 4:17 PM -0500 1/28/03, Aaron Sherman wrote: Now the question becomes, do you WANT them for readability? Given that Larry's answer has been a resounding yes all along, I'm not sure that this specific case was brought up. I am. Larry was clear--square brackets for array access, squiggle brackets for hash access. -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Arrays: Default Values
--- Damian Conway [EMAIL PROTECTED] wrote: Austin Hastings wrote: --- Austin Hastings [EMAIL PROTECTED] wrote: No, undef. OTOH, deleting @a[1] would reset it to default. Ere someone flames my for using a hash keyword in an array context: s/deleting/absquatulating (e.g., via pop, shift, or splice)/ Unfortunately, I don't think we can base defaultitude on the (non)existence of an array element. You end up with some rather nasty action-at-a-distance. Consider: my @a is default(666); print @a[2];# prints 666 @[4] = 1; print @a[2];# now prints undef :-( I think of Cis default as specifying a mapping from an implicit or explicit Cundef to something else. I don't understand your example. Can you explain it again, using words of less than one syllable? What's @[4]? Why does it (even if it's a typo from @a[4]) cause @a[2] to become defined? (Small != dense) If it does become defined, why doesn't it get the default value -- no-one explicitly told it to be undef? I'm not compelled by the counter-argument that this makes it impossible to store an Cundef in an array with a default. Because the whole point of an array having a default is to prevent those nasty out-of-range Cundefs from popping up in the first place. The point of having a default is to replace those undefs with something else. To prevent them from appearing would require rewriting ones code in such a way that extraordinary arrefs didn't happen. But given that I can replace undef with 'fednu' in these cases, I'd now like to reduce/reuse/recycle my undefs back as meaningful values -- they're not reserved for the special case of LOCALE=noaquistan any more. And thinking of defaults as mappings leads me to conclude that it's entirely reasonable to allow sub refs as default specifiers, as a means of creating computed arrays. But I'd expect that the property name is different in that case (probably Cis computed), so as to distinguish: [[ code elided ]] Yeah, that too. I like is computed. =Austin
Re: More Array Behaviors (Take 3)
Michael Lazzaro wrote: 2) There is NO platform-dependent maximum array size. If it's not a sparse array, you'll run out of memory long before you run out of indexes, but using bigints as indexes for sparse arrays is OK. Current: array size is limited to $arch's +INTVAL (2^31-1 / 2^63-1). Arrays get sparse by default if you set arrays elements with indices distance ~3K. IMHO if you need bigger indices use a hash. MikeL leo
Re: Arrays: Default Values
Austin Hastings wrote: --- Austin Hastings [EMAIL PROTECTED] wrote: No, undef. OTOH, deleting @a[1] would reset it to default. Ere someone flames my for using a hash keyword in an array context: s/deleting/absquatulating (e.g., via pop, shift, or splice)/ What's wrong with Cdelete in an array context? If there's to be a distinction between storing an undef value and resetting to the default value -- and, having read Damian's thoughts on the matter, I'm almost convinced that there shouldn't be -- then I think it's much more obvious to distinguish Cdelete and Cundef rather than Cundef @a[1] and C@a[1] = undef. Smylers
Re: Arrays: Default Values
--- Michael Lazzaro [EMAIL PROTECTED] wrote: On Tuesday, January 28, 2003, at 01:01 PM, Nicholas Clark wrote: On Tue, Jan 28, 2003 at 12:30:41PM -0800, Austin Hastings wrote: --- Michael Lazzaro [EMAIL PROTECTED] wrote: my int @a is Array( default = 5 ); @a[0] = undef; This should cause a blip of some kind. If storing an explicit undef (as opposed to undef but 0 or C$v = undef; @a[0] = $v; there should be an exception. If storing an implicit undef: convert to int (IOW: 0) and emit a warning. Hmm. I don't have a strong preference either way, but I'm not sure why (given Cmy int @a): @a[ undef ] Cundef should be autoconverted to 0 with warning, but in: @a[0] = undef; Cundef should _not_ be autoconverted to 0, but instead trigger an exception. They're both in Cint context, unless we want to make a special int being used as an array index context that's different from normal Cint context. Seems like Cundef should be treated like 0 (plus warning) in numeric context either everywhere, or nowhere. (?) I agree. Warning: Using undef as array index would be a nice message - probably save a bunch of debugging. =Austin
Re: Arrays: Default Values
On Tue, Jan 28, 2003 at 02:13:22PM -0800, Michael Lazzaro wrote: Hmm. I don't have a strong preference either way, but I'm not sure why (given Cmy int @a): @a[ undef ] Cundef should be autoconverted to 0 with warning, but in: @a[0] = undef; Cundef should _not_ be autoconverted to 0, but instead trigger an exception. They're both in Cint context, unless we want to make a special int being used as an array index context that's different from normal Cint context. Seems like Cundef should be treated like 0 (plus warning) in numeric context either everywhere, or nowhere. (?) Hmm. You've got me there. I don't have an answer that's consistent. Unless the context is allowed to govern whether undef conversion is allowable, or an exception. But that feels complex. I think the answer is it depends, and some of the time I'd like each different permutation of behaviour. Nicholas Clark
Re: Arrays: Default Values
Austin Hastings wrote: --- Damian Conway [EMAIL PROTECTED] wrote: my @a is default(666); print @a[2]; # prints 666 @a[4] = 1; print @a[2]; # now prints undef :-( [typo in third line corrected] I don't understand your example. Can you explain it again, using words of less than one syllable? If the scheme is (as someone was advocating) that the default is used only in place of elements that don't exist (as opposed to elements that are allocated but contain Cundef), then allocating a previously unallocated element has the potential to change the value it returns, even if that previously unallocated element is not initialized when allocated. So, assigning to @a[4], causes @a[0..3] to be created as well. Which, under a default-for-non-existent-elements-only policy causes @a[2] to stop returning the default. What's @[4]? Why does it (even if it's a typo from @a[4]) cause @a[2] to become defined? It doesn't. It causes it to exist. I understood that it was being advocating that only non-existent elements returned the default. This is why that's a bad idea. If it does become defined, why doesn't it get the default value -- no-one explicitly told it to be undef? Because the whole idea of a default value is that you *don't* put it in every element. The lack of a value in an element is what triggers the default value to be returned. And in Perl Cundef is how we signify the absence of a value. Damian
Re: Arrays: Default Values
Nicholas Clark wrote: I'm not sure. I think I like the idea of @a[0] = undef; being a blip, but undef @a[0]; resetting the value to the default. That thought crossed my mind as well before I got to your message ... Conceptually perl5 already has a distinction between assigning undef to an aggregate, and passing an aggregate to the undef operator: ... however I'm unconvinced that that's the sort of distinction that should be encouraged. Smylers
Re: Arrays: Default Values
On Tue, Jan 28, 2003 at 04:07:17PM -0500, Aaron Sherman wrote:
I think this debate is easier if you think of defaults as overriding and
auto-vivification method on a container.
Hmm. I don't :-)
I think it is easier if you think of defaults as overriding undef.
On Tue, 2003-01-28 at 14:47, Paul Johnson wrote:
Michael Lazzaro said:
2a) When a cell is explicitly re-undefined, does the default value take
effect?
my @a is Array( default = 'foo' ) = (1,2,3);
@a[1] = undef;
@a[1]; # undef, or 'foo'?
STRAWMAN ANSWER: 'foo'.
Seems right to me. Anything else would be very confusing, I think.
This would be very confusing to me. In fact, it seems WRONG to me unless
we're saying that such arrays can simply never hold an undefined
value... which again seems wrong.
I think that seems right.
my @a is Array ( default = 'foo' );
@a[1] = undef;
Should yield the following, I would think:
('foo', undef, 'foo' x Inf)
Though, obviously there's no such thing as @a[2], but if you reference
it, that's how it would auto-vivify.
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.
--
Paul Johnson - [EMAIL PROTECTED]
http://www.pjcj.net
Re: Spare brackets :-)
On Tue, Jan 28, 2003 at 09:24:50AM -0800, Austin Hastings wrote: --- Dan Sugalski [EMAIL PROTECTED] wrote: At 8:47 AM + 1/28/03, Piers Cawley wrote: $ref[$key] an array or hash look-up??? Decided at runtime? How? People use strings as array indices and ints/floats as hash indices, and count on autoconversion to Make It Work. On the one hand: Java/ECMA/J-script does it. That's nice, but Perl isn't Java/ECMAScript/JavaScript/JScript/C/C++/Pascal. It's Perl. Perl uses square brackets for arrays, and curly braces for hashes. Period. And Perl 6 will continue in the path of Perl 1..5, *not* in the path of some other broken syntax. If you have any questions about this, please refer to the 1st, 2nd, or 3rd editions of Programming Perl, or to any of the millions of Perl programmers who have that distinction hard-wired into their wetware. Z.
Re: Arrays: Default Values
On Tue, Jan 28, 2003 at 03:06:19PM -0800, Damian Conway wrote:
Austin Hastings wrote:
--- Damian Conway [EMAIL PROTECTED] wrote:
my @a is default(666);
print @a[2];# prints 666
@a[4] = 1;
print @a[2];# now prints undef :-(
[typo in third line corrected]
I don't understand your example. Can you explain it again, using words
of less than one syllable?
If the scheme is (as someone was advocating) that the default is used only
in place of elements that don't exist (as opposed to elements that are
allocated but contain Cundef), then allocating a previously unallocated
element has the potential to change the value it returns, even if that
previously unallocated element is not initialized when allocated.
So, assigning to @a[4], causes @a[0..3] to be created as well. Which,
under a default-for-non-existent-elements-only policy causes @a[2] to stop
returning the default.
It doesn't have to be that way:
$ perl -le 'sub e { print exists $a[shift] ? 1 : 0 } e 2; $a[4]++; e 2; e 4; delete
$a[4]; e 2; e 4'
0
0
1
0
0
No, I don't know which side I'm arguing anymore :-)
Actually, I do. I don't like exists on arrays.
--
Paul Johnson - [EMAIL PROTECTED]
http://www.pjcj.net
Re: Arrays: Default Values
Michael Lazzaro wrote:
The next (oft-asked) question is whether or not Cis computed denotes
read-only, or if you can store to an Cis computed array.
my @a is computed { $^index**2 };
@a[4] = 'something completely different';
I'd expect that Cis computed and Cis constant would be orthogonal.
And things like this would be downright hysterical:
my @a is computed { $^index**2 };
pop @a;
Returns 1, of course. Since the $^index for a Cpop is always -1.
;-)
Damian
Re: Arrays: Default Values
Michael Lazzaro wrote:
2a) When a cell is explicitly re-undefined, does the default value take
effect?
my @a is Array( default = 'foo' ) = (1,2,3);
@a[1] = undef;
@a[1]; # undef, or 'foo'?
STRAWMAN ANSWER: 'foo'.
If Cundef is a valid value for a cell, then I should be able to store
it. I think that Cdelete would better convey the intent -- it would
also help with the behavior of negative indexes.
2b) Primitive-typed arrays: Given the behavior of (2a), and the fact
that primitive-typed arrays can't store undef, what happens here?
my int @a is Array( default = 5 );
@a[0] = 0;
@a[0]; # 0, or 5?
Definitely 0. Definitely 0. DEFINITELY ZERO.
@a[0] = undef;
@a[0]; # 0, or 5?
STRAWMAN ANSWER: 5, in both cases. So don't do that unless you mean
it.
0: see (2a)
3) Can the default value be a closure, based on index location?
my @a is Array( default = { $_ ** 2 });
STRAWMAN ANSWER: Yes, because it's cool.
sounds good. But we wqant to ensure that the default value can actually
be a closure -- i.e. its not a Cdefault if we execute it.
3a) NOTE that closure-based defaults effectively render the array
infinite. Therefore -- If the requested index is negative, what happens?
@a[-5];
STRAWMAN ANSWER: The closure just gets a negative number as the
requested index.
It's up to you to make it work, if you want it to.
Yes
3b) Does an infinite array still get an exception thrown when trying
to access an infinite [Inf] or [-Inf] index?
STRAWMAN ANSWER: Yes, it does.
Should follow (3a): the generator can through the exception if desired.
Now, what about @a[2.5]: can my generator do interpolation?
Dave.
--
http://dave.whipp.name
Re: Arrays: Default Values
Aaron Sherman wrote: auto-vivification will have to happen in some cases. e.g. if foo requires a lvalue parameter. You can't know if an actual write will happen, so you have to auto-vivify in order to pass a reference. Or did I miss something there? I think the idea is to use a special object which, if assigned to, will create the required element. Dave. -- http://dave.whipp.name
Re: Arrays: Default Values
So ... with the discussion of what if i really wanted to put an undef in there b/c it's not just that i haven't defined it but rather that it really isn't defined. I KNOW it's not defined, and i'm now explicitly saying it's undefined as opposed to before when i was implicitly suggesting that i didn't know what it was and used a default 'unknown' discussion ... What we really need is: @a[2] = undef but undef; or, possibly (more tongue-in-cheek-y) @a[2] = undef but seriously; so the ... property? would say you have a default, maybe, but i don't care. this is REALLY undef is that possible? aside from it being disturbing to write undef but undef :o --attriel (the first suggestion is serious, but the syntax is flawed; the second suggestion has better syntax but is tongue-in-cheek suggested ... )
Re: Arrays: Default Values
attriel wrote: So ... with the discussion of what if i really wanted to put an undef in there b/c it's not just that i haven't defined it but rather that it really isn't defined. I KNOW it's not defined, and i'm now explicitly saying it's undefined as opposed to before when i was implicitly suggesting that i didn't know what it was and used a default 'unknown' discussion ... What we really need is: @a[2] = undef but undef; or, possibly (more tongue-in-cheek-y) @a[2] = undef but seriously; so the ... property? would say you have a default, maybe, but i don't care. this is REALLY undef is that possible? aside from it being disturbing to write undef but undef :o --attriel (the first suggestion is serious, but the syntax is flawed; the second suggestion has better syntax but is tongue-in-cheek suggested ... ) What about: undef @a[2]; or possibly even (although I would argue that undef should remain a unary operator only): @a[2].undef(); Joseph F. Ryan [EMAIL PROTECTED]
