Re: Concerns about {...code...}
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=enlr=q=%5C%22%5C%7B+lang%3AperlbtnG=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}; # 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
Re: Concerns about {...code...}
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=enlr=q=%5C%22%5C%7B+lang%3AperlbtnG=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}; # 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...}
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...}
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...}
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...}
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...}
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...}
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
