On Tue, May 28, 2002 at 08:30:52AM -0400, Mike Lambert wrote:
> Can you provide an implementation of the macros you described above? I
> have a few concerns which I'm not sure if they are addressed. For example:
#define PARROT_start() \
frame * saved_top = stack_top;
> PARROT_str_local(d)
> I'm assuming it puts a reference to d onto the rooted stack. It would also
> need to initialize d to NULL to avoid pointing at garbage buffers.
#define PARROT_str_local(d) \
STRING * d = NULL; \
frame frame_##d; \
int dummy_##d = ( \
(frame_##d.ptr = &d), \
(frame_##d.next = stack_top), \
(stack_top = &frame_##d), \
0);
> PARROT_str_params_3(a, b, c);
> What's the point of this? With rule 5 that prevents function call nesting,
> you're guaranteed of all your arguments being rooted. I think you can lose
> either the nesting requirement or the str_params requirement.
Yes, you are right: we don't need this macro if all the arguments are
already rooted.
> PARROT_return(e);
> I'm assuming this backs the stack up to the place pointed to by
> PARROT_start(), right?
Right:
#define PARROT_return(e) \
do { \
stack_top = saved_top; \
return e; \
} while (0); \
> This means during a longjmp, the stack won't be
> backed up properly until another PARROT_return() is called, somewhere
> farther up the chain, right?
Right, the stack has to be backed up explicitely. But the exception
handler can do it immediately.
> Finally, in response to my original post, you asked:
>
> > Suppose your C code builds a nested datastructure. For instance,
> > it creates some strings and add them to a hash-table. The hash-table is
> > then returned. Should it clear the neonate flag of the strings?
>
> I think I'd have to say...don't do that. Ops and functions shouldn't be
> building large data structures, imo. Stuff like buliding large hashes
> and/or arrays of data should be done in opcode, in perl code, or whatever
> language is operating on parrot.
Still, it seems reasonable for a function to return a small
datastructure, such as a pair of strings.
> If you *really* need to operate on a nested datastructure, and you're
> going to hold it against my proposal, then there are two options.
>
> a) write code like:
> base = newbasepmc #nenoate pmc
> other = newchildpmc #also neonate
> base->add(other) #even if collecting/dod'ing, can't collect above two
> done_with_pmc(other) #un-neonates it, since it's attached to a root (neonate0 set
> ....repeat...
>
> It works, and then you just need to worry about what to do with your
> 'base' at the end of the function (to un-neonate it or not).
This sounds reasonable.
-- Jerome
