Re: Deprecation plans -- concerning left-pointing double angle bracket followed by whitespace

--001a1146311ab54ea90545d21854
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Sun, Jan 8, 2017 at 12:22 PM, Sawyer X <xsawyerx@gmail.com> wrote:

* Use of bare << to mean <<"" is deprecated: Deprecated in 5.000, remove
> in 5.28.0.


does this mean that after 5.28, whitespace between the chevron and the
terminator will be allowed, or does it mean something else?

Currently the following will warn, then crash: Bareword found where
operator expected, near "T6TOR"


print << T6TOR;
this is the only situation when I ever see that $warning
T6TOR


also, unrelated, do we allow =E3=80=8Aand the like to stand in for << yet?


--=20
"Have you taken yourself seriously today?" -- the gravity clown

--001a1146311ab54ea90545d21854
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><div class=3D"gmail_quo=
te">On Sun, Jan 8, 2017 at 12:22 PM, Sawyer X <span dir=3D"ltr">&lt;<a href=
=3D"mailto:xsawyerx@gmail.com" target=3D"_blank">xsawyerx@gmail.com</a>&gt;=
</span> wrote:</div><div class=3D"gmail_quote"><br><blockquote class=3D"gma=
il_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,2=
04,204);padding-left:1ex">
* Use of bare &lt;&lt; to mean &lt;&lt;&quot;&quot; is deprecated: Deprecat=
ed in 5.000, remove<br>
in 5.28.0.</blockquote><div><br></div><div>does this mean that after 5.28, =
whitespace between the chevron and the terminator will be allowed, or does =
it mean something else?</div><div><br></div><div><div>Currently the followi=
ng will warn, then crash: Bareword found where operator expected, near &quo=
t;T6TOR&quot;</div></div><div><br></div><div><br></div><div>print &lt;&lt; =
T6TOR;</div><div>this is the only situation when I ever see that $warning</=
div><div>T6TOR=C2=A0<br></div></div><div><br></div><div><br></div><div><spa=
n style=3D"color:rgb(51,51,51);font-family:&quot;open sans&quot;,&quot;helv=
etica neue&quot;,helvetica,arial,sans-serif;font-size:14px;background-color=
:rgb(249,249,249)">also, unrelated, do we allow =E3=80=8Aand the like to st=
and in for &lt;&lt; yet?</span><br></div><div><span style=3D"color:rgb(51,5=
1,51);font-family:&quot;open sans&quot;,&quot;helvetica neue&quot;,helvetic=
a,arial,sans-serif;font-size:14px;background-color:rgb(249,249,249)"><br></=
span></div><div><span style=3D"color:rgb(51,51,51);font-family:&quot;open s=
ans&quot;,&quot;helvetica neue&quot;,helvetica,arial,sans-serif;font-size:1=
4px;background-color:rgb(249,249,249)"><br></span></div>-- <br><div class=
=3D"gmail_signature">&quot;Have you taken yourself seriously today?&quot; -=
- the gravity clown</div>
</div></div>

--001a1146311ab54ea90545d21854--
0
davidnicol
1/11/2017 2:05:42 PM
perl.perl5.porters 46290 articles. 0 followers. Follow

10 Replies
29 Views

Similar Articles

[PageSpeed] 5


On 01/11/2017 03:05 PM, David Nicol wrote:
>
>
> On Sun, Jan 8, 2017 at 12:22 PM, Sawyer X <xsawyerx@gmail.com
> <mailto:xsawyerx@gmail.com>> wrote:
>
>     * Use of bare << to mean <<"" is deprecated: Deprecated in 5.000,
>     remove
>     in 5.28.0.
>
>
> does this mean that after 5.28, whitespace between the chevron and the
> terminator will be allowed, or does it mean something else?
>
> Currently the following will warn, then crash: Bareword found where
> operator expected, near "T6TOR"
>
>
> print << T6TOR;
> this is the only situation when I ever see that $warning
> T6TOR 

