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

Reply via email to