Dan Sugalski <[EMAIL PROTECTED]> writes:
> At 9:24 PM + 1/21/03, Piers Cawley wrote:
>>Dan Sugalski <[EMAIL PROTECTED]> writes:
>> > Hrm, interesting. Single symbol table for methods and attributes,
>>> though that's not too surprising all things considered. That may make
>>> interoperabili
At 11:52 AM + 1/27/03, Piers Cawley wrote:
Dan Sugalski <[EMAIL PROTECTED]> writes:
At 9:24 PM + 1/21/03, Piers Cawley wrote:
Dan Sugalski <[EMAIL PROTECTED]> writes:
> Hrm, interesting. Single symbol table for methods and attributes,
though that's not too surprising all things co
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
Dan Sugalski <[EMAIL PROTECTED]> writes:
> At 11:52 AM + 1/27/03, Piers Cawley wrote:
>>Dan Sugalski <[EMAIL PROTECTED]> writes:
>>
>>> At 9:24 PM + 1/21/03, Piers Cawley wrote:
Dan Sugalski <[EMAIL PROTECTED]> writes:
> Hrm, interesting. Single symbol table for methods and att
So more changes in packfile and related files, including:
- all packfile segments share a common header which is effectively
the format of a byte_code segment
- all packfile segments conforming to this format are unpacked with
the default_unpack routine, which just sets up a pointer to
the d
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
Nicholas Clark <[EMAIL PROTECTED]> writes:
[...]
> > struct Chunk {
> > opcode_t type;
> > opcode_t version;
> > opcode_t size;
> > void data[];
> > };
will this ever compile?
void data[] is not allowed, and even char data[] is an incomplet
On 27 Jan 2003, Juergen Boemmels wrote:
> Nicholas Clark <[EMAIL PROTECTED]> writes:
> > > struct Chunk {
> > > opcode_t type;
> > > opcode_t version;
> > > opcode_t size;
> > > void data[];
> > > };
> > I agree with the "roughly" bit, but I'd suggest
Juergen Boemmels wrote:
Nicholas Clark <[EMAIL PROTECTED]> writes:
struct Chunk {
opcode_t type;
opcode_t version;
opcode_t size;
void data[];
};
will this ever compile?
It's similar to "opcode_t *data". If size == 0, no data follow in byte
stream. byte_code_{un,}pack is implem
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
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
--- 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
--- Juergen Boemmels <[EMAIL PROTECTED]> wrote:
> Nicholas Clark <[EMAIL PROTECTED]> writes:
> > I guess in future once the normal JIT works, and we've got the pigs
> flying
> > nicely then it would be possible to write a Not Just In Time
> compiler that
> > saves out assembly code and relocation
All~
It occurs to me that no one has mentioned ML. ML would be a pretty good
language to compile to parrot, and has reasonably strong usage in academic
circle...
Matt
> -Original Message-
> From: K Stol [mailto:[EMAIL PROTECTED]]
> Sent: Tuesday, January 21, 2003 3:18 AM
> To: [EMAIL PR
33 matches
Mail list logo
