Re: Concerns about "{...code...}"

[Michael G Schwern]

Larry Wall wrote:
> But I will make one general remark at the start, which is that we
> want Perl 6 programmer to look at curlies differently than Perl 5
> programmers do.  In Perl 5, curlies were overloaded many different
> ways, and rarely did they mean a closure by themselves.  In Perl 6,
> it's almost always the case that bare curlies indicate a closure of
> some sort throughout the rest of the language.  So the visual and
> psychological import of seeing and typing curlies is intentionally
> weighted rather differently.  Curlies are Perl 6's lambda.  Whenever
> the user sees curlies, we want them to stop and think.  Even the
> curlies used by the "built in" control operators are real lambdas
> in the abstract, unlike in P5 where they are just hardwired in the
> grammar.  Bare curlies in regex are now special too.

All this makes me happy and more willing to accept interpolative curlies.  I
was rapidly hooked on Ruby's ability to easily pass blocks into methods and
want to see more user ability to play with blocks.

And after looking a bit more into how Perl 6 does interpolation I see a lot
has changed.  So I'll drink it all in some more.


> : Code execution in a string is a very powerful thing, so it's not the sort of
> : thing one wants to accidentally trigger.  Because it's using a common,
> : innocent construct, this strikes me as being all too easy to trigger
> : accidentally and unknowingly.
> : 
> : $ pugs -wle 'sub key() { 42 } sub value() { 23 }  say "{ key: value }"'
> : 23
> : 
> : Whoops.
> 
> Seems like you had to work pretty hard to contrive an example
> that would parse.  P6 is much pickier about random code than P5 is.

FWIW that naturally occurred to me and I was surprised when it parsed without
error.  But I've been doing a lot of YAML lately.


> As a last resort, you can even redefine how double quotes work.
> "All is fair if you predeclare."  But I think some people would
> construe that as antisocial.

Every time someone responds to a Perl 6 language concern with "just change the
grammar" I silently scream inside. ;)


-- 
Life is like a sewer - what you get out of it depends on what you put into it.
- Tom Lehrer

Re: Concerns about "{...code...}"

[Juerd Waalboer]

Michael G Schwern skribis 2007-12-21 19:21 (-0800):
> Normally I'd go on the side of the reader and say yes, when writing code you
> should be picky about what quotes you use.  But in this case I find that, on
> the writing side, I find it a common annoyance when I chuck a variable into a
> string and then only realize afterwards that it's not interpolating.  On the
> reading side, I find visually scanning for $ in strings easy and I guess I
> assume everyone else does, too.

Just to add nothing to the discussion: I find double quotes without
interpolation annoying, but only when I'm reading code without
syntax highlighting. Whenever I read code with syntax highlighting that
makes the interpolated variables stand out, it's no issue at all.

I tend to write "" first, and then change them to '' when getting close
to releasing the code. Unpaid non-opensource code usually stays at ""...

My excuse is growing up with BASIC.
-- 
Met vriendelijke groet,  Kind regards,  Korajn salutojn,

  Juerd Waalboer:  Perl hacker  <[EMAIL PROTECTED]>  
  Convolution: ICT solutions and consultancy <[EMAIL PROTECTED]>

Re: Concerns about "{...code...}"

[Michael G Schwern]

John Siracusa wrote:
> On 12/21/07 5:54 AM, Larry Wall wrote:
>> To you and me, the fact that there are single quotes means there's
>> something there to hide.  But other people think the other way and
>> see double quotes as indicating there's something to interpolate.
>> I think PBP comes down on that side, but to me, single quotes are a
>> little harder to see.  And maybe there's some bias from seeing double
>> quotes used non-interpolatively in American English.
> 
> FWIW, my reasoning in this area is based on Laziness: single quotes mean I
> don't have to scan the string looking for interpolated stuff when reading
> code.  Double quotes mean I do, and I'm annoyed at the waste of time when I
> scan and find nothing.  "Why didn't this guy just use singles here?"  It's
> (mildly) misleading.
> 
> (There are obviously edge cases, even in Perl 5, but even naive adherence to
> this guideline is a good first approximation, with a second look only
> required in the rarest of cases.)

