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
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
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
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
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
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
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
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
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
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
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().
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
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
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
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,
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
"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{..}
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
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
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
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]
21 matches
Mail list logo
