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
