RE: Should MY:: be a real symbol table?

At 09:12 PM 9/3/2001 -0700, Brent Dax wrote: >From: Dan Sugalski [mailto:[EMAIL PROTECTED]] ># At 07:05 PM 9/3/2001 -0700, Brent Dax wrote: ># ># From: Dan Sugalski [mailto:[EMAIL PROTECTED]] ># ># At 05:30 PM 9/3/2001 -0700, Brent Dax wrote: ># ># >As far as expensiveness, I think this can be jus

RE: Should MY:: be a real symbol table?

On Mon, 3 Sep 2001, Brent Dax wrote: > Now is where the temp() stuff I was talking about earlier comes in. > > sub foo { > my($bar); > foo(); > } > > is basically equivalent to > > sub foo { > temp($MY::bar); > foo(); >

Re: An overview of the Parrot interpreter

> "ST" == Sam Tregar <[EMAIL PROTECTED]> writes: >> * Integer, String, and Number registers 0-x are used to pass parameters >> when the compiler calls routines. ST> s/compiler/interpreter/, right? nope. he means when the compiler generates op codes. the compiler will generate code to

RE: Should MY:: be a real symbol table?

--Brent Dax [EMAIL PROTECTED] "...and if the answers are inadequate, the pumpqueen will be overthrown in a bloody coup by programmers flinging dead Java programs over the walls with a trebuchet." # -Original Message- # From: Dan Sugalski [mailto:[EMAIL PROTECTED]] # Sent: Monday, Septe

Re: An overview of the Parrot interpreter

> "BD" == Brent Dax <[EMAIL PROTECTED]> writes: BD> # s/rather than/as well as/; # we've got a stack of register BD> # frames, right? BD> IIRC, that's mostly for when we run out of registers or we're changing BD> scopes or whatever. For the most part, it's a register architecture.

Re: Should MY:: be a real symbol table?

At 11:35 PM 9/3/2001 -0400, Ken Fox wrote: >Dan Sugalski wrote: > > Good. It should. It's a scary feature, and hopefully that same fear will > > strike anyone else who uses it > >But all it takes is one fool^Wbrave person to mess up somebody >else's perfectly working code. Basically I think this t

Re: Should MY:: be a real symbol table?

Dan Sugalski wrote: > Good. It should. It's a scary feature, and hopefully that same fear will > strike anyone else who uses it But all it takes is one fool^Wbrave person to mess up somebody else's perfectly working code. Basically I think this throws us back to the bad old days when we only had

Re: Should MY:: be a real symbol table?

Dan Sugalski writes: > Needless to say, this makes the optimizer's job... interesting. On the > other hand, it does allow for some really powerful things to be done by > code at runtime. The big thing I want it for is so I can write nats_settings.pm: # nats_settings.pm - turn on strict and w

Re: Should MY:: be a real symbol table?

At 10:50 PM 9/3/2001 -0400, Ken Fox wrote: >Dan Sugalski wrote: > > Oh, it gets better. Imagine injecting a lexically scoped sub into the > > caller's lexical scope. Overriding one that's already there. (Either > > because it was global, or because it was lexically defined at the same or > > highe

Re: Should MY:: be a real symbol table?

Dan Sugalski wrote: > Oh, it gets better. Imagine injecting a lexically scoped sub into the > caller's lexical scope. Overriding one that's already there. (Either > because it was global, or because it was lexically defined at the same or > higher level) > > Needless to say, this makes the optimi

Re: Deoptimizations

At 01:57 PM 9/2/2001 -0400, Ken Fox wrote: >"Bryan C. Warnock" wrote: > > I think the only way your going to be able to detect dynamic redefinitions > > is dynamically. :-) > >Not really. Does the program include string eval? That throws out >optimizations like folding and dead code elimination t

Re: Should MY:: be a real symbol table?

At 09:57 PM 9/3/2001 -0400, Bryan C. Warnock wrote: >On Monday 03 September 2001 09:57 pm, Dan Sugalski wrote: > > Oh, it gets better. Imagine injecting a lexically scoped sub into the > > caller's lexical scope. Overriding one that's already there. (Either > > because it was global, or because it

RE: Should MY:: be a real symbol table?

At 07:05 PM 9/3/2001 -0700, Brent Dax wrote: ># From: Dan Sugalski [mailto:[EMAIL PROTECTED]] ># At 05:30 PM 9/3/2001 -0700, Brent Dax wrote: ># >As far as expensiveness, I think this can be just as fast as ># our current ># >offset-into-the-pad method. ># ># I was speaking in both speed and memor

Re: Should MY:: be a real symbol table?

On Monday 03 September 2001 09:57 pm, Dan Sugalski wrote: > Oh, it gets better. Imagine injecting a lexically scoped sub into the > caller's lexical scope. Overriding one that's already there. (Either > because it was global, or because it was lexically defined at the same or > higher level) > > N

Re: Should MY:: be a real symbol table?

At 09:42 PM 9/3/2001 -0400, Ken Fox wrote: >Dan Sugalski wrote: > > First, of course, runtime and compiletime are mixed on perl. String eval > > has to go walk back up the pads *at runtime* and resolve the variable > names. > >Sure, if you use eval, the symbol table for the current scope >needs t

RE: Should MY:: be a real symbol table?

# -Original Message- # From: Dan Sugalski [mailto:[EMAIL PROTECTED]] # Sent: Monday, September 03, 2001 5:50 PM # To: Brent Dax; Ken Fox # Cc: Simon Cozens; [EMAIL PROTECTED] # Subject: RE: Should MY:: be a real symbol table? # # # At 05:30 PM 9/3/2001 -0700, Brent Dax wrote: # >As far as

Re: Should MY:: be a real symbol table?

At 09:58 PM 9/3/2001 -0400, Ken Fox wrote: >"Bryan C. Warnock" wrote: > > Except that Perl 6 will have the ability to inject lexical variables in its > > scope, and in any dynamic parent's scope. (It isn't clear whether that is > > write-only access or not - which it probably should be for lexica

Re: An overview of the Parrot interpreter

At 09:41 PM 9/3/2001 -0400, Sam Tregar wrote: >On Mon, 3 Sep 2001, Dan Sugalski wrote: > > > I'm not entirely sure how much this'll be used, but I really, *really* want > > to be able to call any sub that qualifies as an op rather than as a sub. > >What would a sub have to do (be?) to qualify? It

Re: Should MY:: be a real symbol table?

"Bryan C. Warnock" wrote: > Except that Perl 6 will have the ability to inject lexical variables in its > scope, and in any dynamic parent's scope. (It isn't clear whether that is > write-only access or not - which it probably should be for lexicals.) > > That, invariably, forces at least some r

Re: An overview of the Parrot interpreter

On Mon, 3 Sep 2001, Dan Sugalski wrote: > I'm not entirely sure how much this'll be used, but I really, *really* want > to be able to call any sub that qualifies as an op rather than as a sub. What would a sub have to do (be?) to qualify? > >I don't understand this restriction. Won't it make i

Re: An overview of the Parrot interpreter

At 09:26 PM 9/3/2001 -0400, Sam Tregar wrote: >On Mon, 3 Sep 2001, Dan Sugalski wrote: > > > >avoid using a "call" opcode all over the place, right? > > > > No, more a "try and leave the bytecode sections read-only" hack. > > > > Imagine, if you will, building LWP and bytecode compiling it. It use

Re: Should MY:: be a real symbol table?

Dan Sugalski wrote: > First, of course, runtime and compiletime are mixed on perl. String eval > has to go walk back up the pads *at runtime* and resolve the variable names. Sure, if you use eval, the symbol table for the current scope needs to be available. There's no reason to have more than on

Re: An overview of the Parrot interpreter

On Mon, 3 Sep 2001, Dan Sugalski wrote: > >avoid using a "call" opcode all over the place, right? > > No, more a "try and leave the bytecode sections read-only" hack. > > Imagine, if you will, building LWP and bytecode compiling it. It uses > private opcodes 1024-1160. Then you later build, say,

Re: An overview of the Parrot interpreter

At 08:19 PM 9/3/2001 -0400, Sam Tregar wrote: >On Mon, 3 Sep 2001, Dan Sugalski wrote: > > > Basically chunks of perl code can define opcodes on the fly--they might be > > perl subs that meet the proper critera, or opcode functions defined by C > > code with magic stuck in the parser, or wacky opt

RE: Should MY:: be a real symbol table?

At 05:30 PM 9/3/2001 -0700, Brent Dax wrote: >As far as expensiveness, I think this can be just as fast as our current >offset-into-the-pad method. I was speaking in both speed and memory use when I was talking about expense. We'd need to maintain a hash structure for each pad, plus we'd need t

Re: An overview of the Parrot interpreter

On Mon, 3 Sep 2001, Dan Sugalski wrote: > Basically chunks of perl code can define opcodes on the fly--they might be > perl subs that meet the proper critera, or opcode functions defined by C > code with magic stuck in the parser, or wacky optimizer extensions or > whatever. There won't be a sing

RE: Should MY:: be a real symbol table?

# -Original Message- # From: Dan Sugalski [mailto:[EMAIL PROTECTED]] # Sent: Monday, September 03, 2001 4:31 PM # To: Ken Fox; Brent Dax # Cc: Simon Cozens; [EMAIL PROTECTED] # Subject: Re: Should MY:: be a real symbol table? # # >Lexicals are fundamentally different from Perl's package ..

Re: An overview of the Parrot interpreter

On Monday 03 September 2001 08:06 pm, Sam Tregar wrote: > I think I understand this. What I don't understand is how this relates to > the next section about Parrot's special relationship with strings. If > Parrot has a "string" type and string handling functions, why use a PMC > to implement a s

Re: Should MY:: be a real symbol table?

At 08:09 PM 9/3/2001 -0400, Ken Fox wrote: >Dan Sugalski wrote: > > At 05:44 PM 9/3/2001 -0400, Ken Fox wrote: > > > Lexicals are fundamentally different from Perl's package (dynamically > > > scoped) variables. > > > > No, actually, they're not. > >How can you possibly think that lexical scoping

Re: Should MY:: be a real symbol table?

On Monday 03 September 2001 08:09 pm, Ken Fox wrote: > Dan Sugalski wrote: > > At 05:44 PM 9/3/2001 -0400, Ken Fox wrote: > > > Lexicals are fundamentally different from Perl's package (dynamically > > > scoped) variables. > > > > No, actually, they're not. > > How can you possibly think that lexi

Re: An overview of the Parrot interpreter

On Mon, 3 Sep 2001, Nathan Torkington wrote: > > Ok, so one example of a PMC is a Perl string... > > If you grok vtables, think of a PMC as the thing a vtable hangs off. > > Another way to think of it is that a PMC is an object. To the outside > (the interpreter that is manipulating data values)

Re: Should MY:: be a real symbol table?

Dan Sugalski wrote: > At 05:44 PM 9/3/2001 -0400, Ken Fox wrote: > > Lexicals are fundamentally different from Perl's package (dynamically > > scoped) variables. > > No, actually, they're not. How can you possibly think that lexical scoping and dynamic scoping are not fundamentally different?!

Where's da code?

Simon and Dan have been teasing you, I know. I'm holding them back from releasing what they have until: 1) We have a CVS server running. (Ask has done this and is now working on anonymous access). 2) We have a bugtracking system. (We're currently thinking of Bugzilla). 3) We have a bui

