On Tuesday 04 September 2001 10:10 pm, Dan Sugalski wrote:
> At 08:59 PM 9/4/2001 -0400, Bryan C. Warnock wrote:
> >Yes, this is akin to redeclaring every lexical variable every time you
> >introduce a new scope. Not pretty, I know. But if you want run-time
> >semantics with compile-time resolu
=head1 TITLE
API for the Perl 6 debugger.
=head1 VERSION
1.1
=head2 CURRENT
Maintainer: David Storrs ([EMAIL PROTECTED])
Class: Internals
PDD Number: ?
Version: 1
Status: Developing
Last Modified: August 18, 2001
PDD Format: 1
Language: English
=head2
--- Dan Sugalski <[EMAIL PROTECTED]> wrote:
> At 03:48 PM 9/4/2001 -0400, Uri Guttman wrote:
> > > "DS" == Dan Sugalski <[EMAIL PROTECTED]> writes:
> >
> >
> > DS> Ah. I've always wanted to do that with tied
> hashes. Okay, even
> > DS> more reason to pass the data in! (We're going to
> en
At 03:48 PM 9/4/2001 -0400, Uri Guttman wrote:
> > "DS" == Dan Sugalski <[EMAIL PROTECTED]> writes:
>
>
> DS> Ah. I've always wanted to do that with tied hashes. Okay, even
> DS> more reason to pass the data in! (We're going to end up with a
> DS> WANT register by the time we're done...)
> "DS" == Dan Sugalski <[EMAIL PROTECTED]> writes:
DS> Ah. I've always wanted to do that with tied hashes. Okay, even
DS> more reason to pass the data in! (We're going to end up with a
DS> WANT register by the time we're done...)
that is not a bad idea. we could allocate a PMC registe
> "DS" == Dan Sugalski <[EMAIL PROTECTED]> writes:
DS> I don't buy that there's a higher bar on comprehension,
DS> either. Register machines in general aren't anything at all
DS> new. Granted, lots of folks grew up with the abomination that is
DS> x86 assembly, if they even bothered h
From: Dan Sugalski [mailto:[EMAIL PROTECTED]]
>
> The real question, as I see it, is "Should we look
> lexicals up by name?" And the answer is Yes. Larry's
> decreed it, and it makes sense. (I'm half-tempted to
> hack up something to let it be done in perl 5
> --wouldn't take much work)
No need,
From: Graham Barr [mailto:[EMAIL PROTECTED]]
> On Tue, Sep 04, 2001 at 03:03:04PM -0400, Dan Sugalski wrote:
> > At 01:58 PM 9/4/2001 -0500, Garrett Goebel wrote:
> > >From: Dan Sugalski [mailto:[EMAIL PROTECTED]]
> > > > At 10:32 AM 9/4/2001 +0100, Piers Cawley wrote:
> > > > Can you see any use
At 08:05 PM 9/4/2001 +0100, Graham Barr wrote:
>On Tue, Sep 04, 2001 at 03:03:04PM -0400, Dan Sugalski wrote:
> > At 01:58 PM 9/4/2001 -0500, Garrett Goebel wrote:
> > >From: Dan Sugalski [mailto:[EMAIL PROTECTED]]
> > > > At 10:32 AM 9/4/2001 +0100, Piers Cawley wrote:
> > > > Can you see any use
On Tue, Sep 04, 2001 at 03:03:04PM -0400, Dan Sugalski wrote:
> At 01:58 PM 9/4/2001 -0500, Garrett Goebel wrote:
> >From: Dan Sugalski [mailto:[EMAIL PROTECTED]]
> > > At 10:32 AM 9/4/2001 +0100, Piers Cawley wrote:
> > > Can you see any use of a sub knowing it was called via a method call?
> >
>
At 03:04 PM 9/4/2001 -0400, Uri Guttman wrote:
>for sure. one case i saw recently in c.l.p.m was someone who wanted to
>chain method calls together like this:
>
> $obj->meth1()->meth2() ;
>
>this is easy assuming you return the object in each method call. but he
>ALSO wanted:
>
> $
> "DS" == Dan Sugalski <[EMAIL PROTECTED]> writes:
DS> At 10:32 AM 9/4/2001 +0100, Piers Cawley wrote:
>> Will the subroutine know how it was called? (ie: Through method
>> dispatch or through straightforward symbol table lookup. I'm really
>> hoping the answer to this is 'yes'.) Or
At 01:58 PM 9/4/2001 -0500, Garrett Goebel wrote:
>From: Dan Sugalski [mailto:[EMAIL PROTECTED]]
> > At 10:32 AM 9/4/2001 +0100, Piers Cawley wrote:
> > > > * Methods get their parameters passed in as a list in
> > > > * PMC register 0, unless we can unambiguously figure
> > > > * out their protot
At 12:38 PM 9/4/2001 +0200, Paolo Molaro wrote:
>I'm not convinced the register machine is the way to go.
Well, neither am I, and I came up with the plan.
Regardless, it's the way we're going to go for now. If it turns out to be a
performance dog then we'll go with a stack-based system. Initial
From: Dan Sugalski [mailto:[EMAIL PROTECTED]]
> At 10:32 AM 9/4/2001 +0100, Piers Cawley wrote:
> > > * Methods get their parameters passed in as a list in
> > > * PMC register 0, unless we can unambiguously figure
> > > * out their prototype at compilation time
> >
> >Will the subroutine know how
At 10:53 AM 9/4/2001 +0300, Ariel Scolnicov wrote:
>What happens when I call a prototyped sub with a code ref?
We call the "I've been called with a single list" entry point. One that,
until recently, I hadn't planned on. :)
That, I expect, will extract the elements from the list into registers,
At 10:32 AM 9/4/2001 +0100, Piers Cawley wrote:
> > * Methods get their parameters passed in as a list in PMC register 0,
> > * unless we can unambiguously figure out their prototype at
> > * compilation time
>
>Will the subroutine know how it was called? (ie: Through method
>dispatch or through s
At 09:06 AM 9/4/2001 +0100, Simon Cozens wrote:
>On Mon, Sep 03, 2001 at 09:53:11PM -0400, Dan Sugalski wrote:
> > Might as well just promote the things to PMCs and pass in a list of them.
>
>I anticipate that, especially for Perl, in a lot of cases we'll be dealing
>with PMCs more often than the
At 01:44 PM 9/4/2001 +0100, Dave Mitchell wrote:
>Dan Sugalski <[EMAIL PROTECTED]> wrote:
> > This also makes scope entry and exit costlier, since you need to make a
> > savestack entry and restore, respectively, for each lexical. I don't think
> > it'd be a win, even if closures weren't getting i
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> This also makes scope entry and exit costlier, since you need to make a
> savestack entry and restore, respectively, for each lexical. I don't think
> it'd be a win, even if closures weren't getting in your way.
although to be fair, the current run-time
On 09/02/01 Simon Cozens wrote:
> =head1 The Software CPU
>
> Like all interpreter systems of its kind, the Parrot interpreter is
> a virtual machine; this is another way of saying that it is a software
> CPU. However, unlike other VMs, the Parrot interpreter is designed to
> more closely mirror
Simon Cozens:
# On Mon, Sep 03, 2001 at 04:05:26PM -0700, Brent Dax wrote:
# > In other words, when you have sub foo {} in your code, it will be
# > assigned an opcode number in the 'private' section. The
# global section
# > is for things that are built-in to Parrot, while the
# private section
Dan Sugalski <[EMAIL PROTECTED]> writes:
> At 08:19 PM 9/3/2001 -0400, Sam Tregar wrote:
> >Speaking of soubroutines, what is Parrot's calling conventions? Obviously
> >we're no long in PUSH/POP land...
>
> Up until now, I didn't know, so consider yourself the first to find out. :)
>
> * Intege
On Mon, Sep 03, 2001 at 09:53:11PM -0400, Dan Sugalski wrote:
> Might as well just promote the things to PMCs and pass in a list of them.
I anticipate that, especially for Perl, in a lot of cases we'll be dealing
with PMCs more often than the "scalar" data types.
Simon
On Mon, Sep 03, 2001 at 08:19:32PM -0400, Sam Tregar wrote:
> I'm still not sure I understand why Parrot is doing string ops at all. Do
> all our target languages have identical semantics for string operations?
Nope. But that's OK, because they won't have identical vtables.
(The string vtable f
On Mon, Sep 03, 2001 at 04:05:26PM -0700, Brent Dax wrote:
> In other words, when you have sub foo {} in your code, it will be
> assigned an opcode number in the 'private' section. The global section
> is for things that are built-in to Parrot, while the private section is
> for stuff you write.
On Mon, Sep 03, 2001 at 06:33:19PM -0400, Ken Fox wrote:
> Thanks for the info. If you guys maintain this level of documentation
> as the code develops, Perl 6 will be easy for first-timers to work on.
That's exactly the idea. :)
> > To be more specific about the software CPU, it will contain a
Dan Sugalski <[EMAIL PROTECTED]> writes:
[... stuff I probably don't understand but at least I don't know WHY ...]
> * Integer, String, and Number registers 0-x are used to pass
> * parameters when the compiler calls routines.
>
>
> * PMC registers 0-x are used to pass parameters *if* the sub
28 matches
Mail list logo
