Simon Cozens writes:
: On Fri, Aug 18, 2000 at 09:57:59AM -0700, Larry Wall wrote:
: > Because we don't lose much efficiency to polymorphism, since we need it
: > anyway to support generic scalars, and we gain some efficiency whenever
: > we procrastinate conversions out of existence.
: 
: Surely we do, because we have to add in something that says what
: representation we're in and, if we're going for a vtable design, how to
: transform it into anything else.

With vtables you add more code, but since the code is accessed in
parallel, you don't add any steps, so the only way polymorphism slows
you down is if it blows out your cache.

: I agree that procastinated conversions are the way to go; this actually brings
: up another interesting thought I had:
: 
: We can tell, for each evaluated block, from the optree which parts of each
: variable are going to be used in that run. This means we can, for instance,
: completely avoid using an SV if a variable is always treated as an NV no
: matter what. 
: 
: Does this buy us anything?

Certainly it can, at the expense of a slower compiler.  Any sort of
type inferencing can only help speed up the run time.  Type
inferencing works better the more real type info you feed it.
In particular, we will need a way to declare the return types of
subroutines.  (Optionally, of course!  Don't panic!  I'm not trying
to turn Perl into a strongly typed language--at least, not by default.)

But as long as we're feeding the compiler more type info, even if we
rule out fancy optimizations for load-and-go programs, we can stilll
say that

    my int $foo;
    my str $bar;

lets the compiler assume that the variable is restricted to integer or
string operations (and related conversions).  We could go farther than
that, and let the programmer request particular representions:

    my int $foo :bits(16);
    my str $bar :enc(utf8);

I don't know how far we want to push that for ordinary Perl programming,
but if we decide that Perl6 is the PI for Perl6, such specificity would
likely be required to produce efficient C/Java/C# code.  It might also
allow us to write the interfaces to external libraries in Perl.

Larry

Reply via email to