"Sean O'Rourke" <[EMAIL PROTECTED]> writes:
> > At the moment I try to use this to get functions working in Scheme. I
> > have something, that is somewhat working in gdb, but not ready yet.
>
> Maybe we need a "pad pumpkin" to avoid these kinds of race conditions.
My actual implementation is a hack using a patched version of Jonathans
patch.
> > The problem I had using this new/pop system arises when an internal
> > lexical scope leaks out of its surrounding scope i.e.
> >
> > sub make_counter {
> > my $counter = shift;
> > return sub { my $val = shift; return $counter += $val ; }
> > }
> > $counter1 = make_counter (0);
> > $counter2 = make_counter (100);
> > print $counter1->(1);
> > print $counter2->(2);
> > print $counter1->(3);
> >
> > When you call $counter1 you have to reinstall the scope of the function
> > definition (the one containing $counter), which is different from the
> > current scope,
>
> The way I have it, "invoke" implicitly pushes its saved pad, which leads
> to an odd extra pop_pad at the end of anonymous subs, but works. Your
> description (snipped) sounds spot-on to me.
You do something like push_pad implicitly in the Sub class, but
without a corresponding op in core.ops, when you invoke the Sub.
You also get the current lexical scope implicitly at Sub creation
time. This may be intentional so that the bytecode cant mess with the
lexical stack, but there are already. new_pad and pop_pad.
What would help me much in implementing scheme functions is a way to
get the current scope at bytecode level, and to extend an arbitary
scope.
Im currently thinking of the following ops
new_pad
create a completly new (empty) pad and push it onto the
pad_stack.
new_pad (in PMC)
create a new pad with $1 as parent, pushing this pad on the
stack.
get_pad (out PMC)
get the current pad, storing it in $1.
get_pad (out PMC, in INT)
get a pad corresponding to current scope at depth $2; store it
in $1. Negative values count from the outermost scope.
new_pad (in INT)
The same as get_pad P0, $1; new_pad P0.
(This is essentally the same you wrote).
store_lex (in STR, in PMC) and store_lex (in INT, in STR, in PMC)
the same way you do it.
> > My current implementation does something like this:
> >
> > Function definition: Get the current scope and store it in the
> > function, along with the definition of the arguments, and the body of
> > the function.
>
> Check.
>
> > Function invokation: Get the current scope and store it on the stack,
>
> Okay, the way I did it, it already is the top of the stack. Same thing, I
> think.
>
> > Set the scope to the value stored in the function, which can be
> > completely independend of the (formerly) current scope. Then extend
> > this scope by the arguments of the function.
>
> And possibly its locals, right?
In scheme locals are always some funny kind of lambda
(let ((<var1> <val1)(<var2> <val2>)...) <body>)
is the same as
((lambda (<var1> <var2> ...) <body>) <val1> <val2>)
In perl every
my $foo;
will translate to
new P0, .PerlUndef
store_lex 0,"$foo",P0
> > Run the body in this scope. At last set the scope back to the value
> > stored on the stack.
> >
> > The stack can be a dedicated pad_stack, but it can also be the
> > user_stack. Maybe a dedicated stack is better because there are
> > dedicated ops for scope resolution.
>
> Actually, referencing the static scope as a multidimensional array might
> work as well:
>
> set P1, P0[2;"$foo"]
> set P0[-1;"$bar"], 23
Good idea.
[...]
bye
juergen
--
Juergen Boemmels [EMAIL PROTECTED]
Fachbereich Physik Tel: ++49-(0)631-205-2817
Universitaet Kaiserslautern Fax: ++49-(0)631-205-3906
PGP Key fingerprint = 9F 56 54 3D 45 C1 32 6F 23 F6 C7 2F 85 93 DD 47
