pre-PATCH: functions in languages/scheme
Juergen Boemmels
chopped off. Ok here its again.
Hi,
I just got functions running in scheme.
It uses a pre-version of Sean O'Rourkes scratchpad.pmc. (Sean, I had to
reimplement some functions to get it compile, did I get them right?)
P31 always holds a scratchpad.pmc with the current environment. When a
function is called it is saved along with all the other used
registers. The environment of the function definition is set to P31,
and extended by one scope. The formal parameters of the function are
stored in this new scope. After the return of the function the old
scope is restored, along with the other old registers.
local variables are just a special form of function creation and
application.
The implementation of the function object is very simple: Its an Array
of 3 Elements: The environment at function definition, a jump target
and a (scheme-)list of the formal parameters. I hope it will be
possible to replace this by a Sub.pmc once it will be capable to store
the environment.
This patch supersedes #17109.
If you apply this patch don't forget to cvs add scratchpad.pmc and
defines.t
bye
juergen
Sean O'Rourke
> I just got functions running in scheme.
>
> It uses a pre-version of Sean O'Rourkes scratchpad.pmc. (Sean, I had to
> reimplement some functions to get it compile, did I get them right?)
Hopefully it will be easy to reconcile our different versions (and will
teach me not to send people partial patches ;). I'll look at this in the
next couple of days, and hopefully send you a full clean patch before
that.
> and a (scheme-)list of the formal parameters. I hope it will be
> possible to replace this by a Sub.pmc once it will be capable to store
> the environment.
I've done this in my local version, so let's see if it (or something like
it) will meet your needs here.
/s
Juergen Boemmels
"Jonathan Sillito" <sil...@cs.ubc.ca> writes:
[...]
> If I remember correctly Sean's patch did store the scratchpad with the
> Sub.pmc, except that I retreived it from the current context's pad_stack.
> Then when Sub.pmc was invoked it pushed the correct pad on the stack. I
> notice that you are using P31 instead of the pad_stack. I probably missed
> the discussion about this, but was the pad_stack approach not working? If
> you have the time would you mind explaining to me what in particular was not
> working?
The current pad_stack handling is very much tied to Sub.pmc. The only
way of getting the current scope is creation of a new sub; the only
way setting the current pad is invoking this sub.
But I didn't used Sub.pmc, partly because the lexical scope is not
working in CVS subs and i don't want to add yet another set of
prepatches, partly because I added the formal parameters to the
procedure object. So I think there are two possible ways out: adding
operations to core.ops (get_current_pad_p and new_pad_p) or rolling the
lexical pad on my own.
And there is a diffrence between define and set!, define creates a new
binding in the top lexical scope, ignoring every previous definition,
but set! changes the binding of a formerly defined variable. This 2
diffrent operations don't map very well on the store_lex_s_p
operation. I used the diffrent keyed access methods of Seans
Scratchpad.pmc for differentating this use cases:
define : P31[-1;S0]
set! : P31[S0]
bye
boe
--
Juergen Boemmels boem...@physik.uni-kl.de
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
Jonathan Sillito
> From: boem...@physik.uni-kl.de [mailto:boem...@physik.uni-kl.de]
>
> The current pad_stack handling is very much tied to Sub.pmc. The only
> way of getting the current scope is creation of a new sub; the only
> way setting the current pad is invoking this sub.
>
> But I didn't used Sub.pmc, partly because the lexical scope is not
> working in CVS subs and i don't want to add yet another set of
> prepatches, partly because I added the formal parameters to the
> procedure object. So I think there are two possible ways out: adding
> operations to core.ops (get_current_pad_p and new_pad_p) or rolling the
> lexical pad on my own.
>
It would be nice if parrot provided the lexical scope semantics scheme (and
other languages) needs rather than have each language implement their own. I
guess this would be Dan's call, but just as another suggestion, could the
lexical ops be limited to something like the following, plus keyed access to
the pad?
new Px, .ScratchPad
push_pad Px
peek_pad Px
pop_pad Px
(The find_lex and store_lex ops would be unnecessary, but could be kept of
course)
> And there is a diffrence between define and set!, define creates a new
> binding in the top lexical scope, ignoring every previous definition,
> but set! changes the binding of a formerly defined variable. This 2
> diffrent operations don't map very well on the store_lex_s_p
> operation. I used the diffrent keyed access methods of Seans
> Scratchpad.pmc for differentating this use cases:
> define : P31[-1;S0]
> set! : P31[S0]
>
Assuming Sean's patch (not my above suggestioned ops), would this implement
the correct semantics for scheme's (define a ...):
new_pad 1
new P0, .SchemeUndef
store_lex 1, "a", P0
# ...
pop_pad
and could (set! a 12) inside of the above define be:
new P0, .SchemeInteger
store_lex "a", P0 # looks back through nested pads
--
Jonathan Sillito
Dan Sugalski
>It would be nice if parrot provided the lexical scope semantics scheme (and
>other languages) needs rather than have each language implement their own. I
>guess this would be Dan's call, but just as another suggestion, could the
>lexical ops be limited to something like the following, plus keyed access to
>the pad?
Working on this. If everyone wants to hash out the sort of semantics
they're thinking about, we can probably get to closure reasonably
fast and get things designed and implemented quickly.
--
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
d...@sidhe.org have teddy bears and even
teddy bears get drunk
Juergen Boemmels
> It would be nice if parrot provided the lexical scope semantics scheme (and
> other languages) needs rather than have each language implement their own. I
> guess this would be Dan's call, but just as another suggestion, could the
> lexical ops be limited to something like the following, plus keyed access to
> the pad?
>
> new Px, .ScratchPad
> push_pad Px
> peek_pad Px
> pop_pad Px
>
> (The find_lex and store_lex ops would be unnecessary, but could be kept of
> course)
Yes these would definitly be enough. In principle this is exactly what
is my P31-hack does; the only difference is that the lexicals are
saved on their own stack instead of the user stack. But this is
definitly a good thing.
Maybe one more:
clone_pad Px
The semantics would be:
peek_pad Py
clone Px, Py
This is a quite common operation, and the intermediate Py-register
would not be necessary. But I will not push this very strong.
> > And there is a diffrence between define and set!, define creates a new
> > binding in the top lexical scope, ignoring every previous definition,
> > but set! changes the binding of a formerly defined variable. This 2
> > diffrent operations don't map very well on the store_lex_s_p
> > operation. I used the diffrent keyed access methods of Seans
> > Scratchpad.pmc for differentating this use cases:
> > define : P31[-1;S0]
> > set! : P31[S0]
> >
>
> Assuming Sean's patch (not my above suggestioned ops), would this implement
> the correct semantics for scheme's (define a ...):
>
> new_pad 1
> new P0, .SchemeUndef
> store_lex 1, "a", P0
> # ...
> pop_pad
>
> and could (set! a 12) inside of the above define be:
>
> new P0, .SchemeInteger
> store_lex "a", P0 # looks back through nested pads
Somehow it looks if these find_lex/store_lex operations are just a
mapping of the Scratchpad vtable to bytecode with the implicit first
argument current_pad.
find_lex P0, S0 => set P0, P31[S0]
store_lex I0, S0, P0 => set P31[I0;S0]
new_pad => save P31 || new P31, .Scratchpad
new P31, .Scratchpad push_pad P31
(Again this P31 crap, bad boemmels :-))
Some commonly used operations might be nice, but there needn't be the
complete vtable.
bye
b.
Juergen Boemmels
> Working on this. If everyone wants to hash out the sort of semantics
> they're thinking about, we can probably get to closure reasonably fast
> and get things designed and implemented quickly.
My scheme implementation is a working (a little bit hacky but
working) implementation of closures.
The following things are definitly needed:
* get_current_lexical_scope or peek_pad
* set_current_lexical_scope or push_pad/pop_pad
The following can be vtable operations on a Scratchpad PMC or
dedicated ops working on the current Scratchpad.
* clone
* increase of size (at least by 1)
* get keyed with STRING
* set keyed with STRING (for changing an already existing binding)
* set keyed with -1;STRING (for new definitions)
These to are needed to do lexical addressing
* get keyed with INTVAL;INTVAL
* set keyed with INTVAL;INTVAL
These may be nice but not needed for scheme
* get keyed with INTVAL (getting direct to the Hashes)
* set keyed with INTVAL;STRING
* new (create an empty Pad, sometimes at startup parrot must do
this)
* decrease of size
The Sub.pmc may do the following things (but it shouldn't be the only
way to do this)
- get the current scope at creation time and save it
- push the current scope and make the saved on current at invoke
time
- pop the current pad before return
hope that helps
Sean O'Rourke
> These may be nice but not needed for scheme
> * get keyed with INTVAL (getting direct to the Hashes)
> * set keyed with INTVAL;STRING
Both get(INTVAL;STRING) and set(INTVAL;STRING) are needed (or at least
useful) for accessing hidden lexicals in outer scopes (e.g. "$OUTER::x").
/s