Aaron Sherman asked:
> Should there be an explicit way to step this down to just parsing the bits
> that are called out as pod?
The original conception allowed for Pod to be independent of the
interleaved language. That has now been supplanted by a model that views
Pod as an integral part of Perl. There's definitely a trade-off there,
but one we've decided to make.
So, no, there are no longer any plans to extend Pod to documenting
*everything*, except so far as Perl 6 will be ale to subsume everything
(in line with Larry's musings of "braided languages").
> There is no explicit mention in the document as to what happens at the Perl
> level when the closing bracket is reached at a point that is not the end of
> a line (i.e. it is not followed by whitespace that contains a newline
> character). Here's an example:
>
> my $a #-[stop the presses!] = 4;
Except for the #~ instead of #=, that's valid (and documented) Perl 6.
That is, Pod comments work exactly like non-Pod comments.
As Synopsis 26 now states:
That is, declarator Pod blocks are syntactically like ordinary Perl 6
single-line comments and embedded comments.
>> * This new declarator block form is special. During source code parsing,
>> normal Pod blocks are simply appended into an array attribute of
>> surrounding Comment object in the AST (which is just $=POD, at the
>> top level). However declarator blocks are *also* appended to the
>> .WHY attribute of the declarator at the start of the most recent
>> (or immediately following) line.
>
> I'd very much like to establish that at default optimization levels for
> execution, this information is not guaranteed to be maintained past the
> creation of the AST.
Unfortunately, it is. Perl 6 defines that Perl 6 programs can always
access their own Pod at runtime (via $=POD). You probably can't even
optimize the information away in the absence of any compile-time
reference to $=POD, since there are plenty of symbolic ways to refer to
$=POD at run-time.
Damian
