Re: Re: Re: resizablepmcarray, assign.
Bob Rogers <[EMAIL PROTECTED]> wrote: FWIW, the Common Lisp system I'm writing takes a third tack. It defines a ParrotObject container associated with the name that refers indirectly to the current value. Of course, Common Lisp "symbol" objects are part of the language spec (and aliasing is not), so I have to at least make it look like I'm doing it this way. But indirection still seems more natural than morphing -- I don't have to worry about whether morphing will produce unintended side-effects. And the best thing is that I can do it all in PIR and Lisp. So when I said "using PMCs as values rather than as containers," I really meant to suggest separating the container from the value. But I have no clue whether this would be easier than the other options. Okay, that makes much more sense. It's not ideal, especially for Tcl, but it does work. Technically, any time we use something other than a TclString PMC it's an optimization. After looking at the code in the Array, Scalar, and String PMCs, I've managed to get things working to my satisfaction using an iterate-and-copy method for array-like objects and morphing for Strings (and soon for other types as well). So if anyone ever finds himself or herself in the same position, a look at TclList's (languages/tcl/src/pmc/tcllist.pmc) assign_pmc method would probably be in order. -- Matt Diephouse http://matt.diephouse.com
Re: Re: resizablepmcarray, assign.
From: "Matt Diephouse" <[EMAIL PROTECTED]> Date: Sat, 5 Aug 2006 01:22:49 -0400 Bob Rogers <[EMAIL PROTECTED]> wrote: > > This tweak may break other stuff (I didn't check), so take it with a > grain of salt. However, this may be a hint that you are better off > using PMCs as values rather than as containers. HTH, Right. So what you did was change Tcl so that we no longer use the assign opcode. This fixes this error, but causes a handful of other ones. I'm not surprised. AFAICT, we have to use assign so that we don't break aliasing (which is rather important). If you have the same variable in two different scopes -- or under two different names -- merely replacing one of those variables with a new PMC (using PMCs as values) won't change the other variable. You have to use assign to morph the PMC into the new type. Among other things, this will break Tcl's [global] and [variable] commands and it isn't really a viable solution. PMCs *are* containers; they're designed that way. Not necessarily . . . This leaves two options: 1) Fixing the set_pmc vtable method for TclList and/or ResizablePMCArray and FixedPMCArray 2) Using a hybrid list/string PMC that behaves in a similar way to Perl 5's scalars Option 1 is preferable, IMO, if it's doable. But it's a little out of my reach as far as C goes, unfortunately. Otherwise I'd have fixed it already. :-) FWIW, the Common Lisp system I'm writing takes a third tack. It defines a ParrotObject container associated with the name that refers indirectly to the current value. Of course, Common Lisp "symbol" objects are part of the language spec (and aliasing is not), so I have to at least make it look like I'm doing it this way. But indirection still seems more natural than morphing -- I don't have to worry about whether morphing will produce unintended side-effects. And the best thing is that I can do it all in PIR and Lisp. So when I said "using PMCs as values rather than as containers," I really meant to suggest separating the container from the value. But I have no clue whether this would be easier than the other options. Thanks for taking a look at this. No problem; thanks for giving me an excuse to take a look at how Tcl works. -- Bob
Re: Re: resizablepmcarray, assign.
Bob Rogers <[EMAIL PROTECTED]> wrote: I finally found the definition of __set (my tagfile-building recipe was deficient), and, on a hunch, made the tweak shown below, with the following result: [EMAIL PROTECTED]> ../../parrot tcl.pbc -e 'set a [list a b]; set x $a; set a b; puts $a; puts $x' b a b [EMAIL PROTECTED]> This tweak may break other stuff (I didn't check), so take it with a grain of salt. However, this may be a hint that you are better off using PMCs as values rather than as containers. HTH, Right. So what you did was change Tcl so that we no longer use the assign opcode. This fixes this error, but causes a handful of other ones. AFAICT, we have to use assign so that we don't break aliasing (which is rather important). If you have the same variable in two different scopes -- or under two different names -- merely replacing one of those variables with a new PMC (using PMCs as values) won't change the other variable. You have to use assign to morph the PMC into the new type. Among other things, this will break Tcl's [global] and [variable] commands and it isn't really a viable solution. PMCs *are* containers; they're designed that way. This leaves two options: 1) Fixing the set_pmc vtable method for TclList and/or ResizablePMCArray and FixedPMCArray 2) Using a hybrid list/string PMC that behaves in a similar way to Perl 5's scalars Option 1 is preferable, IMO, if it's doable. But it's a little out of my reach as far as C goes, unfortunately. Otherwise I'd have fixed it already. :-) Thanks for taking a look at this. -- Matt Diephouse http://matt.diephouse.com