Normally I'd go on the side of the reader and say yes, when writing code you
should be picky about what quotes you use.  But in this case I find that, on
the writing side, I find it a common annoyance when I chuck a variable into a
string and then only realize afterwards that it's not interpolating.  On the
reading side, I find visually scanning for $ in strings easy and I guess I
assume everyone else does, too.


-- 
We do what we must because we can.
For the good of all of us,
Except the ones who are dead.
-- Jonathan Coulton, "Still Alive"

Re: Concerns about "{...code...}"

[Larry Wall]

On Fri, Dec 21, 2007 at 01:51:19PM -0800, Dave Whipp wrote:
> Larry Wall wrote:
>
>> As for the Q base form, it's not really there so much for end-use,
>
> For an operator not intended for end use, it has a remarkable low Huffman 
> rank...

That's because some end-users will want to use Q anyway.  I figured
the shift key requirement was sufficient Huffman coding...  :-)

Larry

Re: Concerns about "{...code...}"

[Jonathan Lang]

Dave Whipp wrote:
> If the construct is used only rarely then it should have a longer name,

Actually, Huffman coding implies that if the construct is used
regularly then it should have a short name.  It does not mandate a
long name for rare constructs; it merely says that if a given short
name is suitable for both a common construct and a rare construct, the
common construct should get it.  If there's no such conflict, there's
no reason not to give the short name to a rarely used construct.

-- 
Jonathan "Dataweaver" Lang

Re: Concerns about "{...code...}"

[Dave Whipp]

Chas. Owens wrote:

On Dec 21, 2007 4:51 PM, Dave Whipp <[EMAIL PROTECTED]> wrote:

Larry Wall wrote:


As for the Q base form, it's not really there so much for end-use,
For an operator not intended for end use, it has a remarkable low
Huffman rank...


But since it will be combined with adverbs like

my $str = Q :b :s /Hello $name\n/;

it needs to be short.   Q is just one part of a larger expression that
is meant to be taken as a whole.


That misses the point of Huffman coding. It is not the length of the 
overall expression that determines the score: it is the relative 
frequency with which it will appear in perl6 programs.


If the construct is used only rarely then it should have a longer name, 
and people using it would be well advised to use the long form of the 
adverbs when they do so -- increasing the overall length of the 
expression still further as an aid to readability of the rarely used 
operator.


If it will be frequently used then it of course deserves the short name.

Re: Concerns about "{...code...}"

[Chas. Owens]

On Dec 21, 2007 4:51 PM, Dave Whipp <[EMAIL PROTECTED]> wrote:
> Larry Wall wrote:
>
> > As for the Q base form, it's not really there so much for end-use,
>
> For an operator not intended for end use, it has a remarkable low
> Huffman rank...
>

But since it will be combined with adverbs like

my $str = Q :b :s /Hello $name\n/;

it needs to be short.   Q is just one part of a larger expression that
is meant to be taken as a whole.

Re: Concerns about "{...code...}"

[Dave Whipp]

Larry Wall wrote:


As for the Q base form, it's not really there so much for end-use,


For an operator not intended for end use, it has a remarkable low 
Huffman rank...

Re: Concerns about "{...code...}"

[Larry Wall]

On Fri, Dec 21, 2007 at 08:59:02AM -0500, Mark J. Reed wrote:
: The single-quoted string literal has become such a habit that I frequently
: make mistakes in other C-like languages that use the two types of quotation
: marks to make the character/string distinction.

Yeah, it might be my C background that biases me the other way too.

I guess when I'm reading someone else's double-quoted string I don't
really feel like I need to check whether it interpolates; it just
"chunks" into a psychological unit that *could* interpolate if it
wants to, and I note any obvious literal text and go on from there.
I don't feel compelled to analyze the string in depth unless I need to.

For someone who is somewhere on the autistic spectrum, I'm pretty good
at ignoring details.  I understand others may not be so lucky.  :)

Larry

Re: Concerns about "{...code...}"

[Brandon S. Allbery KF8NH]

On Dec 21, 2007, at 5:54 , Larry Wall wrote:


On Thu, Dec 20, 2007 at 03:24:30PM -0800, Michael G Schwern wrote:
: Jonathan Scott Duff wrote:
: [1] Note, I'm the sort of person that uses "" until I have a  
reason otherwise.


Well, me too, but P6 just provides a different set of reasons.  :)

