gnubol: Re: Determining free-form or fixed-form reference format.

["William M. Klein" <wmklein@ix.netcom.com>]

To the best of my knowledge the interaction of
   "*>" and ">>"
with XML has not yet been considered by the Standards committee.  I do
believe, however, that Micro Focus (aka MERANT) already has support for both
character strings *and* XML.

I cannot think of any place that a COBOL XML program with have "problems"
with confusing these.  I would think (but this may show my ignorance) that
the XML "symbols" would ONLY appear in a COBOL program - in an alphanumeric
literal.  Such literals are required to support ALL characters and
combinations of characters.  (Actually this is really only true of fixed-form
reference format.  The new free-form reference format allows an implementor
to restrict "special" characters from non-hex-alphanumeric literals.)

Therefore, I don't see that there could ever be ANY set of characters that
couldn't be confused from "meaningful" characters when outside a literal and
a string inside a literal.

Obviously, ">" is already a part of the COBOL language so there is nothing
that can/should be done that would in any way impact its use in COBOL
programs.  Furthermore, it is already used in the "double glyph"  ">=".   And
the JOD (and possibly/probably the Standard after this one) includes "<>" to
mean "not equal to".  (Again, a number of vendors already include this as an
extension.)

As far as the actual characters chosen, I am *so* used to "*>" for inline
comments, that it is hard for me to picture other possibilities. (Micro Focus
has supported these for about a decade now.)  The only "technical" issue that
was discussed at J4 (and WG4) that I still have some "quandary" about is
whether there should be a "terminator" character string so you could have
"inline comments" in the middle of a COBOL line, for example

  Move ABC *> sending field <* to XYZ

where "sending field" is a comment and "to XYZ" is back to COBOL source.
However, I don't think that this "enhancement" is worth adding at this
stage - and it would mean that you would have to "parse" the comment to find
its terminator.

As far as ">>" goes, I was a little happier when an earlier draft required
you to code
    >>DIR
at the beginning of directives (rather than having the "DIR" be optional).
But that led to some really UGLY code for
    >>EVALUATE and >>IF
not to mention
   >>D (debugging indicator)

Bottom-line:
  If you can come up with some examples for J4 or WG4 to think about where
problems may occur with likely XML code, then please let them know.
Otherwise, I don't see this as a serious "open" issue - but that's my opinion
only.

NOTE:
   When OO was just starting, we spent almost a year changing the "inline OO
indicator" each meeting.  We ended up with "::" (double colons) but even that
has some problems that have only surfaced in the last year or so.  (The
problems have to do with the fact that the single colon is *ALWAYS* a
text-separator in COPY/REPLACING.) These types of "aesthetic" issues, really
drive the Standard committee into more "confusion" and circular reasoning
than usual.

--
Bill Klein
    wmklein <at> ix dot netcom dot com
RKRayhawk <rkrayhawk@aol.com> wrote in message
news:20000101195738.07851.00000563@ng-fc1.aol.com...
> Bill,
>
> Overall where do we stand with the special ciphers *> and >> entering the
COBOL
> language?
>
> Has any approved standard put the right angle bracket ( > ) into the
language
> yet?
>
> What stage of approval are any proposed or evolving language standard that
> permit this cipher.
>
> This ill chosen character will make it very difficult to get COBOL to work
well
> with XML as source code or literals in a common source file.
>
> In XML, the star (asterisk, *) has meta characteristics as well.
>
>  This means that COBOL lexical tools need to be able to see two different
kind
> of comments, and disambiguate geater than from .*>. and .>>'. To merge that
> into a single tool set that might hope to be able to see XML in stream is
going
> to be very difficult.
>
> This seems like a serious problem for the future of COBOL. To your
knowledge,
> has this issue been considered in the standards effort?
>
> Bob Rayhawk
> RKRayhawk@aol.com
> Robert Rayhawk
> RKRayhawk@aol.com
>



--
This message was sent through the gnu-cobol mailing list.  To remove yourself
from this mailing list, send a message to majordomo@lusars.net with the
words "unsubscribe gnu-cobol" in the message body.  For more information on
the GNU COBOL project, send mail to gnu-cobol-owner@lusars.net.