Barrie Slaymaker <[EMAIL PROTECTED]> writes:
> If we document C<=for code>/C<=begin code> to do this, and tweak all the
> translators, I don't can live with it (I just want to use whatever
> syntax we cook up), but those do look like new two-word primitives to
> me, and strike me as being less clear to the person reading the code
> than C<=also for test foo.t>, especially given the C<=for test foo.t>
> likely to be hanging around nearby.
> It would save typing, but I personally don't give that a high priority
> (YMMV).
I've been thinking about this some more and I think I have a firmer grasp
on what you're proposing in terms of the POD language. Presenting it in
the RFC as part of a testing framework is actually a bit confusing, since
the impact of the primitive is a lot broader.
Currently, =for/=begin are exclusive; they name one or more output formats
the code is for and all others ignore them. What you're doing is
proposing a fundamentally different kind of translator, one that only
includes tagged paragraphs rather than defaulting to including everything,
and then adding a way to tag a paragraph as something that should be
included by that translator *as well as normal translators*.
This basic idea has other possible uses; one that I can think of
immediately is C<=also for abstract> which tags the following paragraph as
the abstract of the document and would let an abstract extractor pull it
out. (Note that this isn't suitable for indexes, since in general the
index text shouldn't be translated as part of the document.)
What I still don't like about the syntax is that C<=also for>, C<=also
begin>, and C<=also end> are really keywords in their own right; if we
implement these sorts of tags, I think we should avoid keywords that
contain spaces. Something like C<=alsofor> instead would be better, IMO.
The most abstracted way of viewing this is "paragraph tagging"; these new
keywords tag a bunch of POD input as being associated with some keyword
that special translators use. Viewed in that light, I can see the utility
(although I'd like to hammer down the definition; we've suffered a lot
from the fact that the way the argument to =for/=begin is treated is
rather ill-defined); it's worth considering whether =also is the best name
for it.
--
Russ Allbery ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/>
