The purpose of my project is to detect type-unsafe Perl 5. It's implemented
with Malcom Beattie's compiler back-end. Naturally, my type inference
cannot be sound due to the inherent ambiguities of Perl and things like
'eval "string";', but I think it's enough for many purposes.
Right now I'm using a simplified model of the Perl 5 type system. I don't
really address CV, FORMAT, and IO types right now (although I will have to
do so for interprocedural analysis). Also, I ignore the differences between
most of the SV types -- I really only keep track of strings, references,
integers, and doubles.
As far as I know, union types are inefficient to the point of being
impractical. For the purposes of this tool, I've taken an intermediate step
by modeling the type system as a structural type, and I allow type variables
to be introduced in specific places to model type ambiguity. For instance,
if the type of some expression is an undistinguished scalar, I would model
that by specifying the type up to scalar and put a variable type as the
child. This is not as flexible as true union types, but it gets the job
done (for the most part). Hopefully that will be sufficient for what you'd
like to accomplish.
Andy Lester (my SoC mentor) and I are going to try and get a release at some
point this week. This will probably be the version that doesn't do
aggregate data types, since I'm still struggling with that (I'm way past my
deadline for that, but I'll get it done before the deadline). We probably
need to talk more to see how this fits in with what you're doing. I don't
know anything about Perl6, so I'm not sure how my project can be useful.
However, I am excited to contribute to it in some way.
I wrote a paper for the graded project last spring. It talks more about the
formalism that I've been using, among other things. I don't want to spam
the list with the PDF file. However, if someone wants it, let me know
off-list and I will send it to you.
--
Gary Jackson
[EMAIL PROTECTED]
> -----Original Message-----
> From: Autrijus Tang [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, August 16, 2005 9:19 AM
> To: Perl6 Language List
> Cc: Gary Jackson
> Subject: Type inferencing for Perl5
>
> On Tue, Aug 16, 2005 at 02:04:41PM +0100, Nicholas Clark wrote:
> > On Thu, Aug 11, 2005 at 01:35:14AM +0800, Autrijus Tang wrote:
> > > On Wed, Aug 10, 2005 at 07:32:01PM +0200, TSa wrote:
> > > > Counting the sigil quadriga as 4, what is the fifth element?
> > > & @ $ % ::
> > > In Perl5, :: is replaced by *.
> >
> > Strictly in Perl 5 there are 7 types
> > SCALAR, ARRAY, HASH, CODE, GLOB, FORMAT and IO.
> >
> > (where IO might actually be 2 types, file handles and directory
> > handles, and in turn FORMAT is implemented as a subtype of CODE.
> >
> > Also, internally there are 16 variants of SV*, with mostly a 1 to 1
> > mapping for all the types except SCALAR, which sort of absorbs the
> > other 10. Except that the null SV type is easily directly
> morphable into any of the others.
>
> It would be great if we can use a type-directed transform
> from Perl 5 syntax tree into PIL/Perl6, i.e. annotate each
> term with the 16 variants, maybe with union/intersection
> types that represents ambiguous context, such as:
>
> f(reverse(g()));
>
> Hm, I seem to remember that Gary Jackson (cc'ed) is working
> on that, as his Summer of Code project. Gary, can you share
> with us how you plan to approach that, and/or how to get
> involved to your project?
>
> Thanks,
> /Autrijus/
>
