Re: Pie-thon state 5 - and final
Wow. I'm impressed you got anywhere near this far! Your work sounds very promising, a great way to validate Parrot's value proposition. On Sat, Jul 24, 2004 at 12:24:48PM +0200, Leopold Toetsch wrote: | And there is of course the question, if we should really be | "bug"-compatible | | >>> False=42 | >>> if False: | ... print "aha", False | ... | aha 42 But that's not a bug. If one assignes "42" to False, then this is what False means, 42, nothing more and nothing less. Yes, I know you know this. If you could, would you set your goal slightly higher than just the Python tests? I'd love to see Parrot do Stackless Python! *bings* Clark
Re: the whole and everything
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> At 9:18 PM +0200 7/20/04, Leopold Toetsch wrote:
[ I've to come back to my proposed scheme ]
>>No. The whole frame is the continuation. Its holding exactly the
>>interpreter state at the time of calling into the sub. Including
>>registers, which makes register preserving obsolete.
> Which means that as soon as you use it the first time it becomes
> useless, since you can't know when it stops being used. That makes
> them one use--every time you enter the sub you need a new one, just
> as if you were calling in recursively.
I don't think so. As it might not be outerly clear, how it would look
like: here are two code snippets showing the basics of my idea.
1.) Calling a sub
next = sub_pmc->invoke->(&interp, sub_pmc, next);
^^^
void *
invoke(Interp** interp, PMC* self, void *next) {
Interp *caller = *interp;
parrot_sub_t sub = PMC_sub(self);
Interp *frame = sub->frame;
if (!frame || frame->caller)
frame = copy_interp(caller);
else
update_context(frame, caller);
frame->prev = sub->frame;
sub->frame = frame;
frame->caller = caller;
frame->sub_pmc = self;
copy_func_params(frame, caller);
*interp = frame;
next = switch_to_segment(frame, sub->seg);
return next;
}
2.) return from a sub
PMC *self = interp->sub_pmc;
next = self->vtable->return(&interp, self)
void *
return(Interp** interp, PMC* self) {
parrot_sub_t sub = PMC_sub(self);
Interp *frame = sub->frame;
Interp *caller = frame->caller;
Interp *prev = sub->frame = frame->prev;
if (prev && !prev->caller)
add_frame_cache(prev, sub); [1]
copy_return_values(caller, frame);
*interp = caller;
return switch_to_segment(caller, sub->seg);
}
> It's just not going to fly, Leo.
Im Gegenteil ;)
I know, that there are issues with threads. But we have to duplicate or
C<< pmc->vtable->share >> anyway. But copying the sub PMC is cheap, much
more expensive is that we have to reJIT (and/or re-predereference) the
code, because these run loops have absolute register addresses. Doing
that now at a much more fine-grained level, i.e. per subroutine that is
executed in a thread and not per file, might be even a big win.
Above scheme is thread-safe, if there are locks around the code. This
could be an alternative to duplicating subroutine PMCs, it depends. But
for now, I'd like to get single-threaded execution running - fast.
[1] If there is no caller on that frame, it would go into some kind of
frame cache, which C could use, or it could be kept for
that sub, probably depending on memory usage.
leo
Re: Pie-thon state 5 - and final
Clark C. Evans wrote: Wow. I'm impressed you got anywhere near this far! Your work sounds very promising, a great way to validate Parrot's value proposition. Thanks. On Sat, Jul 24, 2004 at 12:24:48PM +0200, Leopold Toetsch wrote: | | >>> False=42 But that's not a bug. If one assignes "42" to False, then this is what False means, 42, nothing more and nothing less. Yes, I know you know this. Well. There are (AFAIK) only 2 instances of the bool object, these shouldn't be assignable. I think that doing "(True,False) = (0,1)" and then importing some library would break things horribly. If you could, would you set your goal slightly higher than just the Python tests? I'd love to see Parrot do Stackless Python! What I know of stackless isn't too much. But Parrot is using CPS (continuation passing style) for all subroutine and method calls, including coroutines aka generators. So I think that *is* stackless Python. *bings* Clark leo
A small Parrot language: Parakeet 0.1
I have made some significant improvements to Parakeet since I last
"released" it, enough that I am now confident that it can become a
complete Parrot language that exposes all of the OO features of the VM.
So I'm calling it 0.1 with the anticipation that several more releases
will follow to finish the language.
http://www.daca.net:8080/Parakeet-0.1.tgz
Just unzip it into languages/parakeet and your ready to go.
Here's a little introduction to Parakeet:
Parakeet is a stack language like Forth. You could call it Forth by
many people's definition, but it *isn't* standard Forth. Parakeet is a
Forth that is extremely machine specific to the Parrot VM. Parakeet
also has a lot of features not found in standard Forth, like local
variables, nested words and classes and (as a result) nested
compile-time and run-time lexical word, class and variable scopes.
Parakeet is fully dynamic and unprototyped, all variables and bindings
are looked up at run-time using Parrot's lexical scratchpad stacks. In
many ways its level of object dynamics approaches that of Python, while
still retaining that Forth minimalistic thing.
Parakeet is written in PIR and compiles new words directly to PIR.
There is no "inner loop" above the Parrot VM and core words are not
"threaded" (in the Forth sense of the word), they are directly inlined
into the new word's body. Consider a simple example:
0> def count do i i println loop end
0> 5 0 count
0
1
2
3
4
0>
The new word 'count' accepts two arguments on the stack, the start on
top of the limit (in Pararkeet 'def' and 'end' correlate roughly to
Forth's ':' and ';'). I typed in the example above on one line, but it
becomes clearer when indented:
def count
do i
i println
loop
end
The PIR code that a word compiles to can be shown with the word 'see':
0> see count
.include "languages/parakeet/macros.imc"
.pcc_sub _count
$P99 = P1 # save return cont.
.POP2
push .CSTACK, .NOS
push .CSTACK, .TOS
find_lex $P0, "i"
assign $P0, .TOS
do2:
find_lex .TOS, "i"
.PUSH
.POP
print .TOS
print "\n"
pop .TOS, .CSTACK
pop .NOS, .CSTACK
inc .TOS
find_lex $P0, "i"
assign $P0, .TOS
push .CSTACK, .NOS
push .CSTACK, .TOS
ne .TOS, .NOS, do2
pop .TOS, .CSTACK
pop .NOS, .CSTACK
invoke $P99
.end
0>
If you're familiar with Forth, you might notice that Parakeet's 'do' has
a following argument unlike Forth. This argument binds to the index
value each time through the loop. This removes two of historical and
standard Forth's horrible hardwired words 'I' and 'J'. Loops can be
nested to any depth:
def foo
3 0 do i
3 0 do j
3 0 do k
i j k + + println
loop
loop
loop
end
I also have hook words 'for i ... next' for when I figure out Parrot
iterators.
Simple variables can be created with 'var':
0> 2 var x 3 var y
0> x y + println
5
0>
Classes are not so fully baked yet. Parakeet uses the following syntax:
class foo
def bar "hi!" println end
endclass
Classes can be instanciated with 'foo new':
0> foo new var f
And instances can bind to "methods" which are inner words:
0> f -> bar
hi!
0>
Classes can contain classes:
class ned
class flanders endclass
def joe flanders new var f end
endclass
There is no subclassing, yet, and I haven't figured out how to tie these
classes into other Parrot classes, yet, but the idea is there.
Curiously unlike Forth, words can also contain words and classes:
def foo
class ned endclass
def bar
"hi!" println
ned new var n # use inner class
end
bar # use inner word
end
0> foo
hi!
0>
Given these rules there are lots of ways to structure words and classes
within each other. Words and classes can be considered "static" (in the
Java sense of the word) structures. Classes can be instantiated to
provide objects with methods. When you call a word on an class instance
with '->' (bind) the instance is passed in the normal PCC way.
I haven't gotten to arguments yet to allow calling out of Parakeet, but
I plan to use '(' and ')' like so:
0> ( arg1 arg2 arg3 ) object -> method
The word '(' pushes a special marker on the stack, the arguments are
pushed on the stack, the word ')' searches down the stack for the marker
building an argument array, and the word '->' (which might have to be
renamed to handle the no-arg and arg cases) folds this up for PCC before
it makes the call.
There will be more ideas like that coming as I continue to get a better
grasp on Parrot. If there is any interest in helping develop Parakeet
(particularly if you are better at rx4 than me!) feel free to contact me
and I'll put it up on sourceforge or somewhere.
-Michel
Re: Why do users need FileHandles?
On Sun, Jul 25, 2004 at 01:32:29AM -0500, Dan Hursh wrote: : >2. Really core. This is the sort of "standard library". Just the most : >essential bits that are required for general Perl usability. You'd : >probably include most of these, even in a "trimmed down" release, such : >as an OS installer : : What most venders will ship. Which is basically why we are planning not to produce one of these. I think we should concentrate on 1 and 3. Larry
Re: Why do users need FileHandles?
Larry Wall wrote: On Sun, Jul 25, 2004 at 01:32:29AM -0500, Dan Hursh wrote: : >2. Really core. This is the sort of "standard library". Just the most : >essential bits that are required for general Perl usability. You'd : >probably include most of these, even in a "trimmed down" release, such : >as an OS installer : : What most venders will ship. Which is basically why we are planning not to produce one of these. I think we should concentrate on 1 and 3. I know. In that case, I think venders are liable to be lazy or peeved and ship option 1 or worse, nothing. Is the answer really supposed to be CPAN or no library? Is there a plan to at least have stable snapshots of CPAN? Sorry to be a pest on this, but the implications actually scare me about things I didn't worry about before because I had confidence that they would be addressed in 'the library'. Maybe I just need to sit and meditate some more. Dan
Re: Why do users need FileHandles?
On Sun, Jul 25, 2004 at 11:41:14PM -0500, Dan Hursh wrote: : Larry Wall wrote: : : >On Sun, Jul 25, 2004 at 01:32:29AM -0500, Dan Hursh wrote: : >: >2. Really core. This is the sort of "standard library". Just the most : >: >essential bits that are required for general Perl usability. You'd : >: >probably include most of these, even in a "trimmed down" release, such : >: >as an OS installer : >: : >: What most venders will ship. : > : >Which is basically why we are planning not to produce one of these. : >I think we should concentrate on 1 and 3. : : I know. In that case, I think venders are liable to be lazy or peeved : and ship option 1 or worse, nothing. Is the answer really supposed to : be CPAN or no library? Is there a plan to at least have stable : snapshots of CPAN? Sorry to be a pest on this, but the implications : actually scare me about things I didn't worry about before because I had : confidence that they would be addressed in 'the library'. Maybe I just : need to sit and meditate some more. Sounds like you're confusing #3 with #4. Larry
