On Mon, Mar 31, 2008 at 11:33:42PM -0400, Bob Rogers wrote:
> Do you remember the discussion two years ago [1] about eliminating the
> user stack in favor of arrays? Chip made the following comment [2]:
>
> From: Chip Salzenberg <[EMAIL PROTECTED]>
> Subject: User stack: Worthwhile?
>
On Monday 31 March 2008 20:33:42 Bob Rogers wrote:
> Do you remember the discussion two years ago [1] about eliminating the
> user stack in favor of arrays? Chip made the following comment [2]:
>
> From: Chip Salzenberg <[EMAIL PROTECTED]>
> Subject: User stack: Worthwhile?
> Da
On Mon, Mar 31, 2008 at 8:33 PM, Bob Rogers
<[EMAIL PROTECTED]> wrote:
>From: "Patrick R. Michaud" <[EMAIL PROTECTED]>
>Date: Mon, 31 Mar 2008 13:53:25 -0500
>
>
>On Sat, Mar 29, 2008 at 02:48:11PM -0700, chromatic wrote:
>> On Thursday 27 March 2008 18:20:21 Patrick R. Michaud wrot
From: "Patrick R. Michaud" <[EMAIL PROTECTED]>
Date: Mon, 31 Mar 2008 13:53:25 -0500
On Sat, Mar 29, 2008 at 02:48:11PM -0700, chromatic wrote:
> On Thursday 27 March 2008 18:20:21 Patrick R. Michaud wrote:
> > 2. Add shift/unshift/push/pop methods to ResizablePMCArray
> > (or o
On Sat, Mar 29, 2008 at 02:48:11PM -0700, chromatic wrote:
> On Thursday 27 March 2008 18:20:21 Patrick R. Michaud wrote:
> > 2. Add shift/unshift/push/pop methods to ResizablePMCArray
> > (or one of its superclasses) in Parrot
>
> This is my preference. It feels like a role.
This is my prefere
On Thursday 27 March 2008 18:20:21 Patrick R. Michaud wrote:
> Actually, it can be done without subclassing via the following
>
> .namespace [ 'ResizablePMCArray' ]
>
> .sub 'unshift' :method
> .param pmc list
> .param pmc value
> unshift list, value
> .end
>
> .sub 'shift' :method
>
On Fri, Mar 28, 2008 at 04:35:42PM +0100, Klaas-Jan Stol wrote:
>
> attached an updated patch including some tests.
Patch applied in r26597. I made a few modifications before
applying:
- Updated the precedence of postfix:++ and postfix:-- to match
- Fixed the relational ops to use e.g., infix:
thanks for the clarifications;
attached an updated patch including some tests.
I left out += and friends for now.
kjs
On Fri, Mar 28, 2008 at 4:18 PM, Patrick R. Michaud <[EMAIL PROTECTED]> wrote:
> On Fri, Mar 28, 2008 at 02:41:28PM +0100, Klaas-Jan Stol wrote:
> > On Fri, Mar 28, 2008 at 1:4
On Fri, Mar 28, 2008 at 02:41:28PM +0100, Klaas-Jan Stol wrote:
> On Fri, Mar 28, 2008 at 1:41 PM, Patrick R. Michaud <[EMAIL PROTECTED]> wrote:
> > It really needs to be inc/dec. And not only that, but the output
> > value of postfix ++ and -- needs to be the value _before_ the
> > inc/dec op
On Fri, Mar 28, 2008 at 1:41 PM, Patrick R. Michaud <[EMAIL PROTECTED]> wrote:
> On Fri, Mar 28, 2008 at 10:51:16AM +0100, Klaas-Jan Stol wrote:
> > Attached is a patch implementing:
> >
> > * ++ and -- postfix operators, implemented as n_sub and n_add (taking
> > "1" as the 3rd operand), this
On Fri, Mar 28, 2008 at 07:41:25AM -0500, Patrick R. Michaud wrote:
> Ideally += should be implemented as the two-argument 'add' opcode
> in PIR... something like
>
> add %0, %1
>
> But the PAST compiler doesn't yet have a great way for distinguishing
> a 2-argument add from a 3-argument add.
On Fri, Mar 28, 2008 at 10:51:16AM +0100, Klaas-Jan Stol wrote:
> Attached is a patch implementing:
>
> * ++ and -- postfix operators, implemented as n_sub and n_add (taking
> "1" as the 3rd operand), this is because each instruction must have an
> output register as far as I can tell (so "inc"/"d
On Fri, Mar 28, 2008 at 2:20 AM, Patrick R. Michaud <[EMAIL PROTECTED]> wrote:
> On Thu, Mar 27, 2008 at 10:33:54PM +0100, Klaas-Jan Stol wrote:
> > On Wed, Mar 26, 2008 at 6:30 PM, Patrick R. Michaud <[EMAIL PROTECTED]>
> wrote:
> > > On Wed, Mar 26, 2008 at 02:25:06PM +0100, Klaas-Jan Stol wro
On Thu, Mar 27, 2008 at 10:33:54PM +0100, Klaas-Jan Stol wrote:
> On Wed, Mar 26, 2008 at 6:30 PM, Patrick R. Michaud <[EMAIL PROTECTED]> wrote:
> > On Wed, Mar 26, 2008 at 02:25:06PM +0100, Klaas-Jan Stol wrote:
> > > * list ops ( I think this is meant by list ops? )
> > > All languages that ha
On Wed, Mar 26, 2008 at 6:30 PM, Patrick R. Michaud <[EMAIL PROTECTED]> wrote:
> On Wed, Mar 26, 2008 at 02:25:06PM +0100, Klaas-Jan Stol wrote:
> > having used NQP a bit, I feel like I'm missing a few things. I'm not
> > entirely sure what the fate of NQP is; will it always be a bootstrap
> > s
On Wed, Mar 26, 2008 at 09:12:18AM -0700, Geoffrey Broadwell wrote:
> > Being able to write
> >
> > unshift @?BLOCK, $?BLOCK;
> >
> > would be useful, as it prevents the need for creating the List class
> > over and over again.
> > I feel that these ops are so basic, it would be well worth it to
On Wed, Mar 26, 2008 at 02:25:06PM +0100, Klaas-Jan Stol wrote:
> having used NQP a bit, I feel like I'm missing a few things. I'm not
> entirely sure what the fate of NQP is; will it always be a bootstrap
> stage for Perl 6,or is it a tool for now and will it be discarded
> later on.
Neither! It
>From the point of view of someone working through the PCT tutorial
(quite rockin', BTW!):
On Wed, 2008-03-26 at 14:25 +0100, Klaas-Jan Stol wrote:
> having used NQP a bit, I feel like I'm missing a few things. I'm not
> entirely sure what the fate of NQP is; will it always be a bootstrap
> stage
hi,
having used NQP a bit, I feel like I'm missing a few things. I'm not
entirely sure what the fate of NQP is; will it always be a bootstrap
stage for Perl 6,or is it a tool for now and will it be discarded
later on.
Anyway, if NQP is to stay, the following features would come in handy,
IMHO. I u
19 matches
Mail list logo
