On Friday 09 November 2001 03:36 pm, Dan Sugalski wrote: > > Do we want non-PMC lexical support? > > Nope, I wasn't going to bother. All variables are PMCs. The int/string/num > things are for internal speed hacks.
But can't a compiler generate one of these "internal hacks"? My thoughts are that a given scope can not return internal representations (like int's / string's), and must encapsulate them inside scalars, BUT the compiler may optimize the inside of a scope. If no evals occur inside the block (rather common), then the lexicals aren't volitile. If no divides are ever performed on a scalar, nor are they stringified, then the compiler might be able to assume that they're raw integers (whether they were declared "my $foo as int" or not). This also assumes that the would-be-integer does not interact with any other scalars. I believe there are op-codes that assign the value of primatives into a scalar (would have to), so scalars and primatives can still interact. Since this is an optimization, I agree that it's usefulness is limited. From the above, the only uses I can see for declaring "my $foo as int" is to set flags (or utilize different vtables) to enforce integerness, and to say to the optimizer that it's ok to use a primitive integer if the block contained a divide. Note that: $foo = int( $bar / $baz) should have the same effect. End result is that this is a problem that can be put off. -Michael
