The story so far:
On September 13 Jarkko professed a desire for
"a quotish context that would be otherwise like q() but with some minimal extra
typing
I could mark a scalar or an array to be expanded as in qq()." [1]
Seeing this as being especially useful for those of us creating command files on VMS
using
here-docs, I volunteered to write the RFC, and proposed that variables be tagged to be
interpolated
in any single-quotish context.
A couple of forms of tagging were proposed. The initial RFC proposed doubling C<$>
and C<@>
(i.e. C<$$scalar> and C<@@array>). Damian Conway suggested C<\I..\E> [2] which has a
very Perlish
feel to it, but Greg Linderman pointed out that C<\I..\E> could easily occur in text
containing Win32
filespecs, and added
"There just really isn't a character that works inside ' for adding additional
interpolation semantics." [3]
All in all, the general sentiment is that single quotish context should not change.
As Nat so
succinctly put it:
I personally do not want to see q() screwed with. [4]
As another approach, Greg also suggested that perhaps C<\D..\E> in double quote
context could
*disable* interpolation, effectively turning C<\D..\E> delimited blocks of text into
single
quote context. [3] While passing Jarkko's "minimal extra typing" requirement, this
still
requires one to be aware of and modify naturally occurring C<\E>s in the tagged text,
as Greg
points out. In addition, to me this seems to be a little bassackwards, no disrespect
intended. [5]
Nat Torkington and M-J Dominus suggested overloading strings operations [6] and the
use of a block
scoped pragma to change single quotish semantics [7], respectively. Jarkko also
suggested a pragma
"...to *really* tag variables lexically to be expanded within singlequotes. Or
for that matter,
*not* to be expanded within doublequotes." [8]
My own preference (and the one I should have suggested at the onset instead of trying
to wedge this
thing into q() context) is for another quote context, one which would be otherwise
like q() but with
some minimal extra typing... This has been suggested by more than one, although
sometimes with some
reluctance. But I believe it fits the bill and doesn't step on any current quote
context toes.
Let's call it qt(), for quote tagged. That and the means of tagging is open for
discussion, but at
least now we know some pitfalls. Working from previous suggestions:
<<$scalar>> # [6] Nat
$$scalar # [1] Jarkko
\I$scalar\E # [2] Damian
TeXies may prefer \I{$scalar}, and the hybrid \I<$scalar> doesn't seem bad. I don't
particularly care
and it may be that there's this perfectly obvious solution that only Larry can see and
we really shouldn't
dicker around too much on this point.
However, this doesn't address here-docs. q(..) and qq(..) are not the same as '..'
and ".." when it
comes to here-docs.
print <<'END'; print <<q(END);
abc abc
END END
The second results in C<Can't find string terminator "q" anywhere before EOF at - line
1.>. I'm not
overly surprised given the special nature of here-docs, but I see nothing wrong with
allowing
print <<q(END) to mean print <<'END' , and
print <<qq(END) to mean print <<"END"
. And once the foot's in the door,
print <<qt(END)
follows.
Time is getting short so I don't really expect any resolution before Oct. 1, although
if this seems at least
reasonably acceptable I can get another RFC out on the <<q(END) == <<'END' proposal
pretty quickly.
Brad
[1] http://www.mail-archive.com/perl6-language@perl.org/msg03888.html
[2] http://www.mail-archive.com/perl6-language@perl.org/msg03970.html
[3] http://www.mail-archive.com/perl6-language@perl.org/msg03983.html
[4] http://www.mail-archive.com/perl6-language@perl.org/msg04018.html
[5] The perl6 lists had started to become as annoyingly uncivil as p5p
has been. I only just decided to come back and see this through.
[6] http://www.mail-archive.com/perl6-language@perl.org/msg03982.html
[7] http://www.mail-archive.com/perl6-language@perl.org/msg03965.html
[8] http://www.mail-archive.com/perl6-language@perl.org/msg03962.html
