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 is then
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
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.
--- 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, based on
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 ability
Dave Whipp suggested:
The size constraints are probably Cbut properties, as is Clocked. The
exception behavior probably deserves to remain an Cis property.
Nope. They're all Cis properties. Cbut properties only apply to *values*.
Variable such as Arrays always take Cis properties.
Damian
Damian Conway [EMAIL PROTECTED] wrote in message
[EMAIL PROTECTED]">news:[EMAIL PROTECTED]...
Dave Whipp suggested:
The size constraints are probably Cbut properties, as is Clocked.
The
exception behavior probably deserves to remain an Cis property.
Nope. They're all Cis properties. Cbut
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
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
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'] #
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 Cbut properties.
And yes, that includes Array
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
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
On Sat, 25 Jan 2003, Damian Conway wrote:
As far as I know Larry is not planning to remove the functional
forms of Cmap, Cgrep, 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
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
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
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
20 matches
Mail list logo
