Dan Sugalski [EMAIL PROTECTED] wrote:
Px = Py[Pz]
won't be, and we'll need to note whether Pz should be taken as an
int, string, or PMC. (PMC for the fancier keying of hashes)
... A simple :i, :s, :p [...] suffix
Do we really need that? The aggregate is responsible to do the right
Dan Sugalski [EMAIL PROTECTED] wrote:
*) We consider ways to make slices. I can see ops, or I can see basic
functions. Either is fine, depends on how often the things are used.
I'll start from the end of the proposal. What about just extending the
keyed syntax:
Px = Py[0] # key
At 11:25 AM +0200 6/16/04, Leopold Toetsch wrote:
Dan Sugalski [EMAIL PROTECTED] wrote:
*) We consider ways to make slices. I can see ops, or I can see basic
functions. Either is fine, depends on how often the things are used.
I'll start from the end of the proposal. What about just extending
Dan Sugalski wrote:
Which reminds me--we need to have a syntax to distinguish between
key types.
Perl already gives us two of the three:
Px[Iy]
Px{Sy}
For the third, I suggest we extend the analogy:
PxPz
--
Brent Dax Royal-Gordon [EMAIL PROTECTED]
Perl and Parrot hacker
Oceania has
At 10:06 AM -0700 6/16/04, Brent 'Dax' Royal-Gordon wrote:
Dan Sugalski wrote:
Which reminds me--we need to have a syntax to distinguish between key types.
Perl already gives us two of the three:
Px[Iy]
Px{Sy}
For the third, I suggest we extend the analogy:
PxPz
Except it breaks really
At 7:48 PM +0200 6/16/04, Eirik Berg Hanssen wrote:
Dan Sugalski [EMAIL PROTECTED] writes:
At 10:06 AM -0700 6/16/04, Brent 'Dax' Royal-Gordon wrote:
Dan Sugalski wrote:
Which reminds me--we need to have a syntax to distinguish between
key types.
Perl already gives us two of the three:
Dan Sugalski [EMAIL PROTECTED] writes:
At 10:06 AM -0700 6/16/04, Brent 'Dax' Royal-Gordon wrote:
Dan Sugalski wrote:
Which reminds me--we need to have a syntax to distinguish between key types.
Perl already gives us two of the three:
Px[Iy]
Px{Sy}
For the third, I suggest we extend
Dan Sugalski wrote:
Yeah, but given that this code will be generated by compilers 90+% of
the time... the assembly generation and parsing of the assembly's easier
with the postfix notation.
My understanding is that compilers will generate an AST, not textual
PIR. Thus, we are looking for a
On Tue, 15 Jun 2004, Dan Sugalski wrote:
So, given that, should plain scalars act as iterators holding a single
value and implement the iterator protocol?
That'd be messy if two things tried to take an iterator over the same scalar
as the same time. On the other hand if it created an iterator
Okay, before we go any further, I think it's important to note that
we're going to restrict ourselves to unidimensional slices for the
time being. Yes, I know, we probably need to deal with
multidimensional slices at some point (and I say probably since there
are quite a number of different
Since we're going to need these, and I'm in a documenting and
defining mood (yes, I am making a final decision on strings today.
Whee!) I figure we need to tackle them.
First, slices. Perl's got 'em, Python has them, Ruby, interestingly,
doesn't. (Sort of) A slice is a subset of elements in an
Dan Sugalski writes:
The slice vtable entry should take as its parameter a slice pmc. This
should be an array of typed from/to values, so we can do something
like:
@foo[0..2,4..8,12..];
with three entries in the slice array--one with a from/to of 0/2, one
with 4/8, and one with
At 1:21 PM -0600 6/14/04, Luke Palmer wrote:
Dan Sugalski writes:
The slice vtable entry should take as its parameter a slice pmc. This
should be an array of typed from/to values, so we can do something
like:
@foo[0..2,4..8,12..];
with three entries in the slice array--one with a from/to
Dan Sugalski writes:
At 1:21 PM -0600 6/14/04, Luke Palmer wrote:
Dan Sugalski writes:
The slice vtable entry should take as its parameter a slice pmc. This
should be an array of typed from/to values, so we can do something
like:
@foo[0..2,4..8,12..];
with three entries in the
14 matches
Mail list logo
