Lexicals

[Juergen Boemmels]

Hi,

I have several questions regarding lexicals.

There is a discrepancy between parrot_assembly.pod and core.ops
parrot_assembly.pod says that find_lex will return a pointer, where as
core.ops uses find_lex to retrive a value and store_lex to set this
value. Which of this is correct?

parrot_assembly mentions a fetch_lex_p_i_i but there is no
implementation yet. This functions would be very handy when you know
at compile time whats in the lexical scope. Is this left-out
intentional or just because nobody has yet implemented it. In the
later case, is somebody already working on this?

How are the integers of the lexicals in the pad assigned? I assume
they get increasing numbers for each store_lex, starting at 0 for a
new pad. Correct?

How do I store to a lexical by number? Shouldn't be there also a
store_lex_i_i_p (or set_lex to indicate that it is a change of an
already existing binding).

Is there a possibility to get a pointer to the current pad, to store
it in the closure? (Im not sure, maybe only the top-pad is needed).
There need also be a way to reinstate the saved lexical.

So I think that are enough questions.
juergen
--
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]

I am not the best one to answer these questions, but I will
make some comments anyway, though Dan is/was planning to give
us an authoritative position doc on some of these issues.

I have done some work on some of this, but my latest code
submission has not been accepted yet.

On 9 Sep 2002, Juergen Boemmels wrote:

> I have several questions regarding lexicals.
>
> There is a discrepancy between parrot_assembly.pod and core.ops
> parrot_assembly.pod says that find_lex will return a pointer, where as
> core.ops uses find_lex to retrive a value and store_lex to set this
> value. Which of this is correct?
>

I would think it will become pointers.

> parrot_assembly mentions a fetch_lex_p_i_i but there is no
> implementation yet. This functions would be very handy when you know
> at compile time whats in the lexical scope. Is this left-out
> intentional or just because nobody has yet implemented it. In the
> later case, is somebody already working on this?
>

This is still the plan and I believe that "by index" is going to
be the fastest way to access lexicals. I have been thinking about
implementing something for this but I am waiting to see if my
previous patch gets committed so I can be sure I am heading in a
reasonable direction. On the other hand maybe I should just press
forward?

> How are the integers of the lexicals in the pad assigned? I assume
> they get increasing numbers for each store_lex, starting at 0 for a
> new pad. Correct?
>
> How do I store to a lexical by number? Shouldn't be there also a
> store_lex_i_i_p (or set_lex to indicate that it is a change of an
> already existing binding).

Dan has hinted that there will be some way, in parrot assembly,
to provide a static pad descriptor that could be used to put all
lexicals in place when the pad is first created.

> Is there a possibility to get a pointer to the current pad, to store
> it in the closure? (Im not sure, maybe only the top-pad is needed).
> There need also be a way to reinstate the saved lexical.

I have submitted code that does this sort of thing for
subroutines.

--
Jonathan Sillito