On Wed, 10 Jul 2002, Melvin Smith wrote:
> 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.
So we don't see them. %MY is so ugly nobody will want to use it. And as
for eval{}, that's actually eval "". try{} will not pose a problem. Keep
in mind that eval "" isn't that common either. Also if you're compiling
some code every iteration, an integer optimization won't help out that
much.
And we do know whether @nums are all integers, if people program well.
Arrays can be typed, too.
> Its almost as if the only optimization will be for
>
> foreach my $i (1...10000)
>
> where we know the type ahead of time.
>
Luke
