Currently PAST-pm checks the PAST::Val node's "ctype"
attribute to decide whether to encode the literal value
as a Parrot form -- if the node doesn't have ctype that indicates
"string constant", then PAST-pm just uses the literal value
directly in the output.

So, just don't set "ctype", and whatever the node has as
its "name" attribute will go directly into the PIR output.

Here's an example:

    $ cat x.pir
    .sub main :main
        load_bytecode 'PAST-pm.pbc'
        .local pmc valnode, blocknode, pir

        ##  $S0 is the string we want to appear in the output
        $S0 = '"\n"'
        valnode = new 'PAST::Val'
        valnode.'init'('vtype'=>'.String', 'name'=>$S0)
        blocknode = valnode.'new'('PAST::Block', valnode, 'name'=>'anon')

        ##  compile the tree to PIR and print the result
        $P99 = compreg 'PAST'
        pir = $P99.'compile'(blocknode, 'target'=>'pir')
        print pir
    .end

    $ ./parrot x.pir

    .sub "anon"
        new $P10, .String
        assign $P10, "\n"
        .return ($P10)
    .end

Eventually the handling of "ctype" is going to change -- first,
the name will change to be more descriptive (but I'll leave a 'ctype'
accessor in place to give compilers time to switch); second, any
ctype specifications will be held in a HLL class mapping table
instead of in each PAST::Val node.

There is a good chance that PAST-pm will treat PAST::Val nodes
of type .String as needing their values to be encoded for Parrot,
but to protect against this punie (and other compilers) can
use .Undef:

        $S0 = '"\n"'
        valnode = new 'PAST::Val'
        valnode.'init'('vtype'=>'.Undef', 'name'=>$S0)

Since the node isn't a string type, PAST-pm will use the "name"
$S0 value directly in the output PIR without performing any
encoding on the literal value, and the generated PIR from the node
would look like

        new $P10, .Undef
        assign $P10, "\n"

And this does exactly what you want.  :-)

Pm