Stability of PCT, PGE, NQP, PIR for HLL development

Andrew Whitworth wknight8111 at gmail.com
Mon Jan 24 13:42:46 UTC 2011


These are all great questions, let me do my best to answer them.


> I
> have a few of questions, which either have conflicting answers in
> existing documentation, or are not addressed anywhere.

Some of our documentation has fallen behind. If you tell me where you
were looking and what conflicting information you were seeing I will
do my best to ensure it gets updated.

> 1. How stable are PCT, PGE and NQP? (Or is it just NQP nowadays?) In
> other words, if I start writing an HLL implementation today for Parrot
> 3.0.0, will the implementation still work on Parrot 4.0?

NQP tends to be very stable. It's well tested, and is [supposed to be]
included in testing by Parrot developers before making large changes.
Even if it does break momentarily, it's fixed quickly and a stable
version of it always ships with Parrot releases. NQP serves as
something of an abstraction layer over PIR, so even if PIR changes
pretty dramatically, NQP will be made to work with it and your NQP
code should continue to work with each new Parrot release.

> 2. How stable is PIR? I would definitely want to write the parser and
> grammar actions in NQP, but based on existing implementations (Rakudo in
> particular), it doesn't seem possible to write a full compiler with just
> NQP; you have to embed some PIR code. And there is an ongoing effort to
> change the target bytecode of the PIR compiler, which (I expect) will
> have ramifications in PIR itself.

This is a more difficult question to answer. PIR represents the lowest
possible level of interaction with libparrot, so changes to libparrot
occasionally necessitate changes to PIR syntax or semantics. Also,
we're in the process of attempting to replace the current PIR compiler
(IMCC) with a new version (PIRATE), and that switchover may cause
certain bits of syntax to change.

That said, PIR is subject to Parrot's deprecation policy. Nothing in
it will change without first putting in a deprecation notice (which
should include instructions for upgrade) and waiting for the next
stable release (3.3 in April).

In general, I would suggest that you do not use PIR directly for most
of your development. It will be easier on you to use a higher-level
language, and your code will be more stable and portable across
releases of Parrot.

I hope this helps you out. What kind of language are you thinking
about implementing?

--Andrew Whitworth


More information about the parrot-dev mailing list