Larry Wall wrote:
> A less obvious strategy is to try to see where various marginal
> features could be subsumed under some more powerful feature.
In general, this is a good^Wgreat concept to avoid multitudinous small features.
> To some extent,
I'm glad you qualified this...
> you see this with the ability to use pod for multiline
> comments.
There's a certain relationship between documentation via pod and documentation
via comments. If pod and comments could be totally unified, this might be a
good idea. But they already have separate syntaxes: so unifying them would
require changes to one or both. Without total unification and uniform syntax
for both, I think it better to leave comments and pod as separate features:
documentation for publication is often at a different level, and better not
mixed with internals documentation anyway: the different syntaxes for code, pod,
and comments helps the author keep them visually separate.
> For embedded comments, we might rather see some kind of
> macro facility that could turn qc// or any other quoted form into a
> list of zero or more tokens.
There's a number of us that have been arguing about that topic. We wish the
-mlc list would become responsive. While a function style or quoted form
comment might seem clever, and even Perlish due to its syntax, it doesn't help
the author of the code/comments readily distinguish them. What good are
comments if you can't find them when you need them?
> Larry
--
Glenn
=====
There are two kinds of people, those
who finish what they start, and so
on... -- Robert Byrne
_______________________________________________
Why pay for something you could get for free?
NetZero provides FREE Internet Access and Email
http://www.netzero.net/download/index.html