The problem here is that you have a space and you haven't quoted T6TOR.
What perl understood is that are not using T6TOR as your terminator, but
that instead you have a bare terminator. Once it had finished the
HEREDOC, it tries to run the T6TOR as a bareword and you have that error
(because it isn't a function, for example).

To be clearer:

print << "WORD"; # <- Terminator is quoted here
....
WORD

print <<WORD; # <- Terminator not quoted here, but since there is no
space, it's understood
....
WORD

print << # <- No terminator, as in "bare <<", deprecated since 1996.
....


print << WORD; # <- You want "WORD" to be the terminator but because
it's not quoted and there's a space, perl reads it as bare << with
"WORD" being some bareword after the HEREDOC
....
WORD


>
>
> also, unrelated, do we allow 《and the like to stand in for << yet?

No that I know. To be honest, I personally dislike seeing Unicode
characters as syntax and have no special interest in making this happen.
0
xsawyerx
1/14/2017 4:35:59 PM
--94eb2c089e6a970b4a0546128097
Content-Type: text/plain; charset=UTF-8

On Sat, Jan 14, 2017 at 10:35 AM, Sawyer X <xsawyerx@gmail.com> wrote:

>
>
> On 01/11/2017 03:05 PM, David Nicol wrote:
> >
> >
> > On Sun, Jan 8, 2017 at 12:22 PM, Sawyer X <xsawyerx@gmail.com
> > <mailto:xsawyerx@gmail.com>> wrote:
> >
> >     * Use of bare << to mean <<"" is deprecated: Deprecated in 5.000,
> >     remove
> >     in 5.28.0.
> >
> >
> > does this mean that after 5.28, whitespace between the chevron and the
> > terminator will be allowed, or does it mean something else?
> >
> > Currently the following will warn, then crash: Bareword found where
> > operator expected, near "T6TOR"
> >
> >
> > print << T6TOR;
> > this is the only situation when I ever see that $warning
> > T6TOR
>
> The problem here is that you have a space and you haven't quoted T6TOR.
> What perl understood is that are not using T6TOR as your terminator, but
> that instead you have a bare terminator. Once it had finished the
> HEREDOC, it tries to run the T6TOR as a bareword and you have that error
> (because it isn't a function, for example)
>

Yes, exactly. My question is if we remove the "feature" of having an empty
terminator, will white space then be allowed after the chevron. I once
submitted a patch, to this list, that caused white space to be allowed
after the chevron, before a terminating bareword, unless the bareword is an
infix operator, so I know it's possible. Whitespace /is/ currently allowed
when the terminator is quoted:

   print <<        "QT6TOR";
this gets quoted, with trailing EOL
QT6TOR

works fine. Only undecorated terminators get misinterpreted.


-- 
"Have you taken yourself seriously today?" -- the gravity clown

--94eb2c089e6a970b4a0546128097
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><div class=3D"gmail_quo=
te">On Sat, Jan 14, 2017 at 10:35 AM, Sawyer X <span dir=3D"ltr">&lt;<a hre=
f=3D"mailto:xsawyerx@gmail.com" target=3D"_blank">xsawyerx@gmail.com</a>&gt=
;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 =
..8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=3D""><br>
<br>
On 01/11/2017 03:05 PM, David Nicol wrote:<br>
&gt;<br>
&gt;<br>
&gt; On Sun, Jan 8, 2017 at 12:22 PM, Sawyer X &lt;<a href=3D"mailto:xsawye=
rx@gmail.com">xsawyerx@gmail.com</a><br>
</span><span class=3D"">&gt; &lt;mailto:<a href=3D"mailto:xsawyerx@gmail.co=
m">xsawyerx@gmail.com</a>&gt;&gt; wrote:<br>
&gt;<br>
&gt;=C2=A0 =C2=A0 =C2=A0* Use of bare &lt;&lt; to mean &lt;&lt;&quot;&quot;=
 is deprecated: Deprecated in 5.000,<br>
&gt;=C2=A0 =C2=A0 =C2=A0remove<br>
&gt;=C2=A0 =C2=A0 =C2=A0in 5.28.0.<br>
&gt;<br>
&gt;<br>
&gt; does this mean that after 5.28, whitespace between the chevron and the=
<br>
&gt; terminator will be allowed, or does it mean something else?<br>
&gt;<br>
&gt; Currently the following will warn, then crash: Bareword found where<br=
>
&gt; operator expected, near &quot;T6TOR&quot;<br>
&gt;<br>
&gt;<br>
&gt; print &lt;&lt; T6TOR;<br>
&gt; this is the only situation when I ever see that $warning<br>
&gt; T6TOR<br>
<br>
</span>The problem here is that you have a space and you haven&#39;t quoted=
 T6TOR.<br>
What perl understood is that are not using T6TOR as your terminator, but<br=
>
that instead you have a bare terminator. Once it had finished the<br>
HEREDOC, it tries to run the T6TOR as a bareword and you have that error<br=
>
(because it isn&#39;t a function, for example)<br></blockquote><div><br></d=
iv><div>Yes, exactly. My question is if we remove the &quot;feature&quot; o=
f having an empty terminator, will white space then be allowed after the ch=
evron. I once submitted a patch, to this list, that caused white space to b=
e allowed after the chevron, before a terminating bareword, unless the bare=
word is an infix operator, so I know it&#39;s possible. Whitespace /is/ cur=
rently allowed when the terminator is quoted:</div><div><br></div><div>=C2=
=A0 =C2=A0print &lt;&lt; =C2=A0 =C2=A0 =C2=A0 =C2=A0&quot;QT6TOR&quot;;</di=
v><div>this gets quoted, with trailing EOL</div><div>QT6TOR</div><div><br><=
/div><div>works fine. Only undecorated terminators get misinterpreted.</div=
></div><br clear=3D"all"><div><br></div>-- <br><div class=3D"gmail_signatur=
e" data-smartmail=3D"gmail_signature">&quot;Have you taken yourself serious=
ly today?&quot; -- the gravity clown</div>
</div></div>

--94eb2c089e6a970b4a0546128097--
0
davidnicol
1/14/2017 6:56:03 PM

On 01/14/2017 07:56 PM, David Nicol wrote:
>
>
> On Sat, Jan 14, 2017 at 10:35 AM, Sawyer X <xsawyerx@gmail.com
> <mailto:xsawyerx@gmail.com>> wrote:
>
>
>
>     On 01/11/2017 03:05 PM, David Nicol wrote:
>     >
>     >
>     > On Sun, Jan 8, 2017 at 12:22 PM, Sawyer X <xsawyerx@gmail.com
>     <mailto:xsawyerx@gmail.com>
>     > <mailto:xsawyerx@gmail.com <mailto:xsawyerx@gmail.com>>> wrote:
>     >
>     >     * Use of bare << to mean <<"" is deprecated: Deprecated in
>     5.000,
>     >     remove
>     >     in 5.28.0.
>     >
>     >
>     > does this mean that after 5.28, whitespace between the chevron
>     and the
>     > terminator will be allowed, or does it mean something else?
>     >
>     > Currently the following will warn, then crash: Bareword found where
>     > operator expected, near "T6TOR"
>     >
>     >
>     > print << T6TOR;
>     > this is the only situation when I ever see that $warning
>     > T6TOR
>
>     The problem here is that you have a space and you haven't quoted
>     T6TOR.
>     What perl understood is that are not using T6TOR as your
>     terminator, but
>     that instead you have a bare terminator. Once it had finished the
>     HEREDOC, it tries to run the T6TOR as a bareword and you have that
>     error
>     (because it isn't a function, for example)
>
>
> Yes, exactly.

Right. Sorry for explaining what you already know. I misunderstood your
question.

> My question is if we remove the "feature" of having an empty
> terminator, will white space then be allowed after the chevron.

This wasn't discussed, to be honest.

I'm personally not in favor in proliferating the usage of bareword
heredoc terminators, even if we can make that simpler.

> I once submitted a patch, to this list, that caused white space to be
> allowed after the chevron, before a terminating bareword, unless the
> bareword is an infix operator, so I know it's possible. Whitespace
> /is/ currently allowed when the terminator is quoted:
>
>    print <<        "QT6TOR";
> this gets quoted, with trailing EOL
> QT6TOR
>
> works fine. Only undecorated terminators get misinterpreted.
>
0
xsawyerx
1/14/2017 7:53:44 PM
--001a11c0168cf6a87a05461ad9a5
Content-Type: text/plain; charset=UTF-8

On Sat, Jan 14, 2017 at 1:53 PM, Sawyer X <xsawyerx@gmail.com> wrote:

> On 01/14/2017 07:56 PM, David Nicol wrote:
>
> > My question is if we remove the "feature" of having an empty
> > terminator, will white space then be allowed after the chevron.
>
> This wasn't discussed, to be honest.
>
> I'm personally not in favor in proliferating the usage of bareword
> heredoc terminators, even if we can make that simpler.
>
> > I once submitted a patch, to this list, that caused white space to be
> > allowed after the chevron, before a terminating bareword, unless the
> > bareword is an infix operator, so I know it's possible. Whitespace
> > /is/ currently allowed when the terminator is quoted:
> >
> >    print <<        "QT6TOR";
> > this gets quoted, with trailing EOL
> > QT6TOR
> >
> > works fine. Only undecorated terminators get misinterpreted.
>

the warning could be removed by simply undeprecating the feature; were that
undeprecation to happen simultaneously with limiting the empty-terminator
feature so
that it only triggers when the chevron is followed by punctuation, a
newline, or an infix operator, and whitespace was allowed between the
chevron and a bareword heredoc terminator, in my opinion that would be
ideal. No old working code would break, and the situation that produces the
warning (which is mystifying to beginners) would instead do what is meant.

The patch I submitted in July 2009 is available for reconsideration at
http://tipjar.com/perlhacking/heredocpatch_revised.txt

it includes revising the deprecation warning to an "are you sure" kind of
warning, pointing out that << has been interpreted as introducing an
empty-line-terminated heredoc, without being all judgemental about it.





-- 
"Have you taken yourself seriously today?" -- the gravity clown

--001a11c0168cf6a87a05461ad9a5
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><div class=3D"gmail_quo=
te">On Sat, Jan 14, 2017 at 1:53 PM, Sawyer X <span dir=3D"ltr">&lt;<a href=
=3D"mailto:xsawyerx@gmail.com" target=3D"_blank">xsawyerx@gmail.com</a>&gt;=
</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px=
 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-=
left-style:solid;padding-left:1ex"><span class=3D"gmail-">On 01/14/2017 07:=
56 PM, David Nicol wrote:<br></span><span class=3D"gmail-"><br>
&gt; My question is if we remove the &quot;feature&quot; of having an empty=
<br>
&gt; terminator, will white space then be allowed after the chevron.<br>
<br>
</span>This wasn&#39;t discussed, to be honest.<br>
<br>
I&#39;m personally not in favor in proliferating the usage of bareword<br>
heredoc terminators, even if we can make that simpler.<br>
<div class=3D"gmail-HOEnZb"><div class=3D"gmail-h5"><br>
&gt; I once submitted a patch, to this list, that caused white space to be<=
br>
&gt; allowed after the chevron, before a terminating bareword, unless the<b=
r>
&gt; bareword is an infix operator, so I know it&#39;s possible. Whitespace=
<br>
&gt; /is/ currently allowed when the terminator is quoted:<br>
&gt;<br>
&gt;=C2=A0 =C2=A0 print &lt;&lt;=C2=A0 =C2=A0 =C2=A0 =C2=A0 &quot;QT6TOR&qu=
ot;;<br>
&gt; this gets quoted, with trailing EOL<br>
&gt; QT6TOR<br>
&gt;<br>
&gt; works fine. Only undecorated terminators get misinterpreted.<br></div>=
</div></blockquote><div><br></div><div>the warning could be removed by simp=
ly undeprecating the feature; were that undeprecation to happen simultaneou=
sly with limiting the empty-terminator feature so</div><div>that it only tr=
iggers when the chevron is followed by punctuation, a newline, or an infix =
operator, and whitespace was allowed between the chevron and a bareword her=
edoc terminator, in my opinion that would be ideal. No old working code wou=
ld break, and the situation that produces the warning (which is mystifying =
to beginners) would instead do what is meant.</div><div><br></div><div>The =
patch I submitted in July 2009 is available for reconsideration at=C2=A0<a =
href=3D"http://tipjar.com/perlhacking/heredocpatch_revised.txt">http://tipj=
ar.com/perlhacking/heredocpatch_revised.txt</a></div><div><br></div><div>it=
 includes revising the deprecation warning to an &quot;are you sure&quot; k=
ind of warning, pointing out that &lt;&lt; has been interpreted as introduc=
ing an empty-line-terminated heredoc, without being all judgemental about i=
t.</div><div><br></div><div><br></div></div><br><br clear=3D"all"><div><br>=
</div>-- <br><div class=3D"gmail_signature">&quot;Have you taken yourself s=
eriously today?&quot; -- the gravity clown</div>
</div></div>

--001a11c0168cf6a87a05461ad9a5--
0
davidnicol
1/15/2017 4:53:42 AM

On 01/15/2017 05:53 AM, David Nicol wrote:
>
>
> On Sat, Jan 14, 2017 at 1:53 PM, Sawyer X <xsawyerx@gmail.com
> <mailto:xsawyerx@gmail.com>> wrote:
>
>     On 01/14/2017 07:56 PM, David Nicol wrote:
>
>     > My question is if we remove the "feature" of having an empty
>     > terminator, will white space then be allowed after the chevron.
>
>     This wasn't discussed, to be honest.
>
>     I'm personally not in favor in proliferating the usage of bareword
>     heredoc terminators, even if we can make that simpler.
>
>     > I once submitted a patch, to this list, that caused white space
>     to be
>     > allowed after the chevron, before a terminating bareword, unless the
>     > bareword is an infix operator, so I know it's possible. Whitespace
>     > /is/ currently allowed when the terminator is quoted:
>     >
>     >    print <<        "QT6TOR";
>     > this gets quoted, with trailing EOL
>     > QT6TOR
>     >
>     > works fine. Only undecorated terminators get misinterpreted.
>
>
> the warning could be removed by simply undeprecating the feature; were
> that undeprecation to happen simultaneously with limiting the
> empty-terminator feature so
> that it only triggers when the chevron is followed by punctuation, a
> newline, or an infix operator, and whitespace was allowed between the
> chevron and a bareword heredoc terminator, in my opinion that would be
> ideal. No old working code would break, and the situation that
> produces the warning (which is mystifying to beginners) would instead
> do what is meant.
>
> The patch I submitted in July 2009 is available for reconsideration
> at http://tipjar.com/perlhacking/heredocpatch_revised.txt

I think there are two good ways to move forward on this:
* Create a new thread to debate this change.
* Resubmit this patch, rebased.

I think the former is better because it would possibly avoid any wasted
efforts in case we decide not to make this change or to revise the patch.

I would be happy to leave this thread to any questions regarding just
the deprecation list published, if that's okay.


>
> it includes revising the deprecation warning to an "are you sure" kind
> of warning, pointing out that << has been interpreted as introducing
> an empty-line-terminated heredoc, without being all judgemental about it.

+1 for friendly warnings. :)
0
xsawyerx
1/15/2017 10:34:37 AM
--001a113f8bd245bd090546250757
Content-Type: text/plain; charset=UTF-8

On Sun, Jan 15, 2017 at 4:34 AM, Sawyer X <xsawyerx@gmail.com> wrote:
>
> On 01/15/2017 05:53 AM, David Nicol wrote:



> > The patch I submitted in July 2009 is available for reconsideration
> > at http://tipjar.com/perlhacking/heredocpatch_revised.txt
>
> I think there are two good ways to move forward on this:
> * Create a new thread to debate this change.
> * Resubmit this patch, rebased.
>
> I think the former is better because it would possibly avoid any wasted
> efforts in case we decide not to make this change or to revise the patch.
>
> I would be happy to leave this thread to any questions regarding just
> the deprecation list published, if that's okay.
>

(1) I did change the subject line on Wednesday.
(2) I am reluctant to rebase the patch without an assurance that it will be
applied. I do not recall the specific objections it received in 2009, but
it clearly was not applied then.

--001a113f8bd245bd090546250757
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><div class=3D"gmail_quo=
te">On Sun, Jan 15, 2017 at 4:34 AM, Sawyer X <span dir=3D"ltr">&lt;<a href=
=3D"mailto:xsawyerx@gmail.com" target=3D"_blank">xsawyerx@gmail.com</a>&gt;=
</span> wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;=
border-left:1px #ccc solid;padding-left:1ex"><span class=3D"">
On 01/15/2017 05:53 AM, David Nicol wrote:</span></blockquote><div>=C2=A0</=
div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-lef=
t:1px #ccc solid;padding-left:1ex"><div><div class=3D"h5">
&gt; The patch I submitted in July 2009 is available for reconsideration<br=
>
&gt; at <a href=3D"http://tipjar.com/perlhacking/heredocpatch_revised.txt" =
rel=3D"noreferrer" target=3D"_blank">http://tipjar.com/perlhacking/<wbr>her=
edocpatch_revised.txt</a><br>
<br>
</div></div>I think there are two good ways to move forward on this:<br>
* Create a new thread to debate this change.<br>
* Resubmit this patch, rebased.<br>
<br>
I think the former is better because it would possibly avoid any wasted<br>
efforts in case we decide not to make this change or to revise the patch.<b=
r>
<br>
I would be happy to leave this thread to any questions regarding just<br>
the deprecation list published, if that&#39;s okay.<br></blockquote><div><b=
r></div><div>(1) I did change the subject line on Wednesday.</div><div>(2) =
I am reluctant to rebase the patch without an assurance that it will be app=
lied. I do not recall the specific objections it received in 2009, but it c=
learly was not applied then.</div><div><br></div></div>
</div></div>

--001a113f8bd245bd090546250757--
0
davidnicol
1/15/2017 5:02:12 PM
--001a1141482c20299305463a9af3
Content-Type: text/plain; charset=UTF-8

On Sun, Jan 15, 2017 at 6:02 PM, David Nicol <davidnicol@gmail.com> wrote:
>
> (1) I did change the subject line on Wednesday.
> (2) I am reluctant to rebase the patch without an assurance that it will
> be applied. I do not recall the specific objections it received in 2009,
> but it clearly was not applied then.
>

No one will give you any assurance about applying any patch before it has
been proven to work. That's not how things work.

Leon

--001a1141482c20299305463a9af3
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On S=
un, Jan 15, 2017 at 6:02 PM, David Nicol <span dir=3D"ltr">&lt;<a href=3D"m=
ailto:davidnicol@gmail.com" target=3D"_blank">davidnicol@gmail.com</a>&gt;<=
/span> wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;b=
order-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div class=3D"=
gmail_extra"><span class=3D""></span><div>(1) I did change the subject line=
 on Wednesday.</div><div>(2) I am reluctant to rebase the patch without an =
assurance that it will be applied. I do not recall the specific objections =
it received in 2009, but it clearly was not applied then.</div>
</div></div>
</blockquote></div><br></div><div class=3D"gmail_extra">No one will give yo=
u any assurance about applying any patch before it has been proven to work.=
 That&#39;s not how things work.<br><br></div><div class=3D"gmail_extra">Le=
on<br></div></div>

--001a1141482c20299305463a9af3--
0
fawaka
1/16/2017 6:46:10 PM
--001a1144c4743c7dd305463b74cd
Content-Type: text/plain; charset=UTF-8

And that's not what I'm asking for.

In the past, I have submitted patches implementing features I understood
were desired, including test cases, and proof that the new feature worked,
and such patches have not been applied. The best example of this is when I
offered a patch to make sort in scalar context return a sortedness ratio,
which turned out to have been a joke. It appears that in 2009 I crafted a
patch to allow spaces between the << and an unquoted terminator, under the
impression that that feature was something which would be applied, and I
discovered I was mistaken.

I'm not asking for "assurance about applying any patch before it has been
proven to work" -- that's ridiculous and I'm actually a little insulted
that you misconstrued me to be requesting such -- I'm asking for
verification that the feature is desired by people with the power to apply
a working patch, which would be that 2009 work, rebased, before taking the
two or three hours of scant free time to review and rebase it against the
current heredoc parsing code, which has possibly changed considerably in
the ensuing six and a half years.

The feature looks ahead after a << in a position that might indicate a
heredoc rather than a shift operator, which is current behavior. What
happens differently is, when the next token is a bareword that is not a
keyword that takes a left argument (for instance C<cmp>) that bareword is
interpreted as a heredoc terminator, just as if it was flush against the
right of the <<. That is, it restricts the situation where <<[space] is
interpreted as introducing a null-terminated heredoc to situations where
that is more likely to be what the programmer intended: followed, after the
space, by syntax other than a quote of some kind -- apostrophe, quote, or
backtick -- or by a keyword that binds left.

A fine example of a left-binding keyword is C<if>:

       print << if rand > 0.5;
this will print half the time

__END__

will still work,  while

       print << BARETERM if rand > 0.5;
this will print half the time
BARETERM
__END__

will DWIM instead of crashing on BARETERM being undefined, after giving a
mystifying warning about << "" being deprecated.


Additionally, the patch changed the warning, from a deprecation warning to
an optional syntax warning. As a group has reviewed all the deprecation
warnings and listed that one for retirement (returning the null terminator
feature to undeprecated status?) this seems like a fine time to reintroduce
the proposal, and yes I'm willing to rebase my 2009 patch, if, once it has
been demonstrated to work, and passed the various other appropriate
scrutinization, it will get applied.

The question is, is this something that people with the power to apply
patches want, or not?




On Mon, Jan 16, 2017 at 12:46 PM, Leon Timmermans <fawaka@gmail.com> wrote:

>
> No one will give you any assurance about applying any patch before it has
> been proven to work. That's not how things work.
>
> Leon
>



-- 
"The best MLK memorial is an integrated playground" -- the gravity clown

--001a1144c4743c7dd305463b74cd
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">And that&#39;s not what I&#39;m asking for.<div><br></div>=
<div>In the past, I have submitted patches implementing features I understo=
od were desired, including test cases, and proof that the new feature worke=
d, and such patches have not been applied. The best example of this is when=
 I offered a patch to make sort in scalar context return a sortedness ratio=
, which turned out to have been a joke. It appears that in 2009 I crafted a=
 patch to allow spaces between the &lt;&lt; and an unquoted terminator, und=
er the impression that that feature was something which would be applied, a=
nd I discovered I was mistaken.</div><div><br></div><div>I&#39;m not asking=
 for &quot;<span style=3D"font-size:12.8px">assurance about applying any pa=
tch before it has been proven to work&quot; -- that&#39;s ridiculous and I&=
#39;m actually a little insulted that you misconstrued me to be requesting =
such -- I&#39;m asking for verification that the feature is desired by peop=
le with the power to apply a working patch, which would be that 2009 work, =
rebased, before taking the two or three hours of scant free time to review =
and rebase it against the current heredoc parsing code, which has possibly =
changed considerably in the ensuing six and a half years.</span></div><div>=
<span style=3D"font-size:12.8px"><br></span></div><div><span style=3D"font-=
size:12.8px">The feature looks ahead after a &lt;&lt; in a position that mi=
ght indicate a heredoc rather than a shift operator, which is current behav=
ior. What happens differently is, when the next token is a bareword that is=
 not a keyword that takes a left argument (for instance C&lt;cmp&gt;) that =
bareword is interpreted as a heredoc terminator, just as if it was flush ag=
ainst the right of the &lt;&lt;. That is, it restricts the situation where =
&lt;&lt;[space] is interpreted as introducing a null-terminated heredoc to =
situations where that is more likely to be what the programmer intended: fo=
llowed, after the space, by syntax other than a quote of some kind -- apost=
rophe, quote, or backtick -- or by a keyword that binds left.</span></div><=
div><span style=3D"font-size:12.8px"><br></span></div><div><span style=3D"f=
ont-size:12.8px">A fine example of a left-binding keyword is C&lt;if&gt;:</=
span></div><div><span style=3D"font-size:12.8px"><br></span></div><div><spa=
n style=3D"font-size:12.8px">=C2=A0 =C2=A0 =C2=A0 =C2=A0print &lt;&lt; if r=
and &gt; 0.5;</span></div><div><span style=3D"font-size:12.8px">this will p=
rint half the time</span></div><div><span style=3D"font-size:12.8px"><br></=
span></div><div><span style=3D"font-size:12.8px">__END__</span></div><div><=
span style=3D"font-size:12.8px"><br></span></div><div><span style=3D"font-s=
ize:12.8px">will still work, =C2=A0while</span></div><div><span style=3D"fo=
nt-size:12.8px"><br></span></div><div><div><span style=3D"font-size:12.8px"=
>=C2=A0 =C2=A0 =C2=A0 =C2=A0print &lt;&lt; BARETERM if rand &gt; 0.5;</span=
></div><div><span style=3D"font-size:12.8px">this will print half the time<=
/span></div><div><span style=3D"font-size:12.8px">BARETERM</span></div><div=
><span style=3D"font-size:12.8px">__END__</span></div><div><span style=3D"f=
ont-size:12.8px"><br></span></div></div><div><span style=3D"font-size:12.8p=
x">will DWIM instead of crashing on BARETERM being undefined, after giving =
a mystifying warning about &lt;&lt; &quot;&quot; being deprecated.</span></=
div><div><span style=3D"font-size:12.8px"><br></span></div><div><span style=
=3D"font-size:12.8px"><br></span></div><div><span style=3D"font-size:12.8px=
">Additionally, the patch changed the warning, from a deprecation warning t=
o an optional syntax warning. As a group has reviewed all the deprecation w=
arnings and listed that one for retirement (returning the null terminator f=
eature to undeprecated status?) this seems like a fine time to reintroduce =
the proposal, and yes I&#39;m willing to rebase my 2009 patch, if, once it =
has been demonstrated to work, and passed the various other appropriate scr=
utinization, it will get applied.</span></div><div><span style=3D"font-size=
:12.8px"><br></span></div><div><span style=3D"font-size:12.8px">The questio=
n is, is this something that people with the power to apply patches want, o=
r not?</span></div><div><span style=3D"font-size:12.8px"><br></span></div><=
div><span style=3D"font-size:12.8px"><br></span></div><div><span style=3D"f=
ont-size:12.8px"><br></span></div><div class=3D"gmail_extra"><br><div class=
=3D"gmail_quote">On Mon, Jan 16, 2017 at 12:46 PM, Leon Timmermans <span di=
r=3D"ltr">&lt;<a href=3D"mailto:fawaka@gmail.com" target=3D"_blank">fawaka@=
gmail.com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=
=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=
=3D"ltr"><span class=3D""><div class=3D"gmail_extra"><div class=3D"gmail_qu=
ote"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-le=
ft:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_ex=
tra">
</div></div>
</blockquote></div><br></div></span><div class=3D"gmail_extra">No one will =
give you any assurance about applying any patch before it has been proven t=
o work. That&#39;s not how things work.<span class=3D"HOEnZb"><font color=
=3D"#888888"><br><br></font></span></div><span class=3D"HOEnZb"><font color=
=3D"#888888"><div class=3D"gmail_extra">Leon<br></div></font></span></div>
</blockquote></div><br><br clear=3D"all"><div><br></div>-- <br><div class=
=3D"gmail_signature" data-smartmail=3D"gmail_signature">&quot;The best MLK =
memorial is an integrated playground&quot; -- the gravity clown</div>
</div></div>

--001a1144c4743c7dd305463b74cd--
0
davidnicol
1/16/2017 7:47:29 PM
[top-posted]

I'm not sure we can make a decision about this yet. If and when we
remove the fatalization of the bare heredoc terminator, only then we can
decide on whether we wish to allow terminators with leading spaces or
not. Once we decide, we can call a "yes" or "no" on such a patch, be it
this one or a revised one. I'm personally not in a rush to determine
this now but I'll put this on my review list for the future.

I'm sorry we do not have an immediate answer for this for you. I
understand why you rather not to put work into it without knowing this
is a desired change.

On 01/16/2017 08:47 PM, David Nicol wrote:
> And that's not what I'm asking for.
>
> In the past, I have submitted patches implementing features I
> understood were desired, including test cases, and proof that the new
> feature worked, and such patches have not been applied. The best
> example of this is when I offered a patch to make sort in scalar
> context return a sortedness ratio, which turned out to have been a
> joke. It appears that in 2009 I crafted a patch to allow spaces
> between the << and an unquoted terminator, under the impression that
> that feature was something which would be applied, and I discovered I
> was mistaken.
>
> I'm not asking for "assurance about applying any patch before it has
> been proven to work" -- that's ridiculous and I'm actually a little
> insulted that you misconstrued me to be requesting such -- I'm asking
> for verification that the feature is desired by people with the power
> to apply a working patch, which would be that 2009 work, rebased,
> before taking the two or three hours of scant free time to review and
> rebase it against the current heredoc parsing code, which has possibly
> changed considerably in the ensuing six and a half years.
>
> The feature looks ahead after a << in a position that might indicate a
> heredoc rather than a shift operator, which is current behavior. What
> happens differently is, when the next token is a bareword that is not
> a keyword that takes a left argument (for instance C<cmp>) that
> bareword is interpreted as a heredoc terminator, just as if it was
> flush against the right of the <<. That is, it restricts the situation
> where <<[space] is interpreted as introducing a null-terminated
> heredoc to situations where that is more likely to be what the
> programmer intended: followed, after the space, by syntax other than a
> quote of some kind -- apostrophe, quote, or backtick -- or by a
> keyword that binds left.
>
> A fine example of a left-binding keyword is C<if>:
>
>        print << if rand > 0.5;
> this will print half the time
>
> __END__
>
> will still work,  while
>
>        print << BARETERM if rand > 0.5;
> this will print half the time
> BARETERM
> __END__
>
> will DWIM instead of crashing on BARETERM being undefined, after
> giving a mystifying warning about << "" being deprecated.
>
>
> Additionally, the patch changed the warning, from a deprecation
> warning to an optional syntax warning. As a group has reviewed all the
> deprecation warnings and listed that one for retirement (returning the
> null terminator feature to undeprecated status?) this seems like a
> fine time to reintroduce the proposal, and yes I'm willing to rebase
> my 2009 patch, if, once it has been demonstrated to work, and passed
> the various other appropriate scrutinization, it will get applied.
>
> The question is, is this something that people with the power to apply
> patches want, or not?
>
>
>
>
> On Mon, Jan 16, 2017 at 12:46 PM, Leon Timmermans <fawaka@gmail.com
> <mailto:fawaka@gmail.com>> wrote:
>
>
>     No one will give you any assurance about applying any patch before
>     it has been proven to work. That's not how things work.
>
>     Leon
>
>
>
>
> -- 
> "The best MLK memorial is an integrated playground" -- the gravity clown
0
xsawyerx
1/17/2017 8:56:49 PM
--001a11431eb697ac04054650ba88
Content-Type: text/plain; charset=UTF-8

like Abigail pointed out, we've got a year and a half to decide what
removing all the warnings means.

I'm in favor of (1) removing the warning (2) leaving the feature in (3)
allowing space before unquoted terminators (and backslash-prefixed unquoted
terminators, too, which isn't even documented anywhere outside of the tests
for it, IIRC)

In the event that becomes the consensus, I'll be happy to rebase my patch.



On Tue, Jan 17, 2017 at 2:56 PM, Sawyer X <xsawyerx@gmail.com> wrote:

> [top-posted]
>
> I'm not sure we can make a decision about this yet. If and when we
> remove the fatalization of the bare heredoc terminator,


it's currently not fatal -- it seems like it is though because the feature
only ever gets parsed
in situations where it isn't what the coder meant. Used correctly, the bare
terminator is a nifty
little trick that saves keystrokes for QUADs, and there's no telling how
much running code relies on it.



> > A fine example of a left-binding keyword is C<if>:
> >
> >        print << if rand > 0.5;
> > this will print half the time
> >
> > __END__
> > --
> > "The best MLK memorial is an integrated playground" -- the gravity clown
>
-- 
"Have you taken yourself seriously today?" -- the gravity clown

--001a11431eb697ac04054650ba88
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">like Abigail pointed out, we&#39;ve got a year and a half =
to decide what removing all the warnings means.<div><br></div><div>I&#39;m =
in favor of (1) removing the warning (2) leaving the feature in (3) allowin=
g space before unquoted terminators (and backslash-prefixed unquoted termin=
ators, too, which isn&#39;t even documented anywhere outside of the tests f=
or it, IIRC)</div><div><br></div><div>In the event that becomes the consens=
us, I&#39;ll be happy to rebase my patch.</div><div><br></div><div><br></di=
v><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">On Tue, Jan 17,=
 2017 at 2:56 PM, Sawyer X <span dir=3D"ltr">&lt;<a href=3D"mailto:xsawyerx=
@gmail.com" target=3D"_blank">xsawyerx@gmail.com</a>&gt;</span> wrote:<br><=
blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px=
 #ccc solid;padding-left:1ex">[top-posted]<br>
<br>
I&#39;m not sure we can make a decision about this yet. If and when we<br>
remove the fatalization of the bare heredoc terminator,</blockquote><div><b=
r></div><div>it&#39;s currently not fatal -- it seems like it is though bec=
ause the feature only ever gets parsed</div><div>in situations where it isn=
&#39;t what the coder meant. Used correctly, the bare terminator is a nifty=
</div><div>little trick that saves keystrokes for QUADs, and there&#39;s no=
 telling how much running code relies on it.</div><div><br></div><div>=C2=
=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;borde=
r-left:1px #ccc solid;padding-left:1ex"><div class=3D"HOEnZb"><div class=3D=
"h5">
&gt; A fine example of a left-binding keyword is C&lt;if&gt;:<br>
&gt;<br>
&gt;=C2=A0 =C2=A0 =C2=A0 =C2=A0 print &lt;&lt; if rand &gt; 0.5;<br>
&gt; this will print half the time<br>
&gt;<br>
&gt; __END__<br></div></div><div class=3D"HOEnZb"><div class=3D"h5">
&gt; --<br>
&gt; &quot;The best MLK memorial is an integrated playground&quot; -- the g=
ravity clown<br></div></div></blockquote></div>-- <br><div class=3D"gmail_s=
ignature" data-smartmail=3D"gmail_signature">&quot;Have you taken yourself =
seriously today?&quot; -- the gravity clown</div>
</div></div>

--001a11431eb697ac04054650ba88--
0
davidnicol
1/17/2017 9:10:24 PM
Reply: