--- 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 C<is 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