To you and me, the fact that there are single quotes means there's
something there to hide.  But other people think the other way and
see double quotes as indicating there's something to interpolate.
I think PBP comes down on that side, but to me, single quotes are a


FWIW, as a sysadmin who's learned (sometimes the hard way) that  
paranoia is good when coding, I tend to use single quotes in Perl  
(and shell) code unless I specifically want interpolation to happen.   
Also, I come down on the side of "generic interpolation should be a  
little harder to enable":  either with a more complex interpolation  
syntax (although your arguments for simple braces have merit) or a  
quoting adverb which defaults off.


--
brandon s. allbery [solaris,freebsd,perl,pugs,haskell] [EMAIL PROTECTED]
system administrator [openafs,heimdal,too many hats] [EMAIL PROTECTED]
electrical and computer engineering, carnegie mellon universityKF8NH

Re: Concerns about "{...code...}"

[Mark J. Reed]

On Dec 21, 2007 8:53 AM, John Siracusa <[EMAIL PROTECTED]> wrote:

> FWIW, my reasoning in this area is based on Laziness: single quotes mean I
> don't have to scan the string looking for interpolated stuff when reading
> code.  Double quotes mean I do, and I'm annoyed at the waste of time when
> I
> scan and find nothing.  "Why didn't this guy just use singles here?"  It's
> (mildly) misleading.


+1, as the kids these days say.

I use singles by default for literal strings.  I switch to doubles when I
need to interpolate, or for text containing apostrophes (though it would be
more consistent to use q[...] in the latter case.  I use qq and qw all the
time, but rarely q for some reason).

The single-quoted string literal has become such a habit that I frequently
make mistakes in other C-like languages that use the two types of quotation
marks to make the character/string distinction.


-- 
Mark J. Reed <[EMAIL PROTECTED]>

Re: Concerns about "{...code...}"

[John Siracusa]

On 12/21/07 5:54 AM, Larry Wall wrote:
> To you and me, the fact that there are single quotes means there's
> something there to hide.  But other people think the other way and
> see double quotes as indicating there's something to interpolate.
> I think PBP comes down on that side, but to me, single quotes are a
> little harder to see.  And maybe there's some bias from seeing double
> quotes used non-interpolatively in American English.

FWIW, my reasoning in this area is based on Laziness: single quotes mean I
don't have to scan the string looking for interpolated stuff when reading
code.  Double quotes mean I do, and I'm annoyed at the waste of time when I
scan and find nothing.  "Why didn't this guy just use singles here?"  It's
(mildly) misleading.

(There are obviously edge cases, even in Perl 5, but even naive adherence to
this guideline is a good first approximation, with a second look only
required in the rarest of cases.)

-John

Re: Concerns about "{...code...}"

[Larry Wall]

On Thu, Dec 20, 2007 at 03:24:30PM -0800, Michael G Schwern wrote:
: Jonathan Scott Duff wrote:
: > On Thu, Dec 20, 2007 at 07:58:51AM -0500, Mark J. Reed wrote:
: >> I think the issue is that bare vars don't interpolate anymore, but
: >> they still have sigils of their own, so adding to the default interp
: >> syntax is too noisy:  ${$var} is not really much improvement over
: >> ${\(expr)}.
: > 
: > That's not quite accurate.  Scalars interpolate as they always have, but
: > aggregates need to be followed their respective bracketing construct
: > (e.g., "My array contains these items: @array[]")
: > 
: > The only "issues" that I see from the original email are:
: > 1. interpolating scalars but not code
: > 2. having to be more careful about what type of string you're using
: > 
: > Adriano answered #1 I think:  $yaml = Q:!c"{ $key: 42 }";
: > 
: > For the second one, if you're really just worried about how prevalent {}
: > appear in double-quotish strings, perhaps @Larry could be persuaded to
: > make them non-interpolative by default. (i.e., the adverb would be
: > required to make them interpolate)
: 
: That pretty much sums up my concern.

Well, it's certainly a concern that we thought about a lot when
designing the interpolation originally, so I rather suspect I'm highly
unlikely to change my mind on this one.  I've done (and read) a fair
amount of pugs programming since then, and while I can see that from a
Perl 5 perspective it looks like a problem, the situation doesn't arise
so often in practice, and when it does, it almost always results in
a compile-time error (which is a good thing).  Perl 6 balances a lot
of subtle issues differently than Perl 5 does, and these all factor into
whether closures should interpolate by default or not.  More on that
below.

