Re: RFC 226 (v2) Selective interpolation in single quotish context.
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\Es 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);
abcabc
ENDEND
The second results in CCan'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
Re: RFC 226 (v2) Selective interpolation in single quotish context.
On 15 Sep 2000, at 11:25, Steve Fink wrote: Does it strike anyone else as odd that 'foo\\bar' eq 'foo\bar'? While 'foo\\' ne 'foo\' :-) (specifically, the former is not a syntax error :-) Cheers, Philip
Re: RFC 226 (v2) Selective interpolation in single quotish context.
On 15 Sep 2000, at 1:10, Perl6 RFC Librarian wrote:
With this proposal, the scalar C$filename can be tagged to be interpolated
by the C\I...\E pair and the double quotish context replaced by single
quotish context resulting in the following:
Definitely with this change, you should include a section on
COMPATIBILITY, noting that people might be using \I in single-quoted
strings already -- this would break. For example, some misguided
DOS user with a filename such as C:\INCLUDE\SYS$HEADER\ERRNO.H
(horribly contrived, I know -- not even sure whether $ is legal in a
DOS path, but I think it is) might be surprised if he got an error
message about $HEADER being undef.
What about \Itext\E, where text does not contain a scalar? Is this the
same as "text"? How about \Ibefore${var}after\E -- is that the same
as "before${var}after"? Does @foo interpolate inside \I...\E? (With
join $"?) What about backslashes inside \I...\E (as in the above funny
filename)?
Cheers,
Philip
Re: RFC 226 (v2) Selective interpolation in single quotish context.
On 14 Sep 2000, at 21:06, Glenn Linderman wrote: I _like_ the conceptual idea, here. But I think we need a different kind of quoting, not extend single quote semantics. Single quote semantics are really, really, good for exact quoting. I'm sure you (since you mention VMS) find single quote semantics good for escaping all those $ VMS requires. Well, we who are forced to use Windoze find single quote semantics good for escaping all those \ used in NT file names. So this proposal as now written blows that away: $x = 'C:\IN\MY\DIRECTORY\THERE\IS\A\FILE\NAMED\$FOO'; This becomes fun with UNC names, which have two backslashes at the beginning. But \\ in a single-quoted string becomes one backslash, so the filename is 'SERVER\SHARE\ONLY\ONE\SLASH\NOW' :-) Cheers, Philip
Re: RFC 226 (v2) Selective interpolation in single quotish context.
Perl6 should allow scalars and arrays to be tagged such that they are interpolated in single quotish context. How do you turn it off? I want to keep a way to specify stuff without any interpolation whatsoever. I see the usefulness of this sort of quoting, but I also see the usefulness of being absolutely able to turn all interpolation off. This seems mostly an issue in heredocs (though I appreciate your generalization to all single quotish contexts.) I wonder if perhaps it might be possible to combine some of the ideas from the white-space heredoc discussion and join them to this one and come up with a nice syntax for a sort of modified here-doc. -- Andy Dougherty [EMAIL PROTECTED] Dept. of Physics Lafayette College, Easton PA 18042
Re: RFC 226 (v2) Selective interpolation in single quotish context.
Andy Dougherty wrote: How do you turn it off? I want to keep a way to specify stuff without any interpolation whatsoever. I see the usefulness of this sort of quoting, but I also see the usefulness of being absolutely able to turn all interpolation off. Yes, I agree with this point, also raise by Glenn and others. Currently, there is very nice semantics in shell-style quoting: q// == '' == *NO* interpolation If we want a quasi-interpolated environment, I say we add qs// for "Single quotes with Some interpolation". I suspect once \I and \E catch on, people are going to be asking for others, and then pretty soon q// will not be much less interpolated than qq//. I think Perl *needs* a NO interpolation quoting contruct, and q// fits the bill quite nicely, as-is. I say a new one should be proposed that can handle these new quasi-interpolated semantics. -Nate
Re: RFC 226 (v2) Selective interpolation in single quotish context.
On Thu, 14 Sep 2000 21:06:24 -0700, Glenn Linderman wrote: However, let's look at it the other way. How about instead of trying to _extend_ single quote semantics, that instead we find a way of _disabling_ double quote semantics? Let's say within double quotes that \D reverts to single-quote semantics with the extension that \E ends them again. I think I like this better. There frequently are threads on comp.lang.perl.misc on people that are opposed to double quotes around strings that don't use any interpolation, because "the double quotes are a warning flag that there is something going on in this string" (paraphrased). And they tend to be slightly disappointed if it turns out to be a false alarm. Invert this: single quotes are a flag that "this string is safe". And now, you're going to add a facility that destroys this safe image? Please, let the programmer in his peace. Let the single quotish strings remain safe. OTOH, double quotish strings already *are* intrinsically unsafe. An option to locally disable interpolation is no extra burden. -- Bart.
Re: RFC 226 (v2) Selective interpolation in single quotish context.
On Fri, 15 Sep 2000 11:25:31 -0700, Steve Fink wrote: Does it strike anyone else as odd that 'foo\\bar' eq 'foo\bar'? It's an necessary evil. You need a way to escape the string delimiter, so that it can be included in the string, for which the backslash is used. Hence, you need to be a be to escape the backslash as well, or else you could never incorporate a backslash+delimiter sequence in the string. Note that backlash and delimiter are the *only* things for which the backslash character serves as an escape character: print q!\'\"\/\!\\!; -- \'\"\/!\ print q/\'\"\/\!\\/; -- \'\"/\!\ -- Bart.
Re: RFC 226 (v2) Selective interpolation in single quotish context.
On Fri, Sep 15, 2000 at 11:25:31AM -0700, Steve Fink wrote:
I agree. I'd like q/.../ to stick as close to giving me ... as possible.
I can live with the current 'foo\\bar' having only one backslash in it,
but I'd rather not have to worry about anything else. I'd vote for
Glenn's allowing the disabling of interpolation in qq// and ""
instead.
Does it strike anyone else as odd that 'foo\\bar' eq 'foo\bar'?
Not at all. I can't count the number of times I have railed against bash
for deciding that you cannot escape ' inside ' (e.g. 'foo\'s bar'). Being
unable to escape \ would cause similar grief (e.g. 'foo bar\\').
This is incredibly annoying when doing Perl one-liners especially; one is
forced to use single quotes so that bash doesn't attempt to interpolate
variables itself. Unfortunately, one can't use single quotes internally
unless you say \047 or its equivalent (which I nearly always have to go look
up), or q{} if you're quoting something. q{} has saved my sanity more than
once.
Michael
--
Administrator www.shoebox.net
Programmer, System Administrator www.gallanttech.com
--
Re: RFC 226 (v2) Selective interpolation in single quotish context.
What's wrong with extending current syntax such that:
$a = "Hello";
print q(@{[$a]} World), "\n";
outputs
Hello World
instead of
@{[$a]} World
yes, it's a few extra char's but IMHO
it's a logical extension
it makes you think twice before doing it, do you really need to do this, or is
there a smarter way?
--
#!/usr/bin/perl -nl
BEGIN{($,,$0)=("\040",21);@F=(sub{tr[a-zA-Z][n-za-mN-ZA-M];print;});
$_="Gnxr 1-3 ng n gvzr, gur ynfg bar vf cbvfba.";{$F[0]};sub t{*t=sub{};
return if rand().5;$_="Vg'f abg lbhe ghea lrg, abj tb.";{$F[0]};$_=0;}
sub v{print map sprintf('%c', 2**7-2**2),(1 .. $0);}v;}{$_++;$_--;$_||=4;
if($_2||($_212)){$_="Vainyvq ragel";{$F[0]};last;}t;$0-=$_;$_="Lbh jva";
die({$F[0]}) if !($0-1);$0-=$0%2?$02?2:1:$0=5?$02?3:1:rand.5?1:3;
$_="V jva";die({$F[0]}) if !($0-11);}v __END__ http://pthbb.org/
MOTD on Boomtime, the 38th of Bureaucracy, in the YOLD 3166:
"Are you calling me crackers? Are you saying I'm a large, sodium-covered square, here
to nourish you?" --Goodfeathers,Animaniacs
Re: RFC 226 (v2) Selective interpolation in single quotish context.
Oh yeah I forget to outline what it currently does for those whom may not have
seen it...
It's usally used for evaluation and interplation of code/subroutines
in "", qq() and HERE. And of course works fine on hashes, scalars, and
arrays.
So it's simply changing perl to check for this in q(). not add a whole
other set of tags and meaning...
--
#!/usr/bin/perl -nl
BEGIN{($,,$0)=("\040",21);@F=(sub{tr[a-zA-Z][n-za-mN-ZA-M];print;});
$_="Gnxr 1-3 ng n gvzr, gur ynfg bar vf cbvfba.";{$F[0]};sub t{*t=sub{};
return if rand().5;$_="Vg'f abg lbhe ghea lrg, abj tb.";{$F[0]};$_=0;}
sub v{print map sprintf('%c', 2**7-2**2),(1 .. $0);}v;}{$_++;$_--;$_||=4;
if($_2||($_212)){$_="Vainyvq ragel";{$F[0]};last;}t;$0-=$_;$_="Lbh jva";
die({$F[0]}) if !($0-1);$0-=$0%2?$02?2:1:$0=5?$02?3:1:rand.5?1:3;
$_="V jva";die({$F[0]}) if !($0-11);}v __END__ http://pthbb.org/
MOTD on Boomtime, the 38th of Bureaucracy, in the YOLD 3166:
"Are you calling me crackers? Are you saying I'm a large, sodium-covered square, here
to nourish you?" --Goodfeathers,Animaniacs
Re: RFC 226 (v2) Selective interpolation in single quotish context.
On Thu, Sep 14, 2000 at 10:01:23PM -0400, Jerrad Pierce wrote: What's wrong with extending current syntax such that: Please read the discussion so far. -- $jhi++; # http://www.iki.fi/jhi/ # There is this special biologist word we use for 'stable'. # It is 'dead'. -- Jack Cohen
Re: RFC 226 (v2) Selective interpolation in single quotish context.
Hang on... \I \E amounts to the same number of characters as using '. .' (that is, terminating this q-string, concat the thing, start a new q-string) So for scalars, there would be no savings at all. For arrays, yes, the proposed \I \E would still be useful. Maybe the \I should just scan for the following scalar/array var name and automatically turn itself off again. -- $jhi++; # http://www.iki.fi/jhi/ # There is this special biologist word we use for 'stable'. # It is 'dead'. -- Jack Cohen
Re: RFC 226 (v2) Selective interpolation in single quotish context.
Hang on... \I \E amounts to the same number of characters as using '. .' (that is, terminating this q-string, concat the thing, start a new q-string) You can't do that in a 'HERE' doc. For arrays, yes, the proposed \I \E would still be useful. Maybe the \I should just scan for the following scalar/array var name and automatically turn itself off again. No thanks. Suppose I want: '$x = $a; $y = func(\I$arg1, $arg2, $arg3\E); #etc. ' Unless it scans ahead and if it fails to find a \E, then it turns itself off after the first interpolation :-) Damian
Re: RFC 226 (v2) Selective interpolation in single quotish context.
On Fri, Sep 15, 2000 at 01:56:39PM +1100, Damian Conway wrote: Hang on... \I \E amounts to the same number of characters as using '. .' (that is, terminating this q-string, concat the thing, start a new q-string) You can't do that in a 'HERE' doc. True. For arrays, yes, the proposed \I \E would still be useful. Maybe the \I should just scan for the following scalar/array var name and automatically turn itself off again. No thanks. Suppose I want: '$x = $a; $y = func(\I$arg1, $arg2, $arg3\E); Hmmm...should \Ifunc($arg1)\E be replaced by the return value of func($arg1)? #etc. ' Unless it scans ahead and if it fails to find a \E, then it turns itself off after the first interpolation :-) :-) Also true. -- $jhi++; # http://www.iki.fi/jhi/ # There is this special biologist word we use for 'stable'. # It is 'dead'. -- Jack Cohen
Re: RFC 226 (v2) Selective interpolation in single quotish context.
No thanks. Suppose I want:
'$x = $a;
$y = func(\I$arg1, $arg2, $arg3\E);
Hmmm...should \Ifunc($arg1)\E be replaced by the return value of
func($arg1)?
I don't think so. I think \I..\E should just impose qq{..} semantics on
the text in between. So you'd still write:
"..\I${\func($arg1)}\E.."
or
"..\I@{[func($arg1)]}\E.."
Damian
Re: RFC 226 (v2) Selective interpolation in single quotish context.
"DC" == Damian Conway [EMAIL PROTECTED] writes:
No thanks. Suppose I want:
'$x = $a;
$y = func(\I$arg1, $arg2, $arg3\E);
Hmmm...should \Ifunc($arg1)\E be replaced by the return value of
func($arg1)?
DC I don't think so. I think \I..\E should just impose qq{..} semantics on
DC the text in between. So you'd still write:
DC "..\I${\func($arg1)}\E.."
DC or
DC "..\I@{[func($arg1)]}\E.."
that makes good sense. so in a single quote string you can have domains
of double quote behavior.
now, what if the double quoted range had a \E in it? either directly or
via interpolation? maybe the end escape should be another char than \E?
uri
--
Uri Guttman - [EMAIL PROTECTED] -- http://www.sysarch.com
SYStems ARCHitecture, Software Engineering, Perl, Internet, UNIX Consulting
The Perl Books Page --- http://www.sysarch.com/cgi-bin/perl_books
The Best Search Engine on the Net -- http://www.northernlight.com
Re: RFC 226 (v2) Selective interpolation in single quotish context.
that makes good sense. so in a single quote string you can have domains
of double quote behavior.
That's it exactly. Very well expressed, thanks Uri.
now, what if the double quoted range had a \E in it? either directly or
via interpolation? maybe the end escape should be another char than \E?
Make \E significant only where it's explicit. Also make \E signifcant
only when \I is in effect.
So to get the string '$interpolated\E\Einterpolated\E$$'
we write:
$x = 'interpolated\E';
$y = q{$\I$x\E\E\I$x\E$$};
Damian
Re: RFC 226 (v2) Selective interpolation in single quotish context.
I _like_ the conceptual idea, here. But I think we need a different kind of quoting, not extend single quote semantics. Single quote semantics are really, really, good for exact quoting. I'm sure you (since you mention VMS) find single quote semantics good for escaping all those $ VMS requires. Well, we who are forced to use Windoze find single quote semantics good for escaping all those \ used in NT file names. So this proposal as now written blows that away: $x = 'C:\IN\MY\DIRECTORY\THERE\IS\A\FILE\NAMED\$FOO'; Now this was always safe before, but now \I turns on intepolation at the third character, and ruins the name... what's more $FOO gets interpolated instead of used as the name. There just really isn't a character that works inside ' for adding additional interpolation semantics. However, let's look at it the other way. How about instead of trying to _extend_ single quote semantics, that instead we find a way of _disabling_ double quote semantics? Let's say within double quotes that \D reverts to single-quote semantics with the extension that \E ends them again. Then you VMS people could write: print F END; \D$! $! execute a.com, copy and purge $! $ @sys$login:a.com $ copy \E$filename\D sys$login:*.* $ purge sys$login:\E$filename\D $! $ exit END and we Windoze people could write $cmd = "copy \DC:\THERE\\EXISTS\A\$FOO\E /b $targetdir"; (would still have to watch out for those \E, but overall quite better than double quote semantics through the whole string), and the Unix people will laugh at all of us. Failing that, I think a new qX// operator would be the way to go. Please, please don't extend single quote semantics with _anything_. -- Glenn = There are two kinds of people, those who finish what they start, and so on... -- Robert Byrne ___ Why pay for something you could get for free? NetZero provides FREE Internet Access and Email http://www.netzero.net/download/index.html
Re: RFC 226 (v2) Selective interpolation in single quotish context.
Damian Conway wrote: now, what if the double quoted range had a \E in it? either directly or via interpolation? maybe the end escape should be another char than \E? Make \E significant only where it's explicit. None of the \ escapes are significant via interpolation, even today. \E shouldn't be any different. So I agree with this. Also make \E signifcant only when \I is in effect. I'm not so sure about this one: \E already has semantics for when \Q, \L, \U are in effect, too. So at minimum we'd have to be careful to document and understand what is meant by: $bar = 'abc'; $x = '$$$\Ifoo\U$bar\E\E$$$'; print $x; Does this produce: $$$fooABC\E$$$ or $$$fooABC$$$ So I tried to see how " handles multiple \E things, and discovered that while \E ends any of \Q \U \L, the semantics are individualized: \U will end a \L and I assume vice versa, but \Q doesn't affect \U or \L (whichever might be in effect). And \E will end the nearest prior \Q without disabling \U or \L (if either is also in effect), needing another \E to turn off a \U or \L that might be in effect. But a \E that has nothing in effect will still be elided from the " string. So we need to make it explicit how \I which would, I assume, also turn on \L, \U, and \Q for use, would interact with them probably that they would all have to be turned off before a \E would turn off \I. Or, if my other email using \D in double quotes is accepted, similar issues arise. -- Glenn = There are two kinds of people, those who finish what they start, and so on... -- Robert Byrne _NetZero Free Internet Access and Email__ http://www.netzero.net/download/index.html
RFC 226 (v2) Selective interpolation in single quotish context.
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Selective interpolation in single quotish context.
=head1 VERSION
Maintainer: Brad Hughes [EMAIL PROTECTED]
Date: Sep. 14, 2000
Last Modified: Sep. 14, 2000
Mailing List: [EMAIL PROTECTED]
Number: 226
Version: 2
Status: Developing
=head1 ABSTRACT
Perl6 should allow scalars and arrays to be tagged such that they are
interpolated in single quotish context.
=head1 DESCRIPTION
Single quotish context, such as Cq{}, C'', and specified here-docs,
is especially useful for large blocks of text which may contain
the C$ and C@ characters. Frequently, however, interpolation within
that large block of text is desired. This RFC proposes that in single
quotish context scalars and arrays may be tagged to be interpolated.
As an example, on the VMS operating system the C$ runs rampant
through VMS namespaces, not to mention that each line of VMS' equivalent
of a Unix shell script (called a .com file) starts with a C$, and execution
of VMS .com files is invoked with a C@, resulting in backslashitis:
print F END;
\$!
\$! execute a.com, copy and purge
\$!
\$ \@sys\$login:a.com
\$ copy $filename sys\$login:*.*
\$ purge sys\$login:$filename
\$!
\$ exit
END
With this proposal, the scalar C$filename can be tagged to be interpolated
by the C\I...\E pair and the double quotish context replaced by single
quotish context resulting in the following:
print F 'END';
$!
$! execute a.com, copy and purge
$!
$ @sys$login:a.com
$ copy \I$filename\E sys$login:*.*
$ purge sys$login:\I$filename\E
$!
$ exit
END
An array can be similarly tagged. Would C\Isubr\E call subr?.
=head1 IMPLEMENTATION
This wouldn't seem a difficult change to make.
=head1 REFERENCES
Originally suggested in a different form by Jarkko Hietaniemi [EMAIL PROTECTED] in
archive address to follow, and seconded by Mark-Jason Dominus
[EMAIL PROTECTED] in archive address to follow.
Version 2 tag pair suggested by Damian Conway in
