[DEPRECATED] PIR compiler availability

[plobsing]

PIR as a language is currently always available in parrot. This privileged status is part of why PIR is a growing pain for Parrot (usually experienced as hatred for IMCC).

PIR will become no different to parrot than any language. It will not be baked-in to libparrot and be always available. In stead, PIR will become a separately loadable component.

PIR will remain available to Parrot programs, however it will require loading before use (via the load_language instruction).

A separate executable (tentatively named "parrot-imcc") will be made available for compiling and running PIR programs as the main parrot executable does today.

[chromatic]

On Tuesday 23 November 2010 at 14:05, Parrot  wrote:

> To get the PIR compiler, a load_language "PIR" instruction should be issued 
> first.

How do you run a .pir file with ./parrot in such a case?  (If the first 
instruction of the PIR file must be the PIR instruction load_language, how does 
Parrot know to use the PIR compiler to parse that first instruction?)

-- c

[NotFound]

Note that currently load_bytecode can look for .pir file, either directly or when a .pbc is not found, and compile it. It may be convenient to change that behavior in advance to avoid surprises and simplify the final deprecation.

[bacek]

-1 to deprecate PIR. +1 to split libparrot, parrot executable (which can handle PBC only) and parrot-pir (as PIR compiler).

-- Bacek

[jimmy]

Replying to bacek:

-1 to deprecate PIR. +1 to split libparrot, parrot executable (which can handle PBC only) and parrot-pir (as PIR compiler). -- Bacek

+1

[plobsing]

converted from RFC to deprecation

[jkeenan]

whiteknight,

What exactly are we deprecating here? Do we have a plan of action? Would we be better off if we reduced the scope of issues discussed in this ticket and opened new TTs only for those things which really do need deprecation?

Thank you very much.

kid51