At 02:13 PM 7/10/2002 -0700, John Porter wrote:
>Dan Sugalski wrote:
> > John Porter wrote:
> > > but what about non-PMC variables?
> >
> > Generally speaking, there aren't any. Everything else (in this case
> > the buffer/string things) is for internal use only. Languages aren't
> > supposed to expose strings directly.
>
>Languages are only supposed to expose PMCs?
>Not ints, nums, strs?
>Why have them if Perl can't see them?
Since Perl vars type-morph themselves, Perl will use PMC types everywhere
that there is an exposed interface. Internally you could use an I/S/N register.
I see no reason why
foreach my $i (@nums) {
...
}
should not use an Ix reg for $i, but maybe $i isn't an int at all, or @nums
is actually a mixed list. Even if we did know that @nums was all integers,
as soon as we see:
%MY{'$i'}, or we find an eval{}, $i must escape the register and we lose
the optimization.
Its almost as if the only optimization will be for
foreach my $i (1...10000)
where we know the type ahead of time.
We've built this register based VM upon which Perl will probably be
the most non-optimized language. Things like exposing your lexical pads,
eval, etc. blow optimization out of the water.
A language like Java/C# will run much faster on Parrot than Perl6,
however, this doesn't worry me, since Perl itself will probably still
get 5-10x speedup even with its use of PMCs everywhere.
-Melvin