But I will make one general remark at the start, which is that we
want Perl 6 programmer to look at curlies differently than Perl 5
programmers do.  In Perl 5, curlies were overloaded many different
ways, and rarely did they mean a closure by themselves.  In Perl 6,
it's almost always the case that bare curlies indicate a closure of
some sort throughout the rest of the language.  So the visual and
psychological import of seeing and typing curlies is intentionally
weighted rather differently.  Curlies are Perl 6's lambda.  Whenever
the user sees curlies, we want them to stop and think.  Even the
curlies used by the "built in" control operators are real lambdas
in the abstract, unlike in P5 where they are just hardwired in the
grammar.  Bare curlies in regex are now special too.

(Going the other way, you'll note that, in various other spots where
P5 uses curlies such as in \x{...} or $x{foo}, P6 prefers things like
\x[...] or $x instead, to avoid the visual implication of code.)

: The gyrations to turn off interpolating code... it's nice to know that exists
: but not something I want to ever have to remember or type or even consider my
: quoting context.

In general, I would never use negative form myself.  I'd be much more
likely to use qs// than qq:!c//.  But since the negative adverbial
forms are already available, it seems better to go ahead and provide
them to work as expected, even if they inspire occasional nausea.

As for the Q base form, it's not really there so much for end-use,
but to provide the bare form from which all other quotes and quote-like
forms are constructed, including forms like rx//.  Most user-defined
quotes should just be variants of q//.  Or just use bare '' quotes,
since it's still possible to interpolate using \qq[$foo].  This is
huffmanly suitable for quoting large stretches of code that need only
occasional interpolations.

: "Interpolate" vs "not interpolate" is enough, I have more
: important things to worry about while coding. [1]

And, in fact, this can be taken as an argument for making closures
interpolate consistently in double quotes, if they interpolate at all.
To the first approximation, double quotes do all interpolations
and single quotes do none (ignoring backslashes).  Positioning the
double quote semantics somewhere in the middle of the spectrum just
means you have to memorize which sequences interpolate by default
and which don't.  And we're trying to avoid the need for the user to
memorize arbitrary lists.

: Non-interpolative by default... well I don't exactly want the feature to go
: away either. [2]  I can see its uses [3] and it potentially eliminates some
: otherwise convoluted bits of code.  And again, I don't want to be thinking
: about flipping interpolation features on and off for each string.  Even qs//
: is more than I want to consider. [4]

In general, if you're interpolating a bunch of strings similarly,
you want to think about factoring that out.  One of the reasons
we're reserving backticks for users is so they can use them for
any specialty quotes, not just for qqx//.

: Code execution in a string is a very powerful thing, so it's not the sort of
: thing one wants to accid

Re: Concerns about "{...code...}"

[Michael G Schwern]

Mark J. Reed wrote:
> No need to get snippy.

I thought the "I'm just fucking around" emotey would be enough.


> PHP may be the best argument out there for
> namespace control, but that doesnt mean it doesnt also have some nice
> bits.  Im rather fond of its extended foreach syntax, for instance.
> (Though I disagree with the conflation of numeric and associative
> arrays, a flaw shared by JavaScript.)
> 
> 
> On 12/20/07, Michael G Schwern <[EMAIL PROTECTED]> wrote:
>> Patrick R. Michaud wrote:
>>> Just to add another perspective, PHP uses curlies inside of
>>> double-quoted strings to indicate various forms of
>>> interpolation, and it doesn't seem to cause major issues
>>> there.
>> PHP has 8000 built in functions and it doesn't seem to cause issues there.
>> I'll not be taking my language design advice from PHP TYVM. ;P
^
-->>^


-- 
I do have a cause though. It's obscenity. I'm for it.
- Tom Lehrer

Re: Concerns about "{...code...}"

[Mark J. Reed]

Since i was mistaken about bare vars (scalars still interpolate), I
agree with Mr. Schwern: plain curlies are insufficiently distinct for
the interpolation syntax.  Sigil+curlies would be better.


