[pugs] Quoting constructs
Roie Marianer
I'm new here, just downloaded pugs the other day. I noticed only q//, qq// and
qw// were implemented of the quoting constructs, so I tried my hand at
implementing most of the quoting constructs as specified in S6.
It's not the best code in the world (and I think I broke qw// on the way), but
if anyone wants the patch (5k in 125 lines) I'd be more than happy to share.
-Roie
pugs> $a
1
pugs> @a
(1, 2)
pugs> %a
{'1' => 'one', '2' => 'two'}
pugs> "$a; @a[]\n %a{}"
'1; 1 2
1 one
2 two
'
pugs> qa"$a; @a[]\n %a{}"
'$a; 1 2\\n %a{}'
pugs> qa:b"$a; @a[]\n %a{}"
'$a; 1 2
%a{}'
pugs> qa:b "$a; @a[]\n %a{}"
'$a; 1 2
%a{}'
pugs> qa:b 7$a; @a[]\n %a{}7
'$a; 1 2
%a{}'
pugs> qa:s ($a; @a[]\n %a{})
'1; 1 2\\n %a{}'
Stevan Little
On Apr 11, 2005, at 2:17 PM, Roie Marianer wrote:
> Hi all.
>
> I'm new here, just downloaded pugs the other day. I noticed only q//,
> qq// and
> qw// were implemented of the quoting constructs, so I tried my hand at
> implementing most of the quoting constructs as specified in S6.
Excellent.
> It's not the best code in the world (and I think I broke qw// on the
> way), but
> if anyone wants the patch (5k in 125 lines) I'd be more than happy to
> share.
I would rather give you commit rights (we give them out quite
liberally) and you could apply it yourself actually. But you should
first test your patch against the latest SVN revision since many many
many things have changed the past few days.
- Stevan
Roie Marianer
> I would rather give you commit rights (we give them out quite
> liberally) and you could apply it yourself actually. But you should
> first test your patch against the latest SVN revision since many many
> many things have changed the past few days.
installing Subversion and making the patch better.
As far as I can see, my patch applies cleanly to latest SVN and passes all the
tests I could run, including the one I wrote for this. For some reason "make
test" gets stuck on t/examples/examples; I deleted it so I could move on.
This happens with SVN too, so it's probably not the fault of my patch. I
hope. (Anyone know why t/examples/examples won't work for me?)
I did hit a snag with %hash<key> and :key<value> notation for hashes and
pairs; I'm not sure how to make them interpolate, so for now they just don't.
As it stands, I think it's committable. Are you sure you want to give commit
rights to a complete stranger? I thought you'd at least want to see what I
did, but it's your project and your rules. :-)
--
-Roie
v2sw6+7CPhw5ln5pr4/6$ck2ma8+9u7/8LSw2l6Fi2e2+8t4TNDSb8/4Aen4+7g5Za22p7/8
[ http://www.hackerkey.com ]
Roie Marianer
> Do you mean the behavior of
>
> "%hash<key>" ":key<value>"
>
> or
>
> %hash< a $key_b c > :key< a $value_b c >
>
Thanks. I meant the latter (I got the former right), and that's what I
thought. I'm still not sure exactly how to get it to work, I'll look at it
tomorrow.
> %hash<< a $key_b c >> :key<< a $value_b c >>
> %hash« a $key_b c » :key« a $value_b c »
Just to be certain, these are both equivalent to
@hash{'a', $key_b, 'c'} key => ['a', $value_b, 'c']
in Perl 5, right?
Larry Wall
: I did hit a snag with %hash<key> and :key<value> notation for hashes and
Do you mean the behavior of
"%hash<key>" ":key<value>"
or
%hash< a $key_b c > :key< a $value_b c >
If you mean the former, only %hash<key> interpolates, since : is not
a metacharacter in strings.
If you mean the latter, neither interpolates, since you'd use one of
%hash<< a $key_b c >> :key<< a $value_b c >>
%hash« a $key_b c » :key« a $value_b c »
for interpolated qw-ish constant slices/values.
Larry
Larry Wall
: > %hash<< a $key_b c >> :key<< a $value_b c >>
: > %hash« a $key_b c » :key« a $value_b c »
: Just to be certain, these are both equivalent to
:
: @hash{'a', $key_b, 'c'} key => ['a', $value_b, 'c']
:
: in Perl 5, right?
Close. It's actually more like:
@hash{split " ", "a $key_b c"} key => [split " ", "a $value_b c"]
That is, the interpolation happens before the implicit split. That's
why
<< $str >>
« $str »
are equivalent to P5's split(" ", $str). And
« @lines »
will interpolate all the lines and then split the whole mess on words.
Larry
Autrijus Tang
> > I would rather give you commit rights (we give them out quite
> > liberally) and you could apply it yourself actually. But you should
> > first test your patch against the latest SVN revision since many many
> > many things have changed the past few days.
> Sorry for the long delay in responding. I was busy with work, life, and also
> installing Subversion and making the patch better.
That's wonderful. If you manage to find some more tuits, please feel
free to drop by #perl6 on irc.freenode.net...
> As it stands, I think it's committable. Are you sure you want to give commit
> rights to a complete stranger? I thought you'd at least want to see what I
> did, but it's your project and your rules. :-)
Hey, we have a version control system, a comprehensive test coverage,
and good discussion channels, I think we can afford anarchism. :-)
Invitation sent, please commit away. Welcome aboard!
Thanks,
/Autrijus/
Roie Marianer
> On Fri, Apr 15, 2005 at 03:27:27AM +0300, Roie Marianer wrote:
> : > %hash<< a $key_b c >> :key<< a $value_b c >>
> : > %hash« a $key_b c » :key« a $value_b c »
> :
> : Just to be certain, these are both equivalent to
> :
> : @hash{'a', $key_b, 'c'} key => ['a', $value_b, 'c']
> :
> : in Perl 5, right?
>
> Close. It's actually more like:
>
> @hash{split " ", "a $key_b c"} key => [split " ", "a $value_b c"]
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.
Several only-slightly-related questions about interpolating:
1. qq x$varx eq $var? (That's how it works in Perl5, anyway)
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)
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.)
My head hurts. :-)
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?
Steven Philip Schubiger
: 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?
You most likely want perl6-language, where Larry among others
participates in.
Steven
Patrick R. Michaud
>
> 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?
perl6-compiler is fine for discussing corner cases and asking for
or verifying an interpretation/clarification of them. If it turns
out that there are multiple competing interpretations available and
some disagreement about which one should be correct, then perl6-language
is (or becomes) the better location for the discussion.
Pm
Larry Wall
: $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