On Sat, Apr 16, 2005 at 03:14:50AM +0300, Roie Marianer wrote: : I actually knew that, but in my head $key_b and $value_b were single words. : But according to S02, the interpolation is protected by quotes. That is, if : $key_b is q0/printf "Hello, world\n" or die"/, that's four words, correct? Or : is it just if the quotes actually appear in the quoting construct? Basically : I'm wondering if there's a detailed specification of how <<>> should work.
That's a really good question, and since I don't offhand know the right answer, I'll put this up onto the fence so it can topple over into p6l-land where there are many king's horses and many king's men, and the question is who's to be master, that's all. My feeling is that we want to allow both kinds of quoting, one to protect against interpolation, and one to protect against splitting, but not allow levels to be mixed. That is, the outer quotes will cause any interpolation inside them to be treated as a "word" string without any consideration of any of the characters inside, even if they happen to be spaces or quote characters. The outer quotes must therefore nest correctly without considering whether there might be inner quotes of the same sort. So we distinguish quoted interpolation from unquoted, and for unquoted interpolation, we look for inner quotes after interpolation and treat them as protection against splitting just as if they'd been outer quotes. I think that works, and won't be terribly surprising to shell programmers, but it still needs some caffeinated thinking. It's not at all clear to me at this point whether we should allow the q forms of quoting on either/both levels, or stick with shell-ish quotes. I can argue that one multiple ways. : Several only-slightly-related questions about interpolating: : : 1. qq x$varx eq $var? (That's how it works in Perl5, anyway) I think I'd prefer that we disallow alphanumeric delims in P6. (But if we did allow them, it would consider the second x to be part of the variable name, since we're looking for the final delimiter only when we're not scanning an internal token, or nested construct.) : 2. If the delimiter is not a single character (I think this only applies to : <<>>), does a backslash protect the first character or both? For example, in : <<some words \>>> or die : Is that three words ['some', 'words', '>'] with the >> ending the construct, : or is that ['some', 'words', '>>>', 'or', 'die']? (and the rest of the file : is interpolated and split into words) I would look at it from the other direction. When used as a quote rather than a meta-syntax starter, backslash only ever quotes a single character, never a token. However, the fact that the final delimiter has to be >> means that if you backwhack the first one, it is not available for token comparison, so the second one can only be the first > of a >> pair, and if the next character happens not to be >, both of your >> become part of the string, so it looks as if the backslash protected both of them. However, \>>> terminates with a final > as part of the string. : 3. Are <<>>-style delimiters allowed in other quoting constructs? Is : q<<Hello>> the string "Hello", or the string "<Hello" followed by the : greater-than sign? (As you can probably tell, I haven't implemented <<>> yet : at all.) I think in general only single characters may be used for pick-your-own quotes, but if we make any exception, <<...>> would be it, on the grounds that some would-be Texan might translate all «...» to <<...>> and then wonder why things break. But I always try to have six breakfasts before I believe anything impossible. As long as this is going over the fence to p6l, we might as well solicit opinion on this one as well, maybe with a different subject. : My head hurts. :-) Eventually the endorphins kick in, and it wraps around to the other end. :-) : By the way, something tells me perl6-compiler isn't the best place for this : discussion. Is there a secret group of people that discusses cornercases for : perl6, and if so could someone tell me on what list they live? As Patrick said, we ain't picky, as long as everyone remains sensitive to the fact that long-running speculative threads do p6c little good, and p6l little harm. Larry
