develooper Front page | perl.perl6.compiler | Postings from July 2005

Some thoughts on PIL

Thread Next
From:
Autrijus Tang
Date:
July 28, 2005 13:58
Subject:
Some thoughts on PIL
Message ID:
20050728205921.GA61292@aut.dyndns.org
On Thu, Jul 28, 2005 at 06:31:34PM +0200, "TSa (Thomas Sandla´┐Ż)" wrote:
> BTW, where can I read about PIL, other then in Parrot/Pugs svn?

(Cc'ing in P6C.)

The current type-indexed design of PIL is going away, because it is
closely tied to the PIR/Parrot model, to the disadvantage of our
Perl5/JavaScript backends.  Also it does not capture any notion of
rank-n types, and relies on the VM for a semantics for container types,
which is prone to trouble.

In the past few weeks I've been reading up on F<:, Fw, CoC, vObj, as
well as intersectional and split types for object calculi, in the
hope of revamping PIL -- Pugs's new internal language -- that can
alleviate backend author's pain and improve type-directed translation.

Perl 6's uniqueness is that it relies on runtime-rebindable package
objects for its type system, but at the same time carries the vague
promise of partial static analysis for the part of the closed world via
toplevel `use optimize`.  The semantic of type annotations remains
unresolved; I reflected this in the recent `the meaning of "returns"`
thread.

It would be far easier if we concede that Perl 6 is essentially untyped,
and all type annotations are merely storage hints, that will still
always require runtime coercion.  This coincide with Parrot's current
idea of never checking subroutine parameter's PMC types (except for
MMD), and always resolve method calls as late as possible, exactly as
Perl 5 did.

Under that view, the only use of type annotation at compile time is
speeding up property/method lookup for typed variables, so they can be
looked up by number instead of names, provided new fields always go
toward the end.  Other than that, they can only serve as runtime
assertions, leading to the curious effect that well-typed programs
can run slower than the unannotated counterpart.

However, my intuition is that a soft-typed system, with clearly defined
dynamic parts translated to runtime coerce and dependent types, that can
work exactly as Perl 5 did at first, but provide sensible inferencing
and compile-time diagnostics as you gradually provide annotations, is
really the way forward.

Under soft typing, Parrot's role would become a fast implementation for
the object space and primitives, but the soundness of large-scale
programs and the standard library will be provided by the compiler, not
the runtime.  This plays well with Pugs's -- not neccessarily Perl 6's --
goal of keeping the language retargettable.

This may not be popular view, as evidented by the relative lack of
research and real-world interest to bridge the gap of static/dynamic
languages, so it would take a while to come up with a suitable formal
treatment.  I'm currently trying to express this idea under the F<:
framework for the new PIL, and I'll keep p6c posted as it goes forward,
and cotinue to reflect design issues to p6l.

Thanks,
/Autrijus/


Thread Next


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About