> 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 a
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 re
--- 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 envisio
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."
>
> C
--- 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 "val
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).
Arr
Michael Lazzaro wrote:
Where is whatever the type-specific
...or user specified...
default is, typically C, C<0>, or C<''>.
Damian
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 a
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 (f
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] # (warning: index out-of-bounds
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
--- 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
> C) and "referent" properties (for C).
Hmm. According to this, C would therefore be a
malvalapropism, no?
=Austi
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
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.
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 f
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
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
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 it
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
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 pointin
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 presum
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 th
--- Dave Whipp <[EMAIL PROTECTED]> wrote:
> "Damian Conway" <[EMAIL PROTECTED]> wrote in message
> [EMAIL PROTECTED]">news:[EMAIL PROTECTED]...
> >Anything that "holds" anything is a variable, not a value.
> > [...]
> > I'm saying that only scalar *values* can have C properties.
> > And yes, that
--- Damian Conway <[EMAIL PROTECTED]> wrote:
> Note that converting to and from C in numeric contexts is much
> less troublesome in Perl 6, because the C operator makes it
> trivial to
> catch bad cases and handle them appropriately:
>
> @a[$str//0] // silently convert to zero
> @
"Damian Conway" <[EMAIL PROTECTED]> wrote in message
[EMAIL PROTECTED]">news:[EMAIL PROTECTED]...
>Anything that "holds" anything is a variable, not a value.
> [...]
> I'm saying that only scalar *values* can have C properties.
> And yes, that includes Array references, but not arrays.
>
> > My men
Michael Lazzaro wrote:
1) Edge cases in array indexing:
@a[ undef ] # undef, or 1?
@a['foo'] # undef, or 1?
These should generate warnings, at least.
I don't know whether undef or 1 is more correct.
It's certainly a legitimate question. (I'm not sure that @a[undef] ==
@a[0]
On Mon, 27 Jan 2003, Michael Lazzaro wrote:
> Some requests for verification, plus additional questions. If anyone
> has any arguments/clarifications/questions on these, please discuss so
> I can document.
>
> 1) Edge cases in array indexing:
>
> @a[ undef ] # undef, or 1?
> @a['foo']
On Monday, January 27, 2003, at 01:15 PM, Dave Whipp wrote:
"Michael Lazzaro" <[EMAIL PROTECTED]> wrote in message
... if such capabilities exist, what are their real names? Can
anyone think of any that are absolute must-haves? Are any of the
above
must-haves?
I think that the only must-
On Monday, January 27, 2003, at 11:46 AM, John Williams wrote:
On Mon, 27 Jan 2003, Michael Lazzaro wrote:
1) Edge cases in array indexing:
@a[ undef ] # undef, or 1?
@a['foo'] # undef, or 1?
These should generate warnings, at least.
I don't know whether undef or 1 is more cor
This confuses me: I thought an array *is* a value.
Nope. Arrays are variables.
Sure, its a value that holds other values:
Anything that "holds" anything is a variable, not a value.
Are you saying that only scalars have C properties
(i.e. an ArrayRef can, but an array can't)?
I'm saying
"Damian Conway" <[EMAIL PROTECTED]> wrote in message
[EMAIL PROTECTED]">news:[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 prope
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.
Damian
"Michael Lazzaro" <[EMAIL PROTECTED]> wrote in message
[EMAIL PROTECTED]">news:[EMAIL PROTECTED]...
>... if such capabilities exist, what are their real names? Can
> anyone think of any that are absolute must-haves? Are any of the above
> must-haves?
I think that the only must-have is the a
--- Nicholas Clark <[EMAIL PROTECTED]> wrote:
> On Mon, Jan 27, 2003 at 11:00:17AM -0800, Michael Lazzaro wrote:
>
> > resize => (1024), # internal blocksize (in indexes)
> ># by which array expands?
> > resize => { $_ * 2 }, # or via closure,
Michael Lazzaro wrote:
I have some answers from current low level implementation.
2) As hinted above, is there a (platform-dependent) maximum addressable
array index, or do we promise to correctly handle all integers, even if
BigInt? (This might come into play for lazy/sparse arrays. Maybe.)
On Mon, Jan 27, 2003 at 11:00:17AM -0800, Michael Lazzaro wrote:
> resize => (1024), # internal blocksize (in indexes)
># by which array expands?
> resize => { $_ * 2 }, # or via closure, based on current size?
I think you're making too many a
Some requests for verification, plus additional questions. If anyone
has any arguments/clarifications/questions on these, please discuss so
I can document.
1) Edge cases in array indexing:
my int @a = (1,2,3);
@a[0] # 1
@a[1] # 2
@a[2] # 3
@a[3]
37 matches
Mail list logo