On 12/20/07, Patrick R. Michaud <[EMAIL PROTECTED]> wrote:
> On Thu, Dec 20, 2007 at 06:01:53PM -0500, Mark J. Reed wrote:
> >On Dec 20, 2007 4:30 PM, Patrick R. Michaud <[EMAIL PROTECTED]> wrote:
> >
> >  Just to add another perspective, PHP uses curlies inside of
> >  double-quoted strings to indicate various forms of
> >  interpolation, and it doesn't seem to cause major issues
> >  there.
> >
> >But PHP's use of curlies is limited and context-sensitive; it's
> triggered
> >by the sequence {$ or ${.  Bare curlies don't do anything.
>
> Ah yes, good point.  I thus withdraw my PHP comment, and we're
> left with the examples in S02.
>
> It could be said that closure interpolation would be off by
> default, and enabled using the :c adverb or the C quoter
> that is already part of the spec.  Then we would have
>
> "These { curlies } aren't interpolative."
> qc "These { 'curl' ~ 'ies' } are."
>
> I don't have a strong opinion one way or another -- I'm just
> trying to point out some alternatives and things the current
> spec already offers.  But perhaps this is all a reminder as to
> why I try to stay out of the language design forum.
>
> Pm
>


-- 
Mark J. Reed <[EMAIL PROTECTED]>

Re: Concerns about "{...code...}"

[Patrick R. Michaud]

On Thu, Dec 20, 2007 at 06:01:53PM -0500, Mark J. Reed wrote:
>On Dec 20, 2007 4:30 PM, Patrick R. Michaud <[EMAIL PROTECTED]> wrote:
> 
>  Just to add another perspective, PHP uses curlies inside of
>  double-quoted strings to indicate various forms of
>  interpolation, and it doesn't seem to cause major issues
>  there. 
> 
>But PHP's use of curlies is limited and context-sensitive; it's triggered
>by the sequence {$ or ${.  Bare curlies don't do anything.  

Ah yes, good point.  I thus withdraw my PHP comment, and we're
left with the examples in S02.  

It could be said that closure interpolation would be off by 
default, and enabled using the :c adverb or the C quoter 
that is already part of the spec.  Then we would have

"These { curlies } aren't interpolative."
qc "These { 'curl' ~ 'ies' } are."

I don't have a strong opinion one way or another -- I'm just
trying to point out some alternatives and things the current
spec already offers.  But perhaps this is all a reminder as to
why I try to stay out of the language design forum.

Pm

Re: Concerns about "{...code...}"

[Michael G Schwern]

Jonathan Scott Duff wrote:
> On Thu, Dec 20, 2007 at 07:58:51AM -0500, Mark J. Reed wrote:
>> I think the issue is that bare vars don't interpolate anymore, but
>> they still have sigils of their own, so adding to the default interp
>> syntax is too noisy:  ${$var} is not really much improvement over
>> ${\(expr)}.
> 
> That's not quite accurate.  Scalars interpolate as they always have, but
> aggregates need to be followed their respective bracketing construct
> (e.g., "My array contains these items: @array[]")
> 
> The only "issues" that I see from the original email are:
> 1. interpolating scalars but not code
> 2. having to be more careful about what type of string you're using
> 
> Adriano answered #1 I think:  $yaml = Q:!c"{ $key: 42 }";
> 
> For the second one, if you're really just worried about how prevalent {}
> appear in double-quotish strings, perhaps @Larry could be persuaded to
> make them non-interpolative by default. (i.e., the adverb would be
> required to make them interpolate)

That pretty much sums up my concern.

The gyrations to turn off interpolating code... it's nice to know that exists
but not something I want to ever have to remember or type or even consider my
quoting context.  "Interpolate" vs "not interpolate" is enough, I have more
important things to worry about while coding. [1]

Non-interpolative by default... well I don't exactly want the feature to go
away either. [2]  I can see its uses [3] and it potentially eliminates some
otherwise convoluted bits of code.  And again, I don't want to be thinking
about flipping interpolation features on and off for each string.  Even qs//
is more than I want to consider. [4]

Code execution in a string is a very powerful thing, so it's not the sort of
thing one wants to accidentally trigger.  Because it's using a common,
innocent construct, this strikes me as being all too easy to trigger
accidentally and unknowingly.

$ pugs -wle 'sub key() { 42 } sub value() { 23 }  say "{ key: value }"'
23

Whoops.

It's also worth noting that ${} and @{} adding more context flexibility.  It
appears {} only happens in list context right now, though I admit I'm not up
on all the new contexts.


[1] Note, I'm the sort of person that uses "" until I have a reason otherwise.

[2] Now being able to turn it ON in a single quoted string would be handy, but
that's just because of my special case writing a lot of make generating
code where $ already has meaning.

[3] Although a lot of them are handled by the interpolation of $obj.method()
which makes me happy.

[4] Which doesn't appear to be documented in S2.


-- 
Look at me talking when there's science to do.
When I look out there it makes me glad I'm not you.
I've experiments to be run.
There is research to be done
On the people who are still alive.
-- Jonathan Coulton, "Still Alive"

Re: Concerns about "{...code...}"

[Mark J. Reed]

No need to get snippy.  PHP may be the best argument out there for
namespace control, but that doesnt mean it doesnt also have some nice
bits.  Im rather fond of its extended foreach syntax, for instance.
(Though I disagree with the conflation of numeric and associative
arrays, a flaw shared by JavaScript.)


On 12/20/07, Michael G Schwern <[EMAIL PROTECTED]> wrote:
> Patrick R. Michaud wrote:
> > Just to add another perspective, PHP uses curlies inside of
> > double-quoted strings to indicate various forms of
> > interpolation, and it doesn't seem to cause major issues
> > there.
>
> PHP has 8000 built in functions and it doesn't seem to cause issues there.
> I'll not be taking my language design advice from PHP TYVM. ;P
>
>
> --
> I am somewhat preoccupied telling the laws of physics to shut up and sit
> down.
>   -- Vaarsuvius, "Order of the Stick"
>http://www.giantitp.com/comics/oots0107.html
>


-- 
Mark J. Reed <[EMAIL PROTECTED]>

Re: Concerns about "{...code...}"

[Mark J. Reed]

On Dec 20, 2007 4:30 PM, Patrick R. Michaud <[EMAIL PROTECTED]> wrote:

> Just to add another perspective, PHP uses curlies inside of
> double-quoted strings to indicate various forms of
> interpolation, and it doesn't seem to cause major issues
> there.


But PHP's use of curlies is limited and context-sensitive; it's triggered by
the sequence {$ or ${.  Bare curlies don't do anything.  It's designed for
enclosing complex dereferences, e.g. an array with a literal key that's more
complex than a simple string, or that contains spaces (can't use quotes in
interpolated array indexes, just like Perl5):

"The value is {$array['a key']}" or"The value is ${array['a key']}"

But:

"The value is {1 + 2 - 3}"   - no interpolation
"The value is {$x +$y - $z}" - syntax error because it expects the string
starting with $x to be a dereference.

-- 
Mark J. Reed <[EMAIL PROTECTED]>

Re: Concerns about "{...code...}"

[Michael G Schwern]

Patrick R. Michaud wrote:
> Just to add another perspective, PHP uses curlies inside of
> double-quoted strings to indicate various forms of 
> interpolation, and it doesn't seem to cause major issues
> there.

PHP has 8000 built in functions and it doesn't seem to cause issues there.
I'll not be taking my language design advice from PHP TYVM. ;P


-- 
I am somewhat preoccupied telling the laws of physics to shut up and sit down.
-- Vaarsuvius, "Order of the Stick"
   http://www.giantitp.com/comics/oots0107.html

Re: Concerns about "{...code...}"

[Patrick R. Michaud]

On Thu, Dec 20, 2007 at 11:35:44AM -0600, Jonathan Scott Duff wrote:
> On Thu, Dec 20, 2007 at 11:23:05AM -0600, Jonathan Scott Duff wrote:
> > Adriano answered #1 I think:  $yaml = Q:!c"{ $key: 42 }";
> 
> Er, I just looked over the spec again and realized that Q does
> absolutely no interpolation, so it would be more like this:
> 
> $yaml = Q:qq:!c"{ $key: 42 }";
> 
> or perhaps
> 
> $yaml = qq:!c"{ $key: 42 }";

There's also

$yaml = qs "{ $key: 42 }";

This form also makes it easier to deal with special characters,
such as quoted yaml values, as in

$yaml = qs /{ $key: "$value" }/;

which interpolates $key and $value but leaves the curlies and
quotation marks alone.

Just to add another perspective, PHP uses curlies inside of
double-quoted strings to indicate various forms of 
interpolation, and it doesn't seem to cause major issues
there.  But perhaps it's less frequent that PHP apps need
to put curlies in double-quoted strings.  Still, given the
very few times I've had to do this, I've never found it
overly onerous to escape the leading curly the few times I've
needed it.

Pm

Re: Concerns about "{...code...}"

[Dave Mitchell]

On Thu, Dec 20, 2007 at 11:35:44AM -0600, Jonathan Scott Duff wrote:
> On Thu, Dec 20, 2007 at 11:23:05AM -0600, Jonathan Scott Duff wrote:
> > Adriano answered #1 I think:  $yaml = Q:!c"{ $key: 42 }";
> 
> Er, I just looked over the spec again and realized that Q does
> absolutely no interpolation, so it would be more like this:
> 
> $yaml = Q:qq:!c"{ $key: 42 }";
> 
> or perhaps
> 
> $yaml = qq:!c"{ $key: 42 }";

To me they look like abominations. Is there any pressing need to have code
interpolate, other than for simple convenience?

-- 
"You may not work around any technical limitations in the software"
-- Windows Vista license

Re: Concerns about "{...code...}"

[Jonathan Scott Duff]

On Thu, Dec 20, 2007 at 11:23:05AM -0600, Jonathan Scott Duff wrote:
> Adriano answered #1 I think:  $yaml = Q:!c"{ $key: 42 }";

Er, I just looked over the spec again and realized that Q does
absolutely no interpolation, so it would be more like this:

$yaml = Q:qq:!c"{ $key: 42 }";

or perhaps

$yaml = qq:!c"{ $key: 42 }";


-Scott
-- 
Jonathan Scott Duff <[EMAIL PROTECTED]>

Re: Concerns about "{...code...}"

[Jonathan Scott Duff]

On Thu, Dec 20, 2007 at 07:58:51AM -0500, Mark J. Reed wrote:
> I think the issue is that bare vars don't interpolate anymore, but
> they still have sigils of their own, so adding to the default interp
> syntax is too noisy:  ${$var} is not really much improvement over
> ${\(expr)}.

That's not quite accurate.  Scalars interpolate as they always have, but
aggregates need to be followed their respective bracketing construct
(e.g., "My array contains these items: @array[]")

The only "issues" that I see from the original email are:
1. interpolating scalars but not code
2. having to be more careful about what type of string you're using

Adriano answered #1 I think:  $yaml = Q:!c"{ $key: 42 }";

For the second one, if you're really just worried about how prevalent {}
appear in double-quotish strings, perhaps @Larry could be persuaded to
make them non-interpolative by default. (i.e., the adverb would be
required to make them interpolate)

-Scott
-- 
Jonathan Scott Duff <[EMAIL PROTECTED]>

Re: Concerns about "{...code...}"

[Mark J. Reed]

I think the issue is that bare vars don't interpolate anymore, but
they still have sigils of their own, so adding to the default interp
syntax is too noisy:  ${$var} is not really much improvement over
${\(expr)}.

 - Original message -
I am not quite sure of all the implications in t...

On 12/20/07, Adriano Ferreira <[EMAIL PROTECTED]> wrote:
> On Dec 20, 2007 1:48 AM, Michael G Schwern <[EMAIL PROTECTED]> wrote:
> > I was reading an article about Perl 6, I forget which one, and it happened
> to
> > mention that code can be interpolated inside double quoted strings.
> That's
> > one thing, my concern is with the selected syntax.
> >
> > say "foo { 1+1 }";   # "foo 2"
> >
> > The {...} construct seems far too common one in normal text to be given
> > special meaning.  One data point is to do a google code search for "{ in
> Perl
> > 5.  It comes up with quite a lot.
> >
> http://www.google.com/codesearch?hl=en&lr=&q=%5C%22%5C%7B+lang%3Aperl&btnG=Search
> >
> > Another concern is embedded YAML.
> >
> > $yaml = "{ $key: 42 }";   # syntax error in Perl 6
> >
> > Finally, it chokes on unbalanced braces adding another trap for users.
> >
> > I'm concerned this will lead to a lot of unsightly backwhacking or having
> to
> > be more careful about what type of string you're using.
> >
> > What about ${} and @{} instead?  ${} would execute in scalar context and
> @{}
> > in list.  They're just cleaned up versions of the successful, but ugly,
> Perl 5
> > idioms ${\(...)} and @{[...]} idioms.  They make use of an existing
> > interpolated character so there's no additional load on the programmer.
> >
> > ${} and @{} already have interpolated meanings in Perl 5 but not in Perl
> 6.
>
> I am not quite sure of all the implications in the design of quoting
> constructs (which is detailed in Synopsis 02 -
> http://perlcabal.org/syn/S02.html). But it seems Larry anticipated
> mechanisms to handle all the cases you mentioned.
>
> For instance, while {...} expressions do interpolate by default as in
>
> > say "foo { 1+1 }";   # "foo 2"
>
> but that can be stopped by using a quoting construct plus an adverb. I
> think that should be something like
>
> say Q :!c ;   # "foo { 1 + 1 }"
>
> Also, the sigils can interpolate just the way you said, but using ()
> rather than braces (which is consistent to how they are used in other
> expressions of the language).
>
> It is all there somewhere in Section "Literals" of Synopsis 02
> (http://perlcabal.org/syn/S02.html#Literals). More specifically, look
> for the item that starts with "In addition to q and qq, there is now
> the base form Q".
>
> Kind regards,
> Adriano Ferreira
>
> > --
> > ...they shared one last kiss that left a bitter yet sweet taste in her
> > mouth--kind of like throwing up after eating a junior mint.
> > -- Dishonorable Mention, 2005 Bulwer-Lytton Fiction Contest
> >by Tami Farmer
> >
> >
>


-- 
Mark J. Reed <[EMAIL PROTECTED]>

Re: Concerns about "{...code...}"

[Adriano Ferreira]

On Dec 20, 2007 1:48 AM, Michael G Schwern <[EMAIL PROTECTED]> wrote:
> I was reading an article about Perl 6, I forget which one, and it happened to
> mention that code can be interpolated inside double quoted strings.  That's
> one thing, my concern is with the selected syntax.
>
> say "foo { 1+1 }";   # "foo 2"
>
> The {...} construct seems far too common one in normal text to be given
> special meaning.  One data point is to do a google code search for "{ in Perl
> 5.  It comes up with quite a lot.
> http://www.google.com/codesearch?hl=en&lr=&q=%5C%22%5C%7B+lang%3Aperl&btnG=Search
>
> Another concern is embedded YAML.
>
> $yaml = "{ $key: 42 }";   # syntax error in Perl 6
>
> Finally, it chokes on unbalanced braces adding another trap for users.
>
> I'm concerned this will lead to a lot of unsightly backwhacking or having to
> be more careful about what type of string you're using.
>
> What about ${} and @{} instead?  ${} would execute in scalar context and @{}
> in list.  They're just cleaned up versions of the successful, but ugly, Perl 5
> idioms ${\(...)} and @{[...]} idioms.  They make use of an existing
> interpolated character so there's no additional load on the programmer.
>
> ${} and @{} already have interpolated meanings in Perl 5 but not in Perl 6.

I am not quite sure of all the implications in the design of quoting
constructs (which is detailed in Synopsis 02 -
http://perlcabal.org/syn/S02.html). But it seems Larry anticipated
mechanisms to handle all the cases you mentioned.

For instance, while {...} expressions do interpolate by default as in

> say "foo { 1+1 }";   # "foo 2"

but that can be stopped by using a quoting construct plus an adverb. I
think that should be something like

say Q :!c ;   # "foo { 1 + 1 }"

Also, the sigils can interpolate just the way you said, but using ()
rather than braces (which is consistent to how they are used in other
expressions of the language).

It is all there somewhere in Section "Literals" of Synopsis 02
(http://perlcabal.org/syn/S02.html#Literals). More specifically, look
for the item that starts with "In addition to q and qq, there is now
the base form Q".

Kind regards,
Adriano Ferreira

> --
> ...they shared one last kiss that left a bitter yet sweet taste in her
> mouth--kind of like throwing up after eating a junior mint.
> -- Dishonorable Mention, 2005 Bulwer-Lytton Fiction Contest
>by Tami Farmer
>
>