why is pod not allowed within expressions?

     if (something() and

=head3  Additional Check
we check for something_additional now, in addition to just
something
=cut

        something_additional()){
                ...

fails.

Is this by design?

-- 
"Simplicity is one of the most misunderstood concepts
in programming" -- Matz

"David Nicol" <davidnicolgmail.com> writes:

>      if (something() and
>
> =head3  Additional Check
> we check for something_additional now, in addition to
just something
> =cut
>
>         something_additional()){
>                 ...
>
> fails.
>
> Is this by design?

Consider this:

---- snip ----
sub head3() { }

my $x

=head3

;
---- snip ----

See?

-- Johan

On 8/16/07, David Nicol wrote:
>      if (something() and
>
> =head3  Additional Check
> we check for something_additional now, in addition to
just something
> =cut
>
>         something_additional()){
>                 ...
>
> fails.
>
> Is this by design?
>

Probably, since it's documented. From "perldoc
perlsyn", the section
titled "PODs: Embedded Documentation":

       Perl has a mechanism for intermixing documentation
with source code.
-->   While it's expecting the beginning of a new
statement, <--
       if the compiler encounters a line that
       begins with an equal sign and a word, like this

Cheers,
-- 
Offer Kaye

On 8/22/07, Offer Kaye <offer.kayegmail.com> wrote:
> [...] it's documented. From "perldoc
perlsyn", the section
> titled "PODs: Embedded Documentation":
>
>        Perl has a mechanism for intermixing
documentation with source code.
> -->   While it's expecting the beginning of a new
statement, <--
>        if the compiler encounters a line that
>        begins with an equal sign and a word, like this

Would anyone be into a patch that changed the test from
"While it's
expecting the beginning of a new statement" to
"Anywhere except
immediately following something that could be construed as
an l-value?"

Also included in this wishlist item would be a warning when
a line following
a l-value matches /^=w/.

I actually doubt anyone besides myself is routinely annoyed
by this.

David Nicol wrote:
> On 8/22/07, Offer Kaye <offer.kayegmail.com> wrote:
>   
>> [...] it's documented. From "perldoc
perlsyn", the section
>> titled "PODs: Embedded Documentation":
>>
>>        Perl has a mechanism for intermixing
documentation with source code.
>> -->   While it's expecting the beginning of a
new statement, <--
>>        if the compiler encounters a line that
>>        begins with an equal sign and a word, like
this
>>     
>
> Would anyone be into a patch that changed the test from
"While it's
> expecting the beginning of a new statement" to
"Anywhere except
> immediately following something that could be construed
as an l-value?"
>
> Also included in this wishlist item would be a warning
when a line following
> a l-value matches /^=w/.
>
> I actually doubt anyone besides myself is routinely
annoyed by this.
>
>
>   

Can you show a use-case where the pod / literate-programming
style
is materially improved ? 

A-priori, Id expect deeply embedded pod to be discussing the
code itself,
for which #comments are more appropriate.


<tangent>

Ive often wanted pod's line-wrap to be controllable - forex

=wrapat 4

    This Indented pod is rewrapped for display,
    in contrast to the current non-wrapping when the pod is
explicitly 
indented.
    Id find this style more readable (in the raw file) than
left-margin pod,
    without sacrificing the wrapping feature.

David Nicol wrote:
> On 8/22/07, Offer Kaye <offer.kayegmail.com> wrote:
>> [...] it's documented. From "perldoc
perlsyn", the section
>> titled "PODs: Embedded Documentation":
>>
>>        Perl has a mechanism for intermixing
documentation with source code.
>> -->   While it's expecting the beginning of a
new statement, <--
>>        if the compiler encounters a line that
>>        begins with an equal sign and a word, like
this
> 
> Would anyone be into a patch that changed the test from
"While it's
> expecting the beginning of a new statement" to
"Anywhere except
> immediately following something that could be construed
as an l-value?"

My fear would be that this would slow down compilation.  I'd
be interested to
see what happens.


> Also included in this wishlist item would be a warning
when a line following
> a l-value matches /^=w/.

Its not a syntax error?


-- 
Whip me, beat me, make my code compatible with VMS!

On 8/23/07, Jim Cromie wrote:
>
> Can you show a use-case where the pod /
literate-programming style
> is materially improved ?
>
> A-priori, Id expect deeply embedded pod to be
discussing the code itself,
> for which #comments are more appropriate.
>

I'm with Jim on this one. If only for
backwards-compatibility's sake.

But I am curious, does anyone know what was chosen for
Perl6? I know
there were a lot of discussions on the "new POD"
for Perl6, I just
don't know the details of what was decided, or if indeed any
final
syntax has been chosen...

Cheers,
-- 
Offer Kaye