Re: Tying sub arguments is rare?

Chip Salzenberg writes:
> I think we have to continue allowing simple value modification.  Even
> transmogrification is no issue, because it's simply an implementation
> technique limited to a  of the type tree (PoolScalars), and thus
> irrelevant to classes that fall outside that subtree.

So the following works:

  my $x = 1;
  foo($x);

  sub foo {
      $_[0] = "blah";
  }

$x starts out life as a ThinIntegerScalar and then transmogrifies
into a ThinStringScalar -- which is no problem because that's supported
for all objects derived from PoolScalar. Cool. One thing that occurs
to me though is that this is a "yank-the-rug-from-under-the-compiler"
sort of thing so some compiler optimizations (like caching vtbl
pointers) might break things.

The problem case is when a PoolScalar must transmogrify to a non-Pool
Scalar. (But Topaz doesn't have any non-PoolScalars yet... ;) One
possible solution is to have transmogrify() generate a forwarding
object if the new object is larger than the old one. (Don't lisp
systems with copying garbage collectors call these broken hearts?)

A forwarding system might be useful for moving things like FatScalar
out of the PoolScalar hierarchy too. A forwarding object should only
be a few bytes larger than the xguts pointer in FatScalar (and the
forwarding object will eventually be GC'd).

BTW, why are ThinScalars so big? ThinIntegerScalar is 32 bytes on
my machine (Sun Ultra-60 w/ gcc 2.95). Is this common? FatScalar by
comparison is only 24 bytes.

- Ken

-- 
Ken Fox, [email protected], (313)59-44794
------------------------------------------------------------------------
Ford Motor Company, Powertrain           | "Is this some sort of trick
Analytical Powertrain Methods Department |  question or what?" -- Calvin
C3P Implementation Section               |