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
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 every .pm
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
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 :-)
Next
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, last,
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 when
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 registers, I'm not
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 the
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
#
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 actual
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 package
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
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 sense that
(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,
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.)
Ok,
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.
#
#
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 http://citeseer.nj.nec.com/romer96structure.html,
but you guys have already read that, eh? ;)
One thing I was
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 register
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 and dynamic
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
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 single
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 to
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
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 optimizer
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,
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
one
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 uses
private
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
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
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'd have
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 lexicals.)
# -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
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 to be
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?!
Even
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) its
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 lexical scoping
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 called as:
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 single
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 only one.
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 the first way
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
a good
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
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\n;
#
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
higher level)
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
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
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 throws
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.
as dan has
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 memory use
--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,
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 put the op
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 was
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 that use
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 optimizer's
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
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 really
isn't a way to know
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 actually
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 guarantee
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
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 true. ML can do
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 the
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
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
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
Ctry and Ccatch
(Cfinally is not nearly so certain.)
Conditional Statement Modifiers
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();
}
Oh,
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 just as
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 modules
67 matches
Mail list logo