Re: An overview of the Parrot interpreter

Sam Tregar writes: > > If our PMC is a string and has a vtable which implements Perl-like > > string operations, this will return the length of the string. If, on the > > other hand, the PMC is an array, we might get back the number of > > elements in the array. (If that's what we want it to do.)

Internals Plan

(From this week's summary, plus some additional info) --- The next phase of Parrot will be a code review - for the Perl internals community to poke and prod and make sense of what Dan and Simon have done. The community will provide feedback, and Dan and Simon will disappear for a brief period, bef

Re: An overview of the Parrot interpreter

At 06:37 PM 9/3/2001 -0400, Sam Tregar wrote: >On Sun, 2 Sep 2001, Simon Cozens wrote: > > > For instance, the Parrot VM will have a register architecture, rather > > than a stack architecture. > >s/rather than/as well as/; # we've got a stack of register frames, right? Well, register in the sen

Re: Should MY:: be a real symbol table?

At 05:44 PM 9/3/2001 -0400, Ken Fox wrote: >Brent Dax wrote: > > What I'm suggesting is that, instead of the padlist's AV containing > > arrays, it should contain stashes, otherwise indistinguishable from > > the ones used for global variables. > >Lexicals are fundamentally different from Perl's p

Re: Should MY:: be a real symbol table?

Brent Dax wrote: > Ken Fox: > # Lexicals are fundamentally different from Perl's package (dynamically > # scoped) variables. > > *How* are they "fundamentally different"? Perl's "local" variables are dynamically scoped. This means that they are *globally visible* -- you never know where the actu

RE: An overview of the Parrot interpreter

Note: this is my understanding of the situation; I could be wrong. Sam Tregar: # On Sun, 2 Sep 2001, Simon Cozens wrote: # # > For instance, the Parrot VM will have a register # architecture, rather # > than a stack architecture. # # s/rather than/as well as/; # we've got a stack of register # f

Re: An overview of the Parrot interpreter

On Sun, 2 Sep 2001, Simon Cozens wrote: > For instance, the Parrot VM will have a register architecture, rather > than a stack architecture. s/rather than/as well as/; # we've got a stack of register frames, right? > There will be global and private opcode tables; that is to say, an area > of

Re: An overview of the Parrot interpreter

> "KF" == Ken Fox <[EMAIL PROTECTED]> writes: KF> Simon Cozens wrote: >> To be more specific about the software CPU, it will contain a large >> number of registers. KF> The register frames store values, not pointers to values? If KF> there's another level of indirection with regist

Re: An overview of the Parrot interpreter

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. One goal down, N-1 to go... ;) Simon Cozens wrote: > To be more specific about the software CPU, it will contain a large > number of registers. The registe

Re: An overview of the Parrot interpreter

Dan Sugalski wrote: > For those of you worrying that parrot will be *just* low-level ops, > don't. There will be medium and high level ops in the set as well. I was going to cite , but you guys have already read that, eh? ;) One thing I was expec

RE: Should MY:: be a real symbol table?

Note: some parts of this may seem a bit like a flame. This is unintentional. Ken Fox: # Brent Dax wrote: # > What I'm suggesting is that, instead of the padlist's AV containing # > arrays, it should contain stashes, otherwise indistinguishable from # > the ones used for global variables. # # Lex

Re: Should MY:: be a real symbol table?

Brent Dax wrote: > What I'm suggesting is that, instead of the padlist's AV containing > arrays, it should contain stashes, otherwise indistinguishable from > the ones used for global variables. Lexicals are fundamentally different from Perl's package (dynamically scoped) variables. Even if you c

Re: An overview of the Parrot interpreter

Simon Cozens <[EMAIL PROTECTED]> wrote: > Firstly, a magic number is presented to identify the bytecode file as > Parrot code. Hopefully this is followed by a header that has a version number and lots of useful stuff like flags and offsets and things, just like wot real object files have :-) > N

Re: An overview of the Parrot interpreter

On Sun, 2 Sep 2001, Simon Cozens wrote: > For instance, the Parrot VM will have a register architecture, rather > than a stack architecture. It will also have extremely low-level > operations, more similar to Java's than the medium-level ops of Perl and > Python and the like. For those of you wo

An overview of the Parrot interpreter

Here's the first of a bunch of things I'm writing which should give you practical information to get you up to speed on what we're going to be doing with Parrot so we can get you coding away. :) Think of them as having a Apocalypse->Exegesis relationship to the PDDs. I haven't yet finished writi