Re: What's MY.line?
On Tue, Jul 09, 2002 at 09:50:26PM -0400, Chip Salzenberg wrote:
Based on what I rememeber from the long threads about this,
>3. Is C<%MY> intended to reflect the PAD?
loosely speaking yes.
>
> 3a. If so, how can one distinguish among the e.g. many C
> variables declared within the current function?
It was decreed that %MY only sees stuff in the inner-most lexical scope
(so the Perl6 version of a pad is 'bigger' than what %MY sees):
{
my $x = 1;
{
exists %MY::{'$x'}; # false
print %MY::{'$x'}; # undef
print $x; # 1
%MY{'$x'} = 2;
print %MY::{'$x'}; # 2
print $x; # 2
{
exists %MY::{'$x'}; # false
print %MY::{'$x'}; # undef
print $x; # 2
}
}
exists %MY::{'$x'}; # true
print %MY::{'$x'}; # 1
print $x; # 1
}
>
> 3b. If not, how are lexical adjustments to C<%MY> unwound? Or are
> they? If they're not, I can actually see the idea that could be
> part of the base utility of C<%MY>.
I think the main intent of %MY:: is to allow import() to lexically affect
the caller, ie
sub import {
caller(1).MY{'&foo'} = sub { ... };
}
(for some vague handwaving interpretation of caller() and MY)
Dave.
--
My get-up-and-go just got up and went.
Re: Mutable vs immutable strings
"Clark C . Evans" wrote: > So, I propose that Parrot supports both of these attitudes > of reasoning by using a flag. Initially, all strings > are 'mutable'. I concur with Clark. What he's proposing is (it seems to me) nothing more than a "read-only" flag, and that's as immutable as a variable needs to get. However, I'm concerned about the performance impact of such a thing. Perhaps a better approach would be to swap out the mutator methods with code that throws. -- John Douglas Porter __ Do You Yahoo!? Sign up for SBC Yahoo! Dial - First Month Free http://sbc.yahoo.com
distro pdd hosage
umm... has anyone else noticed that pdd02 in the distribution (0.4) is spouged, and that pdd03 is completely missing? -- John Douglas Porter __ Do You Yahoo!? Sign up for SBC Yahoo! Dial - First Month Free http://sbc.yahoo.com
Re: Mutable vs immutable strings
I'm following this list only for a very short time now, and I don't have very much programming experience, so tell me if all this is pure nonsense. But isn't this partly addressed with COW? The way I understood Copy On Write, it means that if you "copy" a string, only some pointers are copied and some flags are set, until you modify one of the two strings. So IMHO, this shouldn't be too much slower than simply copying the pointer of an immutable string. And if you wanted to change a mutable string buffer (which has been passed to your code by reference, for example), you might want to make a copy anyway, which is exactly what happens when you modify a "copied" string in Parrot. Thus I don't see a very big performance win in introducing mutable strings. Am 10.07.2002 14:00:16 schrieb John Porter <[EMAIL PROTECTED]>: > >"Clark C . Evans" wrote: >> So, I propose that Parrot supports both of these attitudes >> of reasoning by using a flag. Initially, all strings >> are 'mutable'. > >I concur with Clark. What he's proposing is (it seems to me) >nothing more than a "read-only" flag, and that's as >immutable as a variable needs to get. > >However, I'm concerned about the performance impact of such a thing. >Perhaps a better approach would be to swap out the mutator methods >with code that throws. > >-- >John Douglas Porter > > >__ >Do You Yahoo!? >Sign up for SBC Yahoo! Dial - First Month Free >http://sbc.yahoo.com > >
Re: Mutable vs immutable strings
Florian Haeglsperger wrote: > But isn't this partly addressed with COW? > . . . > Thus I don't see a very big performance win in introducing mutable > strings. Good point. But some people maintain that there could be a need for truly "constant" strings, that should never be modified, and any attempt to do so, even under COW, should fail. -- John Douglas Porter __ Do You Yahoo!? Sign up for SBC Yahoo! Dial - First Month Free http://sbc.yahoo.com
RE: Tasks for the interested
At 2:30 PM -0700 7/9/02, John Porter wrote: >Garrett Goebel wrote: >> John Porter wrote: >> > Not to beat on Dan (or anyone else), but for the sake of those >> [...] >> >> Please don't beat on Dan... ;) > >I'm not! Nope, he isn't. Warnings and concerns based on technical merits and past experience are *always* in order. (Though I'd prefer people hold off on slamming a design that's been decided to be final, unless they're working on the implementation--in which case slams based on the realities of the situation are definitely warranted) > > Parrot isn't Perl. I.e., your Perl-vision blinders are on a tad > > tight. It's the first general purpose vm for dynamic languages. >> That would make it a first system not second. > >That actually doesn't matter much. The two systems are very >similar in many fundamental respects; and the one thing that >all the designers have in common is perl5. Remember what >Larry said: "perl 6 is the community's rewrite". >That makes perl 6 a "second system" in many respects. Too many respects. Adding "just one more feature" is amazingly seductive. This is worse in some ways, since it's got features of both a first and a second system. > > And with a goal like he'll always have at least one voice >> screaming bloat into the one ear, while someone else'll be >> asking for support for yet another obscure language feature >> in the other. > >I'm just saying that (IMHO) trying to reproduce the behavior >of even two different virtual machines in parrot would be way >beyond parrot's purpose. Absolutely. Which is why we're not going to do that. These 'add-on' bytecode interpreters don't get any special consideration in the core. That means they *can* have: *) A custom bytecode loader to translate their bytecode format to ours, or something we can use *) As many custom PMC classes as they want *) Dynamically loaded custom opcode functions They *don't* get: *) Changes to fundamental core behaviour (like refcounting garbage collection) If someone writes one and has a reasonable request, it gets treated the same as any other reasonable request--if it fits the current design, or can go in without causing problems elsewhere, it will probably go in. If not, well, they're out of luck. -- Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
RE: Tasks for the interested
Dan Sugalski wrote: > These 'add-on' bytecode interpreters don't get any special > consideration in the core. That means they *can* have: > > *) A custom bytecode loader to translate their bytecode format >to ours, or something we can use > *) As many custom PMC classes as they want > *) Dynamically loaded custom opcode functions > > They *don't* get: > > *) Changes to fundamental core behaviour (like refcounting >garbage collection) I like it! Thanks, Dan. -- John Douglas Porter __ Do You Yahoo!? Sign up for SBC Yahoo! Dial - First Month Free http://sbc.yahoo.com
Re: vtables and multimethod dispatch
At 8:35 PM -0700 7/9/02, John Porter wrote: >Dan Sugalski wrote: >> John Porter wrote: >> > Why is "left side wins" insufficient? >> >> Well, perl 5 is apparently not left side wins for overloading, which >> is enough. > >Mmmm. Have a good example handy? I'll have to go dig one up. Damian hit me with the "Perl does it" at YAPC, and I generally take what he says at face value. (Often with aspirin as well, but that's a separate issue) >But even so, I'm not sure that should be a problem, since we're >talking about multimethods at the vm interpreter layer; we should >expect (shouldn't we?) that a compiler will be able to transform >expressions with overloading into bytecode that does the right >thing even in a left-side-wins scheme. Well, sort of. The interpreter, in the general case, can't know if things are overloaded without the compiler doing full dataflow analysis, and that's deep into the Hard Problem realm. What we're doing is assuming we don't know and letting the variables decide whether they'll care. Perl's will, though other languages can decide differently. > > If there's an int on the left and a float on the right, >> the math is still done floating-point. > >Yes. My first inclination is to say that this is a rather special >case, since the types are intrinsic, and there are only two of them. >That means that a complete elaboration is feasible, so there's no >issue of which side wins; you'll always get a perfect match. > >But the more general problem is (presumably) always a possibility, >so we have to address it. As in the case of int-vs-float, maybe a >kind of "paper-scissors-rock" rulebase that orders types. >(What C/C++ hard-codes as "type promotion".) Type promotion makes me more nervous than multimethod dispatch. I think I'd rather not do that unless we really have to. >If no match is found in the rulebase for the 2 (n?) types >involved, then we could fall back to left-side-wins. If we can't find a match, or if there are two equal-distance matches with no clear winner, we throw an exception. There'll be a mechanism to specify a default method. (Which, by default, will pitch an exception) >Just a thought. > >Btw, I think the "distance in type space" idea is pretty kewl... >but the thought of actually using it in parrot gives me thewillies. Heh. I never expected to have to dust off my trig skills when I started this. If I need to dig out the calculus books, I think I'll just go run screaming... -- Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Mutable vs immutable strings
At 7:34 AM -0700 7/10/02, John Porter wrote: >Florian Haeglsperger wrote: >> But isn't this partly addressed with COW? >> . . . >> Thus I don't see a very big performance win in introducing mutable >> strings. > >Good point. > >But some people maintain that there could be a need for truly >"constant" strings, that should never be modified, and any >attempt to do so, even under COW, should fail. Right. COW is a performance hack--there's a difference between "I defer getting a private copy" and "This isn't changeable". It's reasonably important to have both. I'm not sure that the place to enforce read-onlyness is at the string/buffer level. Doing it at the PMC level is more likely the right place to do it. -- Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: What's MY.line?
At 9:50 PM -0400 7/9/02, Chip Salzenberg wrote: >3. Is C<%MY> intended to reflect the PAD? Yes. > 3a. If so, how can one distinguish among the e.g. many C > variables declared within the current function? One pad per block, rather than per sub. -- Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: vtables and multimethod dispatch
Dan Sugalski wrote: > What we're > doing is assuming we don't know and letting the variables decide > whether they'll care. Perl's will, though other languages can decide > differently. Letting the variables decide? So, we take a poll of all the arguments, and ask each one which they think ought to be the receiver? That would be O(n^2) in the number of args. And what if (as for other languages) the variables don't care? Then do we do left-side-wins? > > maybe a > > kind of "paper-scissors-rock" rulebase that orders types. > > (What C/C++ hard-codes as "type promotion".) > > Type promotion makes me more nervous than multimethod dispatch. > I think I'd rather not do that unless we really have to. But I'm not talking about actually doing type promotion; it's just a scheme to decide who gets to decide. In the example of int-vs-float, the rulebase (it's really just a DAG) decides that float wins. So a float.method gets an int argument; the int isn't promoted to a float. > > If no match is found in the rulebase for the 2 (n?) types > > involved, then we could fall back to left-side-wins. > > If we can't find a match, or if there are two equal-distance matches > with no clear winner, we throw an exception. You don't like the idea of falling back to left-side-wins? > > Btw, I think the "distance in type space" idea is pretty kewl... > > but the thought of actually using it in parrot gives me thewillies. What bothers me is this: the programmer needs to be able to predict what the machine is going to do with the code she gives it. And predicting how the machine is going to resolve the multimethod call could be, in any but trivial cases, far too difficult. Programmers will end up guessing -- or, even worse, not giving it a single thought -- and then we may as well be programming in PL/1. :-) > Heh. I never expected to have to dust off my trig skills when I > started this. If I need to dig out the calculus books, I think I'll > just go run screaming... Not to worry. There's no trig involved. Just the Pythagorean theorem. -- John Douglas Porter __ Do You Yahoo!? Sign up for SBC Yahoo! Dial - First Month Free http://sbc.yahoo.com
Re: Mutable vs immutable strings
Dan Sugalski wrote: > I'm not sure that the place to enforce read-onlyness is at the > string/buffer level. Doing it at the PMC level is more likely the > right place to do it. Yes; but what about non-PMC variables? -- John Douglas Porter __ Do You Yahoo!? Sign up for SBC Yahoo! Dial - First Month Free http://sbc.yahoo.com
Re: vtables and multimethod dispatch
On Wed, Jul 10, 2002 at 10:17:47AM -0700, John Porter wrote: > > Dan Sugalski wrote: > > Heh. I never expected to have to dust off my trig skills when I > > started this. If I need to dig out the calculus books, I think I'll > > just go run screaming... > > Not to worry. There's no trig involved. Just the > Pythagorean theorem. Unless I'm being thick, x² < y² whenever x < y for positive x and y (ie you don't need to take the square root of the hypotenuse to work out which hypotenuse is shorter. And all we're actually interested in which one is shorter, aren't we?) Nicholas Clark -- Even better than the real thing:http://nms-cgi.sourceforge.net/
administriflings
Would I be out of line to request that people edit their email headers so that replies only go to the list? I'm tired of getting two (or more) copies of everything on any thread I've posted in. Thanks, John Douglas Porter __ Do You Yahoo!? Sign up for SBC Yahoo! Dial - First Month Free http://sbc.yahoo.com
Re: Mutable vs immutable strings
At 10:21 AM -0700 7/10/02, John Porter wrote: >Dan Sugalski wrote: >> I'm not sure that the place to enforce read-onlyness is at the >> string/buffer level. Doing it at the PMC level is more likely the >> right place to do it. > >Yes; but what about non-PMC variables? Generally speaking, there aren't any. Everything else (in this case the buffer/string things) is for internal use only. Languages aren't supposed to expose strings directly. -- Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: vtables and multimethod dispatch
At 10:17 AM -0700 7/10/02, John Porter wrote: >Dan Sugalski wrote: >> What we're >> doing is assuming we don't know and letting the variables decide >> whether they'll care. Perl's will, though other languages can decide >> differently. > >Letting the variables decide? >So, we take a poll of all the arguments, and ask each one >which they think ought to be the receiver? >That would be O(n^2) in the number of args. Sort of. That's what the multimethod dispatch table does, though lookup is O(n) since we precompute the dispatch table. We look for the entry in the table based on the type of the left and right side. Since we're conveniently assigning each type a number, it's just a matter of looking those numbers up and indexing into the table. >And what if (as for other languages) the variables don't care? >Then do we do left-side-wins? Yes. What we're really doing is left-side-wins always. It's just that, in the case of all the perl types, they then do a multimethod lookup for the ultimate routine to execute. > > > maybe a >> > kind of "paper-scissors-rock" rulebase that orders types. >> > (What C/C++ hard-codes as "type promotion".) >> >> Type promotion makes me more nervous than multimethod dispatch. >> I think I'd rather not do that unless we really have to. > >But I'm not talking about actually doing type promotion; it's >just a scheme to decide who gets to decide. >In the example of int-vs-float, the rulebase (it's really just >a DAG) decides that float wins. So a float.method gets an int >argument; the int isn't promoted to a float. Ah. In that case it's really a subset of multimethod dispatch, so it all sort of works out. > > > If no match is found in the rulebase for the 2 (n?) types >> > involved, then we could fall back to left-side-wins. >> >> If we can't find a match, or if there are two equal-distance matches >> with no clear winner, we throw an exception. > >You don't like the idea of falling back to left-side-wins? Oh, I like it, but at that point we've already decided to do a MM lookup, so there's really no going back. > > > Btw, I think the "distance in type space" idea is pretty kewl... >> > but the thought of actually using it in parrot gives me thewillies. > >What bothers me is this: the programmer needs to be able to predict >what the machine is going to do with the code she gives it. >And predicting how the machine is going to resolve the multimethod >call could be, in any but trivial cases, far too difficult. >Programmers will end up guessing -- or, even worse, not giving it >a single thought -- and then we may as well be programming in PL/1. >:-) Yeah, this definitely true, and I've been told it's an issue when there are multiple routines that are almost, but not quite, correct. One place where we make it easier on ourselves at this level is restricting the inheritance hierarchy. Since pretty much everything inherits directly from default it's pretty simple to predict. -- Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
[netlabs #788] [PATCH] Array fixes (and tests)
# New Ticket Created by Simon Glover
# Please include the string: [netlabs #788]
# in the subject line of all future correspondence about this issue.
# http://bugs6.perl.org/rt2/Ticket/Display.html?id=788 >
This patch fixes a number of off-by-one errors in array.pmc, and adds a
few more tests.
Simon
--- classes/array.pmc.old Wed Jul 10 15:33:45 2002
+++ classes/array.pmc Wed Jul 10 15:50:03 2002
@@ -71,7 +71,7 @@ pmclass Array {
}
INTVAL type () {
-return 0;
+return enum_class_Array;
}
INTVAL type_keyed (KEY* key) {
@@ -132,7 +132,7 @@ pmclass Array {
kp = &key->atom;
ix = atom2int(INTERP, kp);
-if (ix > SELF->cache.int_val || ix < 0) {
+if (ix >= SELF->cache.int_val || ix < 0) {
internal_exception(OUT_OF_BOUNDS, "Array element out of bounds!\n");
}
@@ -156,7 +156,7 @@ pmclass Array {
kp = &key->atom;
ix = atom2int(INTERP, kp);
-if (ix > SELF->cache.int_val || ix < 0) {
+if (ix >= SELF->cache.int_val || ix < 0) {
internal_exception(OUT_OF_BOUNDS, "Array element out of bounds!\n");
}
@@ -181,7 +181,7 @@ pmclass Array {
kp = &key->atom;
ix = atom2int(INTERP, kp);
-if (ix > SELF->cache.int_val || ix < 0) {
+if (ix >= SELF->cache.int_val || ix < 0) {
internal_exception(OUT_OF_BOUNDS, "Array element out of bounds!\n");
}
@@ -205,7 +205,7 @@ pmclass Array {
kp = &key->atom;
ix = atom2int(INTERP, kp);
-if (ix > SELF->cache.int_val || ix < 0) {
+if (ix >= SELF->cache.int_val || ix < 0) {
internal_exception(OUT_OF_BOUNDS, "Array element out of bounds!\n");
}
@@ -229,7 +229,7 @@ pmclass Array {
kp = &key->atom;
ix = atom2int(INTERP, kp);
-if (ix > SELF->cache.int_val || ix < 0) {
+if (ix >= SELF->cache.int_val || ix < 0) {
internal_exception(OUT_OF_BOUNDS, "Array element out of bounds!\n");
}
@@ -254,7 +254,7 @@ pmclass Array {
kp = &key->atom;
ix = atom2int(INTERP, kp);
-if (ix > SELF->cache.int_val || ix < 0) {
+if (ix >= SELF->cache.int_val || ix < 0) {
internal_exception(OUT_OF_BOUNDS, "Array element out of bounds!\n");
}
@@ -274,7 +274,7 @@ pmclass Array {
kp = &key->atom;
ix = atom2int(INTERP, kp);
-if (ix > SELF->cache.int_val || ix < 0) {
+if (ix >= SELF->cache.int_val || ix < 0) {
internal_exception(OUT_OF_BOUNDS, "Array element out of bounds!\n");
}
@@ -336,11 +336,11 @@ pmclass Array {
void set_number (PMC * value) {
INTVAL idx = (INTVAL)value->cache.num_val;
-resize_array(interpreter, SELF, idx+1);
+resize_array(interpreter, SELF, idx);
}
void set_number_native (FLOATVAL idx) {
-resize_array(interpreter, SELF, (INTVAL)idx + 1);
+resize_array(interpreter, SELF, (INTVAL)idx);
}
void set_number_bignum (BIGNUM* value) {
--- t/pmc/array.t.old Wed Jul 10 15:24:00 2002
+++ t/pmc/array.t Wed Jul 10 16:01:47 2002
@@ -1,9 +1,9 @@
#! perl -w
-use Parrot::Test tests => 1;
+use Parrot::Test tests => 5;
use Test::More;
-output_is(<<'CODE', <<'OUTPUT', "Basic array tests");
+output_is(<<'CODE', <<'OUTPUT', "Setting array size");
new P0,.Array
set I0,P0
@@ -17,31 +17,108 @@ OK_1: print "ok 1\n"
print "not "
OK_2: print "ok 2\n"
+ set P0,2.0
+ set I0,P0
+ eq I0,2,OK_3
+ print "not "
+OK_3: print "ok 3\n"
+
+new P1, .PerlInt
+set P1, 3
+ set P0,P1
+ set I0,P0
+ eq I0,3,OK_4
+ print "not "
+OK_4: print "ok 4\n"
+
+
+end
+CODE
+ok 1
+ok 2
+ok 3
+ok 4
+OUTPUT
+
+output_is(<<'CODE', <<'OUTPUT', "Setting first element");
+new P0, .Array
+set P0, 1
+
set P0,0,-7 # set P0[0], -7
set I0,P0,0 # set I0, P0[0]
- eq I0,-7,OK_3
+ eq I0,-7,OK_1
print "not "
-OK_3: print "ok 3\n"
+OK_1: print "ok 1\n"
set P0,0,3.7 # set P0[0], 3.7
set N0,P0,0 # set N0, P0[0]
- eq N0,3.7,OK_4
+ eq N0,3.7,OK_2
print "not "
-OK_4: print "ok 4\n"
+OK_2: print "ok 2\n"
set P0,0,"Buckaroo" # set P0[0], "Buckaroo"
set S0,P0,0 # set S0, P0[0]
- eq S0,"Buckaroo",OK_5
+ eq S0,"Buckaroo",OK_3
print "not "
-OK_5: print "ok 5\n"
+OK_3: print "ok 3\n"
end
CODE
ok 1
ok 2
ok 3
-ok 4
-ok 5
+OUTPUT
+
+output_is(<<'CODE', <<'OUTPUT', "Setting second element");
+new P0, .Array
+set P0, 2
+
+ set P0[1], -7
+ set I0, P0[1]
+ eq I0,-7,OK_1
+ print "not "
+OK_1: print "ok 1\n"
+
+ set P0[1], 3.7
+ set N0, P0[1]
+ eq N0,3.7,OK_2
+ print "not "
+OK_2: print "ok 2\n"
+
+ set P0[1],"Buckaroo"
+ set S0, P0[1]
+ eq
[netlabs #789] [PATCH] Squish some warnings
# New Ticket Created by Simon Glover
# Please include the string: [netlabs #789]
# in the subject line of all future correspondence about this issue.
# http://bugs6.perl.org/rt2/Ticket/Display.html?id=789 >
stack_chunk is now Stack_Chunk...
Simon
--- sub.c.old Wed Jul 10 14:53:24 2002
+++ sub.c Wed Jul 10 15:00:50 2002
@@ -34,8 +34,8 @@ new_sub(struct Parrot_Interp * interp, o
/* Using system memory until I figure out GC issues */
struct Parrot_Sub * newsub = mem_sys_allocate(sizeof(struct Parrot_Sub));
newsub->init = address;
-newsub->user_stack = (struct stack_chunk *)new_stack(interp);
-newsub->control_stack = (struct stack_chunk *)new_stack(interp);
+newsub->user_stack = (Stack_Chunk_t *)new_stack(interp);
+newsub->control_stack = (Stack_Chunk_t *)new_stack(interp);
newsub->lex_pad = NULL;
return newsub;
}
@@ -49,8 +49,8 @@ new_coroutine(struct Parrot_Interp * int
mem_sys_allocate(sizeof(struct Parrot_Coroutine));
newco->init = address;
newco->resume = NULL;
-newco->ctx.user_stack = (struct stack_chunk *)new_stack(interp);
-newco->ctx.control_stack = (struct stack_chunk *)new_stack(interp);
+newco->ctx.user_stack = (Stack_Chunk_t *)new_stack(interp);
+newco->ctx.control_stack = (Stack_Chunk_t *)new_stack(interp);
newco->lex_pad = NULL;
return newco;
}
--- include/parrot/sub.h.oldWed Jul 10 14:53:33 2002
+++ include/parrot/sub.hWed Jul 10 14:54:06 2002
@@ -20,8 +20,8 @@
typedef struct Parrot_Sub {
INTVAL flags;
-struct stack_chunk *user_stack;
-struct stack_chunk *control_stack;
+struct Stack_Chunk *user_stack;
+struct Stack_Chunk *control_stack;
struct Scratchpad *lex_pad;
opcode_t*init;
} * parrot_sub_t;
[netlabs #790] [PATCH] MANIFEST update
# New Ticket Created by Simon Glover # Please include the string: [netlabs #790] # in the subject line of all future correspondence about this issue. # http://bugs6.perl.org/rt2/Ticket/Display.html?id=790 > Self-explanatory. Simon --- MANIFEST.oldWed Jul 10 14:43:48 2002 +++ MANIFESTWed Jul 10 14:45:18 2002 @@ -87,6 +87,7 @@ disassemble.c disassemble.pl docs/embed.pod docs/faq.pod +docs/glossary.pod docs/intro.pod docs/jit.pod docs/overview.pod @@ -250,6 +251,7 @@ languages/cola/gen.c languages/cola/semant.c languages/cola/sym.c languages/cola/type.c +languages/forth/forth.pasm languages/imcc/Makefile languages/imcc/README languages/imcc/cfg.c @@ -341,9 +343,12 @@ languages/scheme/t/arith/nested.t languages/scheme/t/harness languages/scheme/t/io/basic.t languages/scheme/t/logic/basic.t +lib/Make/Archive_Obj.pm lib/Make/CC_Obj.pm lib/Make/Dependency.pm lib/Make/Link_Obj.pm +lib/Make/Link_Shared_Obj.pm +lib/Make/Lint_Obj.pm lib/Make/Perl_Obj.pm lib/Make/Target_Obj.pm lib/Parrot/BuildUtil.pm
Re: Mutable vs immutable strings
Dan Sugalski wrote: > John Porter wrote: > > but what about non-PMC variables? > > Generally speaking, there aren't any. Everything else (in this case > the buffer/string things) is for internal use only. Languages aren't > supposed to expose strings directly. Languages are only supposed to expose PMCs? Not ints, nums, strs? Why have them if Perl can't see them? -- John Douglas Porter __ Do You Yahoo!? Sign up for SBC Yahoo! Dial - First Month Free http://sbc.yahoo.com
Re: Mutable vs immutable strings
At 02:13 PM 7/10/2002 -0700, John Porter wrote:
>Dan Sugalski wrote:
> > John Porter wrote:
> > > but what about non-PMC variables?
> >
> > Generally speaking, there aren't any. Everything else (in this case
> > the buffer/string things) is for internal use only. Languages aren't
> > supposed to expose strings directly.
>
>Languages are only supposed to expose PMCs?
>Not ints, nums, strs?
>Why have them if Perl can't see them?
Since Perl vars type-morph themselves, Perl will use PMC types everywhere
that there is an exposed interface. Internally you could use an I/S/N register.
I see no reason why
foreach my $i (@nums) {
...
}
should not use an Ix reg for $i, but maybe $i isn't an int at all, or @nums
is actually a mixed list. Even if we did know that @nums was all integers,
as soon as we see:
%MY{'$i'}, or we find an eval{}, $i must escape the register and we lose
the optimization.
Its almost as if the only optimization will be for
foreach my $i (1...1)
where we know the type ahead of time.
We've built this register based VM upon which Perl will probably be
the most non-optimized language. Things like exposing your lexical pads,
eval, etc. blow optimization out of the water.
A language like Java/C# will run much faster on Parrot than Perl6,
however, this doesn't worry me, since Perl itself will probably still
get 5-10x speedup even with its use of PMCs everywhere.
-Melvin
Re: Mutable vs immutable strings
On Wed, 10 Jul 2002, Melvin Smith wrote:
> At 02:13 PM 7/10/2002 -0700, John Porter wrote:
>
> >Dan Sugalski wrote:
> > > John Porter wrote:
> > > > but what about non-PMC variables?
> > >
> > > Generally speaking, there aren't any. Everything else (in this case
> > > the buffer/string things) is for internal use only. Languages aren't
> > > supposed to expose strings directly.
> >
> >Languages are only supposed to expose PMCs?
> >Not ints, nums, strs?
> >Why have them if Perl can't see them?
>
> Since Perl vars type-morph themselves, Perl will use PMC types everywhere
> that there is an exposed interface. Internally you could use an I/S/N register.
>
> I see no reason why
>
> foreach my $i (@nums) {
> ...
> }
>
> should not use an Ix reg for $i, but maybe $i isn't an int at all, or @nums
> is actually a mixed list. Even if we did know that @nums was all integers,
> as soon as we see:
>
> %MY{'$i'}, or we find an eval{}, $i must escape the register and we lose
> the optimization.
So we don't see them. %MY is so ugly nobody will want to use it. And as
for eval{}, that's actually eval "". try{} will not pose a problem. Keep
in mind that eval "" isn't that common either. Also if you're compiling
some code every iteration, an integer optimization won't help out that
much.
And we do know whether @nums are all integers, if people program well.
Arrays can be typed, too.
> Its almost as if the only optimization will be for
>
> foreach my $i (1...1)
>
> where we know the type ahead of time.
>
Luke
Re: Mutable vs immutable strings
On Wednesday 10 July 2002 02:39 pm, Melvin Smith wrote:
>
> Since Perl vars type-morph themselves, Perl will use PMC types everywhere
> that there is an exposed interface. Internally you could use an I/S/N
> register.
>
> I see no reason why
>
> foreach my $i (@nums) {
> ...
> }
>
> should not use an Ix reg for $i, but maybe $i isn't an int at all, or @nums
> is actually a mixed list.
I thought that was the whole point of typing in Perl 6.
my int @nums = (1, "2", 3.1); # (1,2,3) assuming C 'works'
for @nums -> $i {} # $i is a PMC, still
for @nums -> int $i {} # $i is in an Ix register now
for @nums {}# will $_ be smart enough to 'int' itself? I hope so
Yes, people will have to think about optimizing their code. It's not great,
but it's not that onerous. It might be nice if the current topic would type
itself based on its initializer, when obvious.
Ashley Winters
Adding the system stack to the root set
Okay, one of the outstanding problems we've had is in adding the system stack to the root set. A number of depressingly unpleasant solutions have been proposed (most of 'em by me :) but they're all hackish and expensive in the common case, which is not needing to GC anything. Turns out, though, that with our current scheme we can walk the system stack easily enough on platforms with a contiguous stack. So that's what we're going to do. The GC'll walk the stack (which should, generally speaking, have very little data on it) and mark all the PMCs and Buffers for which pointers can be found as live. Yes, this is an issue for systems with a chunked stack. As far as I know that only applies to the various ARM OSes, and for those we'll have to have some different system specific code to deal with the stack. (Which is fine) -- Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: What's MY.line?
At 04:24 PM 7/10/2002 +0100, [EMAIL PROTECTED] wrote:
>Dan Sugalski <[EMAIL PROTECTED]> writes:
>
> > At 9:50 PM -0400 7/9/02, Chip Salzenberg wrote:
> > >3. Is C<%MY> intended to reflect the PAD?
> >
> > Yes.
>
>Hey! How's this for a scary thought:
>
>$continuation.the_pad
>
>I'll get my coat.
Hah, good try!
I think this would be easy for Parrot. A continuation object will
have all of its context encapsulated already, including the lexical pad
stack.
Assuming the existence of this mystical beast, it could work like:
%continuation.the_pad{'$foo'}
-Melvin
Re: What's MY.line?
Chip Salzenberg wrote in perl.perl6.language : > In (re?)examining the Apocalypses, I've found something that confuses me a > bit. A2 refers to C as a "pseudopackage" and says: > > __LINE__ becomes MY.line > __FILE__ " MY.file > [...] > > With regard to C: > >2. What are "line" and "file"? Properties? Class variables? > (Probably not class variables since C is not called a class.) That's the implementation problem ;-) In perl 5, __LINE__, __FILE__ and __PACKAGE__ are replaced at compile-time (in fact, at tokenizing-time) by the appropriate constants. The question is : to which kind of bytecode MY.file (etc.) get compiled ? -- Rafael Garcia-Suarez : http://use.perl.org/~rafael/
Re: What's MY.line?
At 4:24 PM +0100 7/10/02, [EMAIL PROTECTED] wrote: >Dan Sugalski <[EMAIL PROTECTED]> writes: > >> At 9:50 PM -0400 7/9/02, Chip Salzenberg wrote: >> >3. Is C<%MY> intended to reflect the PAD? >> >> Yes. > >Hey! How's this for a scary thought: > >$continuation.the_pad What's that supposed to do, though? You want to alter the pad that gets put in place at the top of the pad list for a continuation? No problem. A bad idea, mind, but no problem... :) -- Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: What's MY.line?
At 10:12 PM + 7/10/02, Rafael Garcia-Suarez wrote: >Chip Salzenberg wrote in perl.perl6.language : >> In (re?)examining the Apocalypses, I've found something that confuses me a >> bit. A2 refers to C as a "pseudopackage" and says: >> >> __LINE__ becomes MY.line >> __FILE__ " MY.file >> >[...] >> >> With regard to C: >> >> 2. What are "line" and "file"? Properties? Class variables? >>(Probably not class variables since C is not called a class.) > >That's the implementation problem ;-) >In perl 5, __LINE__, __FILE__ and __PACKAGE__ are replaced at >compile-time (in fact, at tokenizing-time) by the appropriate constants. >The question is : to which kind of bytecode MY.file (etc.) get compiled ? Well, unless they're accessible symbollically, there's no difference between __LINE__ and MY.line. Just string constants to compare against... -- Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
RE: vtables and multimethod dispatch
Nicholas Clark:
# On Wed, Jul 10, 2002 at 10:17:47AM -0700, John Porter wrote:
# >
# > Dan Sugalski wrote:
#
# > > Heh. I never expected to have to dust off my trig skills when I
# > > started this. If I need to dig out the calculus books, I
# think I'll
# > > just go run screaming...
# >
# > Not to worry. There's no trig involved. Just the Pythagorean
# > theorem.
#
# Unless I'm being thick, x² < y² whenever x < y for positive x
# and y (ie you don't need to take the square root of the
# hypotenuse to work out which hypotenuse is shorter. And all
# we're actually interested in which one is shorter, aren't we?)
Assuming x and y are integers, yes. Which'll probably be all we ever
deal with, so for all intents and purposes you're correct.
--Brent Dax <[EMAIL PROTECTED]>
@roles=map {"Parrot $_"} qw(embedding regexen Configure)
He who fights and runs away wasted valuable running time with the
fighting.
Re: Mutable vs immutable strings
At 04:34 PM 7/10/2002 -0600, Luke Palmer wrote:
>On Wed, 10 Jul 2002, Melvin Smith wrote:
>
> > At 02:13 PM 7/10/2002 -0700, John Porter wrote:
> >
> > >Dan Sugalski wrote:
> > > > John Porter wrote:
> > > > > but what about non-PMC variables?
> > > >
> > > > Generally speaking, there aren't any. Everything else (in this case
> > > > the buffer/string things) is for internal use only. Languages aren't
> > > > supposed to expose strings directly.
> > >
> > >Languages are only supposed to expose PMCs?
> > >Not ints, nums, strs?
> > >Why have them if Perl can't see them?
> >
> > Since Perl vars type-morph themselves, Perl will use PMC types everywhere
> > that there is an exposed interface. Internally you could use an I/S/N
> register.
> >
> > I see no reason why
> >
> > foreach my $i (@nums) {
> > ...
> > }
> >
> > should not use an Ix reg for $i, but maybe $i isn't an int at all, or @nums
> > is actually a mixed list. Even if we did know that @nums was all integers,
> > as soon as we see:
> >
> > %MY{'$i'}, or we find an eval{}, $i must escape the register and we lose
> > the optimization.
>
>So we don't see them. %MY is so ugly nobody will want to use it. And as
So take it out and inform Larry. :)
>for eval{}, that's actually eval "". try{} will not pose a problem. Keep
>in mind that eval "" isn't that common either. Also if you're compiling
>some code every iteration, an integer optimization won't help out that
>much.
Thanks for the syntax correction...
I was referring to the above situation where a lexical might be optimized
away without being stored in a pad (for %MY).
Granted, I never said it was used often, just that it may kill optimizations.
I may also be too paranoid. I really don't care for %MY either, but it
isn't my language.
>And we do know whether @nums are all integers, if people program well.
>Arrays can be typed, too.
I don't know enough about this to comment.
I do know that PMC (Px register) usage gives up a lot of
performance to Ix/Sx/Nx regs, especially on JIT, and we should optimize
in every possible case.
-Melvin
[netlabs #791] [PATCH] add some ops to core.ops
# New Ticket Created by "Sean O'Rourke"
# Please include the string: [netlabs #791]
# in the subject line of all future correspondence about this issue.
# http://bugs6.perl.org/rt2/Ticket/Display.html?id=791 >
This patch adds several ops that exist in the vtables, and seem useful,
but aren't in core.ops yet:
- le, lt, ge, gt, eq, ne on PMC's
- defined(INT, PMC)
- neg(PMC, PMC)
/s
-- attachment 1 --
url: http://bugs6.perl.org/rt2/attach/3731/3471/05e9b6/core.ops.patch
*** core.ops.~1.181.~ Sat Jul 6 13:08:59 2002
--- core.opsWed Jul 10 19:03:39 2002
***
*** 1132,1143
--- 1132,1147
=item B(in STR, in STR)
+ =item B(in PMC, in PMC)
+
=item B(in INT, in INT, inconst INT)
=item B(in NUM, in NUM, inconst INT)
=item B(in STR, in STR, inconst INT)
+ =item B(in PMC, in PMC, inconst INT)
+
Branch if $1 is equal to $2.
Return address is popped off the call stack if no address is supplied.
***
*** 1165,1170
--- 1169,1181
goto NEXT();
}
+ op eq (in PMC, in PMC) {
+ if ($1->vtable->is_equal(interpreter, $1, $2)) {
+ goto POP();
+ }
+ goto NEXT();
+ }
+
inline op eq(in INT, in INT, inconst INT) {
if ($1 == $2) {
goto OFFSET($3);
***
*** 1186,1191
--- 1197,1208
goto NEXT();
}
+ op eq (in PMC, in PMC, inconst INT) {
+ if ($1->vtable->is_equal(interpreter, $1, $2)) {
+ goto OFFSET($3);
+ }
+ goto NEXT();
+ }
***
*** 1195,1206
--- 1212,1227
=item B(in STR, in STR)
+ =item B(in PMC, in PMC)
+
=item B(in INT, in INT, inconst INT)
=item B(in NUM, in NUM, inconst INT)
=item B(in STR, in STR, inconst INT)
+ =item B(in PMC, in PMC, inconst INT)
+
Branch if $1 is not equal to $2.
Return address is popped off the call stack if no address is supplied.
***
*** 1228,1233
--- 1249,1261
goto NEXT();
}
+ op ne (in PMC, in PMC) {
+ if (! $1->vtable->is_equal(interpreter, $1, $2)) {
+ goto POP();
+ }
+ goto NEXT();
+ }
+
inline op ne(in INT, in INT, inconst INT) {
if ($1 != $2) {
goto OFFSET($3);
***
*** 1249,1254
--- 1277,1288
goto NEXT();
}
+ op ne(in PMC, in PMC, inconst INT) {
+ if (! $1->vtable->is_equal(interpreter, $1, $2)) {
+ goto OFFSET($3);
+ }
+ goto NEXT();
+ }
***
*** 1256,1265
=item B(in NUM, in NUM, inconst INT)
- =item B(in PMC, in PMC, inconst INT)
-
=item B(in STR, in STR, inconst INT)
Branch if $1 is less than $2.
=cut
--- 1290,1299
=item B(in NUM, in NUM, inconst INT)
=item B(in STR, in STR, inconst INT)
+ =item B(in PMC, in PMC, inconst INT)
+
Branch if $1 is less than $2.
=cut
***
*** 1285,1290
--- 1319,1330
goto NEXT();
}
+ op lt (in PMC, in PMC, inconst INT) {
+ if ($1->vtable->cmp(interpreter, $1, $2) < 0) {
+ goto OFFSET($3);
+ }
+ goto NEXT();
+ }
***
*** 1294,1299
--- 1334,1341
=item B(in STR, in STR, inconst INT)
+ =item B(in PMC, in PMC, inconst INT)
+
Branch if $1 is less than or equal to $2.
=cut
***
*** 1319,1324
--- 1361,1372
goto NEXT();
}
+ op le(in PMC, in PMC, inconst INT) {
+ if ($1->vtable->cmp(interpreter, $1, $2) <= 0) {
+ goto OFFSET($3);
+ }
+ goto NEXT();
+ }
***
*** 1328,1333
--- 1376,1383
=item B(in STR, in STR, inconst INT)
+ =item B(in PMC, in PMC, inconst INT)
+
Branch if $1 is greater than $2.
=cut
***
*** 1353,1358
--- 1403,1414
goto NEXT();
}
+ op gt(in PMC, in PMC, inconst INT) {
+ if ($1->vtable->cmp(interpreter, $1, $2) > 0) {
+ goto OFFSET($3);
+ }
+ goto NEXT();
+ }
***
*** 1362,1367
--- 1418,1425
=item B(in STR, in STR, inconst INT)
+ =item B(in PMC, in PMC, inconst INT)
+
Branch if $1 is greater than or equal to $2.
=cut
***
*** 1387,1392
--- 1445,1457
goto NEXT();
}
+ op ge(in PMC, in PMC, inconst INT) {
+ if ($1->vtable->cmp(interpreter, $1, $2) >= 0) {
+ goto OFFSET($3);
+ }
+ goto NEXT();
+ }
+
=item B(in INT, inconst INT)
***
*** 1926,1931
--- 1991,1998
=item B(out NUM, in NUM)
+ =item B(out PMC, in PMC)
+
Set $1 to the negative of
[netlabs #792] [PATCH] add some ops to Perl PMC's
# New Ticket Created by "Sean O'Rourke"
# Please include the string: [netlabs #792]
# in the subject line of all future correspondence about this issue.
# http://bugs6.perl.org/rt2/Ticket/Display.html?id=792 >
This patch does the following:
- add defined() to PerlUndef
- add neg(PMC) to PerlNum
- fix logical_not(PMC) in PerlInt -- it was backwards.
/s
-- attachment 1 --
url: http://bugs6.perl.org/rt2/attach/3733/3474/6f0d76/perlpmc.patch
Index: perlint.pmc
===
RCS file: /cvs/public/parrot/classes/perlint.pmc,v
retrieving revision 1.24
diff -w -p -u -r1.24 perlint.pmc
--- perlint.pmc 12 Jun 2002 22:12:18 - 1.24
+++ perlint.pmc 11 Jul 2002 03:51:50 -
@@ -590,7 +590,7 @@ fprintf(stderr,"perlint_modulus not impl
}
void logical_not (PMC* value) {
-SELF->cache.int_val = (INTVAL)(!value->vtable->get_bool(INTERP, value));
+ value->vtable->set_integer_native(INTERP, value, !SELF->cache.int_val);
}
void repeat (PMC* value, PMC* dest) {
@@ -606,4 +606,5 @@ fprintf(stderr,"perlint_modulus not impl
void decrement () {
SELF->cache.int_val --;
}
+
}
Index: perlnum.pmc
===
RCS file: /cvs/public/parrot/classes/perlnum.pmc,v
retrieving revision 1.25
diff -w -p -u -r1.25 perlnum.pmc
--- perlnum.pmc 12 Jun 2002 22:12:18 - 1.25
+++ perlnum.pmc 11 Jul 2002 03:51:50 -
@@ -318,6 +318,10 @@ fprintf(stderr,"modulus_float not implem
fprintf(stderr,"modulus_same not implemented\n");
}
+void neg (PMC * dest) {
+ dest->vtable->set_number_native(INTERP, dest, -SELF->cache.num_val);
+}
+
void bitwise_or (PMC* value, PMC* dest) {
dest->vtable->set_integer_native(INTERP, dest,
(INTVAL)SELF->cache.num_val |
@@ -462,4 +466,5 @@ fprintf(stderr,"repeat_int not implement
void decrement () {
SELF->cache.num_val --;
}
+
}
Index: perlundef.pmc
===
RCS file: /cvs/public/parrot/classes/perlundef.pmc,v
retrieving revision 1.16
diff -w -p -u -r1.16 perlundef.pmc
--- perlundef.pmc 21 Jun 2002 17:22:34 - 1.16
+++ perlundef.pmc 11 Jul 2002 03:51:51 -
@@ -447,4 +447,8 @@ pmclass PerlUndef {
Parrot_warn(INTERP, PARROT_WARNINGS_UNDEF_FLAG, "Use of uninitialized value
in repeat");
dest->vtable->set_string(INTERP, dest, NULL);
}
+
+INTVAL defined () {
+ return 0;
+}
}
Re: [netlabs #791] [PATCH] add some ops to core.ops
At 10:38 PM 7/10/2002 -0500, via RT wrote: ># New Ticket Created by "Sean O'Rourke" ># Please include the string: [netlabs #791] ># in the subject line of all future correspondence about this issue. ># http://bugs6.perl.org/rt2/Ticket/Display.html?id=791 > > > >This patch adds several ops that exist in the vtables, and seem useful, >but aren't in core.ops yet: Looks good, applied. -Melvin
Re: Mutable vs immutable strings
On Wednesday 10 July 2002 08:18 pm, Melvin Smith wrote:
> I was referring to the above situation where a lexical might be optimized
> away without being stored in a pad (for %MY).
I would *hope* %MY is only modified at compile-time. I wouldn'd be upset if
Perl ignored my attempts to access %MY at runtime.
As for eval, if I ever need a CS master's thesis subject, I could always try
this...
Whenever the compiler runs across an eval, take a continuation from within the
compiler. Make sure the compiler keeps enough state in lexicals to start
where it leaves off. At runtime when the eval is reached, save the current
continuation and hop over to the compile-time continuation and try compiling
it in-place as a sub. It would be necessary to treat any lexicals used inside
the eval"" as arguments to the sub -- otherwise usage of those lexicals
inside the sub might change the optimization of those scalars and you
wouldn't be able to call the continuation back to the runtime eval and have
it work. Then, fiddle with the newly compiled bytecode and find the address
of the eval continuation location we jumped from, and go back there.
for 1..1000 -> int $i { # $i is optimized away in a nice register
my $str = '$i + 1';# assume this isn't constant voodoo'd away
#eval $str;# at runtime, this could mean:
my $compiletime_cont;
my $runtime_cont;
BEGIN {
$compiletime_cont = take_continuation();
if caller(0).continued { # just guessing at a flag
# this block is actually called at _runtime_
# this should morph the else clause bytecode below
Perl6::compile_for_eval($str, $runtime_cont);
invoke($runtime_cont);
}
}
$runtime_cont = take_continuation();
unless caller(0).continued {
invoke($compiletime_cont);
} else {
# this code is modified/generated/whatever by compile_for_eval above
my sub &eval_expression = sub ($i) { $i + 1 }
eval_expression($i);
# I decided $(-> $i { $i + 1 }).($i) was too obfuscated. You're welcome
}
}
Wouldn't it be great to have something so incredibly slow? Code morphing is so
80's! Okay, I've had my headache-inducing thought for the evening.
Yes, my Scheme interpreter written in Perl6 is coming along nicely. Muahaha!
(kidding, obviously)
Ashley Winters
