> Wirt Atmar writes:
>
> >    1. If line begins with comment symbol, skip to next line immediately.

which does not preclude passing it through to the $STDLIST intact.

> >
> >    2. Line is scanned for "%" symbols. If found, and the macrovariable
is
> >determined to be legitimate, the macrovariable is excised and its value
> >substituted into the line.
> >...
> >which I will argue is the only
> >appropriate fashion for this kind of thing:
>
> It depends on the goals of the language. With Wirt's scanning sequence,
> it's not possible to comment out a line from within a macro definition.

I don't get your drift.  Is there no COMMENT structure within your macro
language?

> In addition, with Jeff's scheme, it's possible to pass the job output to
> a postprocessor that can interpret what's in the COMMENT statements to
> control further processing.

Given what I will call "proper" comment handling (just pass through to the
list of what's been done, NOT handling it at all), there's nothing to stop a
user from creating more commands for the postprocessor (at least now that we
have good toys like ECHO), even if that postprocessor's rules include
processing comments.  Your postprocessor can/may of course do whatever it
pleases; we're talking about the OS Command Interpreter, not a pre- or
post-processor.  It appears to me that the designers of MPE simply made the
wrong "thoughtful" decision - the COMMENT command is DEFINED to be
unprocessed text, and should be.  Those same designers also have the power
to change that definition; I don't see where that's been done.

> This isn't much different than, say, Javadoc,
> where the contents of code comments have semantic meaning to a different
> process that's applied to the same code.  The PostScript Document
> Structuring Conventions have the same comments-are-partially-processed
> characteristic.

...which I'd also not-so-humbly call erroneous.  What does Webster have to
say about COMMENT?  I ought to be able to put absolutely any thing I please
in a comment and expect it to a) remain intact and b) have no effect on the
process to which I add the comment.

(Didn't COMMENT processing in MPE come about as the result of lack of other
tools such as ECHO?  My fuzzy memory corresponds with CSY's fuzzy logic ;-)

IMHO a comment is a comment is a comment, and shouldn't be toyed with.
Otherwise, what good are comments?

Fregzample, when there's a problem with a jobstream or script, specifically
referring to the problem should be doable via comments, using whatever
symbols therein I deem necessary for my comment.  When comments get
processed, not only the comment gets mangled, so do other things.  Why can't
I put !, <, >, >> in a comment?  Because undocumented features of the OS
mess around with them.  OK, they're not undocumented; they're just
over-reaching their proper scope.  Anyway, processed comments have proven
themselves to be a very handy trap for this very conscientious user thereof;
the liberal usage of comments is thus actively discouraged.

Tracy

* To join/leave the list, search archives, change list settings, *
* etc., please visit http://raven.utc.edu/archives/hp3000-l.html *