Patrick R. Michaud wrote:
>  
>  PAST-pm expects it to be pretty rare that a HLL's string literal
>  format will exactly match what works as a string literal in PIR, so 
>  PAST::Val nodes expect the HLL to have already decoded the string
>  constant according to whatever rules the HLL uses.  Then PAST-pm
>  can re-encode the string into a form that is guaranteed to work
>  in Parrot (even handling things such as placing "unicode:" in
>  front of PIR string literals if the string has characters that
>  fall outside of the ASCII range.)

Agreed that this is a good general solution.

>  I can modify PAST-pm to provide a "send exactly this string to PIR" 
>  option for PAST::Val.  

Yes, good idea for the simple case.

>  More generally useful would seem to be to 
>  provide a generic function or opcode that can decode single/double 
>  quoted strings according to PIR's encoding rules, and then use
>  that to get the string into PAST::Val.

That's a lot of extra work when all you need is for the string to pass 
through to PIR exactly as it was parsed. So I'd skip this one.

>  I think that the various languages have enough differences in
>  string literal handling that each compiler will end up writing 
>  its own string literal decoder.  (Or we need a semi-powerful library
>  to handle the many differences.)  In the meantime having an 
>  easy-to-access subrule for "just pretend it's a quoted literal 
>  according to PIR conventions" might be a good way for someone
>  wanting to bootstrap a compiler, without placing Parrot-specific
>  encodings into PAST-pm.

Ultimately we will want some general tools to assist compiler writers 
with string handling. It really shouldn't be any more difficult than 
writing the general grammar rules or operator precedence rules. Since 
special string handling is something Perl 6 users are likely to need too 
(pretty much all templating is customized string interpolation), it's 
worth punting this to p6l to see if they come up with a nice interface.

In the mean time, a string decoder rule written in PIR is good enough.

>  Lastly, I'm still working out the handling of HLL to Parrot
>  type mappings -- it's also possible that some of this will
>  fall out as a result of that.

Makes sense.

Allison