Re: What's up with %MY?

Damian Conway wrote: > It would seem *very* odd to allow every symbol table *except* > %MY:: to be accessed at run-time. Well, yeah, that's true. How about we make it really simple and don't allow any modifications at run-time to any symbol table? Somehow I get the feeling that "*very* odd" can'

Re: What's up with %MY?

Dan revealed: > > How am I expected to produce fresh wonders if you won't let me > > warp the (new) laws of the Perl universe to my needs? > That's easy--you slip the pumpking or internals designer a 10-spot. > Amazing what it'll do... :) And how do you think I got five of my module

Re: What's up with %MY?

At 04:11 PM 9/4/2001 +1100, Damian Conway wrote: >I would envisage that mucking about with symbol tables would be no more >common in Perl 6 than it is in Perl 5. But I certainly wouldn't want to >restrict the ability to do so. > >How am I expected to produce fresh wonders if you won't let me warp

Re: What's up with %MY?

> I haven't seen details in an Apocalypse, but Damian's > Perl 6 overview has a bit about it. The Apocalypse > specifically mentions *compile-time* scope management, > but Damian is, uh, Damian. (DWIMery obviously. ;) Hmm. It would seem *very* odd to allow every symbol table *ex

Re: Prototypes

> > Are prototypes going to be checked at runtime now? > > For methods, at least. Dunno about subs, that's Larry's call. I > could make a good language case for and against it. It adds > overhead on sub calls, which is a bad thing generally. I would strongly like to see a guarante

Re: Prototypes

> But since the current prototyping system... has a highly positive > pressure gradient compared to the surrounding air, Well...I think it's more a problem of "I do no' thin' dat word means wha' you thin' it means". People want prototypes to be parameter type specifiers, when they're actua

Re: Prototypes

At 11:47 PM 9/3/2001 -0400, Ken Fox wrote: >"Bryan C. Warnock" wrote: > > { > > my $a = sub ($$) { code }; > > gork($a); > > } > > > > sub gork { > > my ($a) = shift; > > $a->(@some_list); # <- Here > > } > > > > The reason prototypes aren't checked at "Here" is because there real

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: LangSpec: Statements and Blocks [first,last]

iVAN wrote: > As we read in Damian Conway- Perl6-notes, there will be "...may be..." (Remember, I'm only the shambling henchman ;-) > a var-iterator that can be used to see how many times the cycle has > been "traversed" i.e. > > foreach my $el (@ary) { >.. do something

Re: LangSpec: Statements and Blocks

Some feedback. > Syntax Overview > > Keywords > continue, do, else, elsif, for, foreach, given, goto, grep, if, last, > map, next, redo, sort, sub, unless, until, when, while C and C (C is not nearly so certain.) > Conditional Statement Modifiers > > 6. [ L

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

What's up with %MY?

I haven't seen details in an Apocalypse, but Damian's Perl 6 overview has a bit about it. The Apocalypse specifically mentions *compile-time* scope management, but Damian is, uh, Damian. (DWIMery obviously. ;) Is stuff like: %MY::{'$lexical_var'} = \$other_var; supposed to be a compile-time o

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: Prototypes

A few more ideas to put down, lest I lay wake all night, thoughts churning... One. Presumably, there will be an op for the actual calling of the subroutine. That op can take an (extra) argument, with one of three values, that the prototype checking can get to. The first value indicates that th

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: Prototypes

"Bryan C. Warnock" wrote: > { > my $a = sub ($$) { code }; > gork($a); > } > > sub gork { > my ($a) = shift; > $a->(@some_list); # <- Here > } > > The reason prototypes aren't checked at "Here" is because there really > isn't a way to know what the prototype was. Um, that's not

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: Prototypes

On Monday 03 September 2001 10:46 pm, Dan Sugalski wrote: > At 10:32 PM 9/3/2001 -0400, Bryan C. Warnock wrote: > >On Monday 03 September 2001 10:27 pm, Dan Sugalski wrote: > > > >To me, that seems only a language decision. This could certainly > > > > handle that. > > > > > > Ah, but calling in

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: Prototypes

At 10:32 PM 9/3/2001 -0400, Bryan C. Warnock wrote: >On Monday 03 September 2001 10:27 pm, Dan Sugalski wrote: > > >To me, that seems only a language decision. This could certainly handle > > >that. > > > > Ah, but calling in the first way has two PMCs in as parameters, while the > > second has o

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: Prototypes

On Monday 03 September 2001 10:27 pm, Dan Sugalski wrote: > >To me, that seems only a language decision. This could certainly handle > >that. > > Ah, but calling in the first way has two PMCs in as parameters, while the > second has only one. Potentially at least. A world of difference there. A

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: Prototypes

At 10:17 PM 9/3/2001 -0400, Bryan C. Warnock wrote: >On Monday 03 September 2001 09:30 pm, Dan Sugalski wrote: > > A clever idea, and one I'd not though of. That's probably the best way to > > do it. Has some other issues, like do we allow prototypes like: > > > >sub foo ($$) {}; > > > > to be

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: Prototypes

On Monday 03 September 2001 09:30 pm, Dan Sugalski wrote: > A clever idea, and one I'd not though of. That's probably the best way to > do it. Has some other issues, like do we allow prototypes like: > >sub foo ($$) {}; > > to be called as: > >foo(@bar) > > if @bar has two elements in it?

Re: My, our, thems-over-theres.....

A while ago, I posted some inconsistencies with scope declarators. (http:[EMAIL PROTECTED]/msg08028.html) A few more related notions $a = "test"; { chop(my $a = our $a = "hello"); # The lexical is chopped print "1-$a\n"; # But the global is printed } print "2-$a\

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: Multiple-dispatch on functions

At 07:46 AM 9/2/2001 +0100, Piers Cawley wrote: >Dan Sugalski <[EMAIL PROTECTED]> writes: > > Nope, the cost will be paid on all sub calls. We at least need to > > check on every sub call to see if there are multiple versions of the > > functions. (We can't tell at compile time if it's a single or

Re: Prototypes

At 10:11 PM 9/2/2001 -0400, Bryan C. Warnock wrote: >On Sunday 02 September 2001 07:49 pm, Dan Sugalski wrote: > > On Sun, 2 Sep 2001, Bryan C. Warnock wrote: > > > Are prototypes going to be checked at runtime now? > > > > For methods, at least. Dunno about subs, that's Larry's call. I could make

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: LangSpec: Statements and Blocks

On Monday 03 September 2001 01:06 pm, Davíð Helgason wrote: > We will be adding 'try' & 'catch'. 'finally' also? (or 'finalize' :-) I've not heard anything definite on this. > > >16. [ LABEL: ] when expr : { block } # Note 5 > > > >[Note 5. 'when' is only a valid construct whe

Re: LangSpec: Statements and Blocks

A few, hopefully relevant thoughts (some of them). Bryan C. Warnock wrote: >-- > >Perl 6 Reference - Statements and Blocks >(0.1/2001-09-01) A beauty to behold, this! >Syntax Overview > >Keywords >continue, do, else, elsif, for, foreach, given, goto, grep, if, las

Re: Source/Program metadata from within a program

On Mon, Sep 03, 2001 at 04:56:28PM +0100, Nick Ing-Simmons wrote: > >The problem is, it appears DATA is only opened if there's an __END__ > >or __DATA__ tag. I don't remember it working this way... > > > >*shrug* We can fix that easy. :) > > No you can't - you run out of fd's pretty quick if ev

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