One argument *against* intra-token-sequence multiline comments is that they
are harder to see, and thus render readers of the code more prone to
misunderstand it. Is this worth really promoting?
The extant pod-based multiline comment solution does not suffer from this,
as it is quite easy to see, owing to its column-zero constraint. It also
avoids the gnarly games that C programmers play of /* covertly placing */
comments midsequence in the token stream.
However, as currently employed, these pod comments *do* suffer from a couple
of potentially non-trivial problems in their own right. The more important
of these is that when you're done with a "=for commentary" or an "=end
commentary", you're not back in code mode. The other issue is that there is
no standardly accepted target name indicative of comment status, which means
that people's choices in this will not be predictable. Lack of predictability
hampers machine analysis, which is desirable for easy extraction (perhaps for
significant comments?) and so that the translators can casually ignore these
without remonstration.
Can we do something about this easily enough? I think so. Settling on one
pod target for multiline comments, and then defining the =for and =end of
that target to implicitly =cut back to code, would seem to address both of
these issues. Is there some reason that these funky punctuational and
easy-to-miss intra-sequential multiline comments are to be preferred over
this strategy?
As a quasi post script, that reminds me that *perhaps* pod is the way to go
as far as significant comments are concerned. If we don't get sufficiently
rich declarations of input and output types and ranges to happify the poor
tiny-active-working-set people with their expert-hostile, user-obsequious
IDEs, then we could probably painlessly stake out some structured pod
territory for this explicit purpose. This would have the advantage of
being backwards compatible, but perhaps one doesn't care so much in this
particular arena.
--tom
