Austin Hastings <[EMAIL PROTECTED]> writes:
> --- "Joseph F. Ryan" <[EMAIL PROTECTED]> wrote:
>> If the final design stays the way it is now, there really won't be
>> a "lexer". Instead, a perl6 grammar parses the data, and builds up
>> a huge match-object as it, well, matches. This match object
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]
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
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.)
--- 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" <[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
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
"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
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
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
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 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']
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]
"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
--- 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
> @
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}
--- 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
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
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 b
On Sat, 25 Jan 2003, Damian Conway wrote:
> As far as I know Larry is not planning to remove the functional
> forms of C, C, etc.
>
> Those forms may, it's true, become mere wrappers for the OO forms.
> But I confidently expect they will still be available.
Hmmm, so that means that they should be
Damian Conway wrote:
> Correct. Although presumably this:
>
> my @d = @x »but« Foo;
Damian, somewhere in the conversation on hyper-ops you switched over from this syntax:
my @sum = @a «+» @b;
to this syntax:
my @sum = @a »+« @b;
(Since those two statements use non-ASCII charac
> And, please, let's spawn no threads talking about how parentheses in font Foo
> on platform Bar look like they point outwards. Ulk.
Er... I meant to say "inwards". Else that sentence makes NO sense.
Double Ulk.
=thom
"You live and learn. Or you don't live long." --Lazarus Long
Thomas A. Boyer wrote:
Damian, somewhere in the conversation on hyper-ops you switched over from this syntax:
my @sum = @a «+» @b;
to this syntax:
my @sum = @a »+« @b;
> Would you care to share your thoughts on why you've gone with
inward-pointing guillemets?
Because that's what L
The Perl 6 Summary for the week ending 20030126
Welcome to the first Perl 6 summary of the new 'Copious Free Time
enabled' era, which should mean that these summaries will get mailed out
on Monday evening from now on.
We start, as usual, with perl6-internals
The eval patch
L
24 matches
Mail list logo
