Re: Form feed comment for pragma Page

Re: Form feed comment for pragma Page

[Robert Dewar]

Rex said

"Compilers issue informationals about either:

   1) Comments after pragma Page do not have to be printed in
      the source code.

   2) The form feed character isn't in the allowed set of
      characters for Ada source code.

It appears that problem number 1 should go away in
Ada 95 because all pragmas must be printed out in
the source listing.  However, this may cause an extra
form feed.
"

First, there is no change in Ada 95 compared to Ada 83 with respect
to pragma Page.

Second, form feed *is* in the allowed set of characters for Ada
source code, but it is a logical end of line separator, so you
cannot put it in the middle of a comment (since it ends the logical line).
Again, no change from 83 to 95 here.

Re: Form feed comment for pragma Page

[Robert Dewar]

Just to be clear, if you gave the following lines

   pragma page ;  -- ^L (form feed for pagination during
                  --     straight printing of the source code file)

to an Ada compiler, including the comments in parens, then any Ada
83 or Ada 95 compiler must flag a syntax error for the line
starting (form feed.

Re: Form feed comment for pragma Page

[Robert A Duff]

In article <dewar.833858501@schonberg>, Robert Dewar <dewar@cs.nyu.edu> wrote:
>Second, form feed *is* in the allowed set of characters for Ada
>source code, but it is a logical end of line separator, so you
>cannot put it in the middle of a comment (since it ends the logical line).
>Again, no change from 83 to 95 here.

Quite true, but implementers can play games, since the RM does not
define the source representation.  Just because your editor and
operating system think it's a form-feed, doesn't mean your compiler
does, and vice-versa.

- Bob

Re: Form feed comment for pragma Page

[Arthur Evans Jr]

In article <dewar.833858501@schonberg>, dewar@cs.nyu.edu (Robert Dewar) wrote:

> Second, form feed *is* in the allowed set of characters for Ada
> source code, but it is a logical-end-of line separator, so you
> cannot put it in the middle of a comment (since it ends the logical line).

Well, form feed (control-L) is an ASCII character and part of the
standard character set, but I'm quite surprised to hear that it's a
logical-end-of line, for two reasons:

  - If anything, it's-end-of page, not-end-of line.

  - And it's not even that.  The RM in A.10(8) is quite clear that the
    standard does not specify which characters, if any, correspond to
    logical end-of-line or end-of-page or end-of-file.

I'll agree that many implementations, probably most of them, choose to
implement end-of-page using the ASCII form feed character, but the
standard is silent on the subject.

Art Evans

Arthur Evans Jr, PhD        Phone: 412-963-0839
Ada Consulting              FAX:   412-963-0927
461 Fairview Road
Pittsburgh PA  15238-1933
evans@evans.pgh.pa.us

Re: Form feed comment for pragma Page

[Robert Dewar]

Bob said

"Quite true, but implementers can play games, since the RM does not
define the source representation.  Just because your editor and
operating system think it's a form-feed, doesn't mean your compiler
does, and vice-versa.
"

Yes, I know these games well, but this particular one is unlikely, since
the ACVC sources insist that form feed act as end of line

(yes, yes, you could translate this to something else and still "mis-
interpret form feed, but that is FAR out in the theoretical realm!)

Re: Form feed comment for pragma Page

[Robert Dewar]

Art says

"Well, form feed (control-L) is an ASCII character and part of the
standard character set, but I'm quite surprised to hear that it's a
logical-end-of line, for two reasons:

  - If anything, it's-end-of page, not-end-of line.

  - And it's not even that.  The RM in A.10(8) is quite clear that the
    standard does not specify which characters, if any, correspond to
    logical end-of-line or end-of-page or end-of-file.

I'll agree that many implementations, probably most of them, choose to
implement end-of-page using the ASCII form feed character, but the
standard is silent on the subject."

Art, you are confused, we are talking about source representation here.
YOu quoted some irrelevant paragraph about Text_IO. THe operable
statement in the standard is:

2.1
13  format_effector
                The control functions of ISO 6429 called character tabulation
                (HT), line tabulation (VT), carriage return (CR), line feed
                (LF), and form feed (FF).

and

2.2
2   The text of a compilation is divided into lines.  In general, the
representation for an end of line is implementation defined.  However, a
sequence of one or more format_effectors other than character tabulation (HT)
signifies at least one end of line.

Pretty clear, and far from silent.

It is very important to understand that source representation has nothing
to do with type Standard.Character or with Text_IO. Sure, may implementations
may choose to represent the source in a manner that is consistent with
Text_IO as a sequence of elements of type Standard.Character, but this is
not a required representation, just one possible choice.

Form feed comment for pragma Page

[Rex Reges]

One unusually nonportable bit of Ada code occurs when you place 
a form feed character in a comment after a pragma Page:

   pragma page ;  -- ^L (form feed for pagination during
                  --     straight printing of the source code file)

Compilers issue informationals about either:

   1) Comments after pragma Page do not have to be printed in 
      the source code.

   2) The form feed character isn't in the allowed set of
      characters for Ada source code.

It appears that problem number 1 should go away in 
Ada 95 because all pragmas must be printed out in
the source listing.  However, this may cause an extra
form feed.

-- 
or you can call me The Fixer...
or you can e-mail me at RegesR@pgate.he.boeing.com

Re: Form feed comment for pragma Page

[Robert Dewar]

Rex said

"Note that there is a slight difference between Ada 83 and 95
concerning the definition of a comment.  It appeared to me
that the intent was to allow almost any character code to
be in the comment including nulls and other items not
normally allowed."

No difference between Ada 83 and Ada 95 here, an approved AI allowed
(though to be precise did not require) this in Ada 83. The Ada 95
definition is merely a restatement of the conclusions of this AI.

Note that ending a comment with a form feed is of course fine, since
that is the end of a logcal line anyway.

Re: Form feed comment for pragma Page

[Keith Thompson]

In <evans-0406961641500001@ppp5.pgh.net> evans@evans.pgh.pa.us (Arthur Evans Jr) writes:
> Well, form feed (control-L) is an ASCII character and part of the
> standard character set, but I'm quite surprised to hear that it's a
> logical-end-of line, for two reasons:
> 
>   - If anything, it's-end-of page, not-end-of line.
> 
>   - And it's not even that.  The RM in A.10(8) is quite clear that the
>     standard does not specify which characters, if any, correspond to
>     logical end-of-line or end-of-page or end-of-file.
> 
> I'll agree that many implementations, probably most of them, choose to
> implement end-of-page using the ASCII form feed character, but the
> standard is silent on the subject.

RM A.10(8) refers to files processed by Text_IO, not to Ada source files;
there's no requirement that they're the same thing.  An Ada compiler
needn't use Text_IO to read source files.

The relevant paragraph is 2.2(2), which says:

    The text of a compilation is divided into lines.  In general,
    the representation for an end of line is implementation defined.
    However, a sequence of one or more format_effectors other than
    character tabulation (HT) signifies at least one end of line.

A format_effector is defined in 2.1(13) as one of HT, VT, CR, LF, and FF.
Thus a formfeed character *in an Ada source* must signify an end of line.

Note that the coded representation for these characters is also
implementation-defined.

-- 
Keith Thompson (The_Other_Keith) kst@thomsoft.com <*>
TeleSoft^H^H^H^H^H^H^H^H Alsys^H^H^H^H^H Thomson Software Products
10251 Vista Sorrento Parkway, Suite 300, San Diego, CA, USA, 92121-2718
This sig uses the word "Exon" in violation of the Communications Decency Act.

Re: Form feed comment for pragma Page

[Rex Reges]

Yes, I verified that both the VAX and Harris's version of the 
Verdix compiler do accept a comment which ends in a form feed.

The form feed character is a valid formatting element in the
language, but is handled differently by the source code listings.
The Vax prints the pragma page, pages to the next page, and then 
finishes the line's  comment and pages again.  Therefore, 
nothing is lost.

Note that there is a slight difference between Ada 83 and 95
concerning the definition of a comment.  It appeared to me
that the intent was to allow almost any character code to
be in the comment including nulls and other items not 
normally allowed.

-- 
or you can call me The Fixer...
or you can e-mail me at RegesR@pgate.he.boeing.com

Text_IO and Ada source (was: Form feed comment for pragma Page)

[Arthur Evans Jr]

I said (among other things)

> The RM in A.10(8) is quite clear that the standard does not specify
> which characters, if any, correspond to logical end-of-line or
> end-of-page or end-of-file.

Robert Dewar (and Keith Thompson) replied

> Art, you are confused, we are talking about source representation here.
> YOu quoted some irrelevant paragraph about Text_IO. THe operable
> statement in the standard is: 2.1(13)

Absolutely right -- I missed that section.

Robert goes on:

> It is very important to understand that source representation has
> nothing to do with type Standard.Character or with Text_IO. Sure, may
> implementations may choose to represent the source in a manner that is
> consistent with Text_IO as a sequence of elements of type
> Standard.Character, but this is not a required representation, just
> one possible choice.

It's too bad in a way, though I guess inevitable, that the standards for
Text_IO and source representation are not better connected.  An effect
is that it's not clear how to write an Ada program that emits proper Ada
code -- proper in the sense that the compiler I am using will be able to
read it.  Indeed, the documentation of the Ada compiler I now use is
silent on both of these subjects:
  - the exact form required for source text; and
  - how Text_IO treats end-of-line and such.

Appendix M(6) requires that the form of source text be documented,
though I see no requirement to document the details of Text_IO file
format.  (Curious omission...)

In practice, of course, all of this is a non-issue, since in my compiler
(and I expect in most compilers) both forms use the conventions for text
files on the platform.  It could be very much an issue if my program
needed to write Ada code to be compiled on some other platform.

Art

Re: Text_IO and Ada source (was: Form feed comment for pragma Page)

[Robert Dewar]

Art said

"In practice, of course, all of this is a non-issue, since in my compiler
(and I expect in most compilers) both forms use the conventions for text
files on the platform.  It could be very much an issue if my program
needed to write Ada code to be compiled on some other platform."

Most, but not all, for instance, on an IBM mainframe, one would expect
the source representation to be EBCDIC.

Re: Text_IO and Ada source (was: Form feed comment for pragma Page)

[Norman H. Cohen]

In article <dewar.834075532@schonberg>, dewar@cs.nyu.edu (Robert Dewar) writes: 
|> Art said
|>
|> "In practice, of course, all of this is a non-issue, since in my compiler
|> (and I expect in most compilers) both forms use the conventions for text
|> files on the platform.  It could be very much an issue if my program
|> needed to write Ada code to be compiled on some other platform."
|>
|> Most, but not all, for instance, on an IBM mainframe, one would expect
|> the source representation to be EBCDIC.

("both forms" = source text and run-time text I/O)

But there would be a particular EBCDIC code representing the Latin-1
source-text linefeed character.  The real issue is that the
line-terminator would be implicit in the "logical record length" (LRECL).
However, it appears to follow from RM95 2.2(2) that *both* non-tab format
effectors (i.e., the EBCDIC codes representing the Latin-1 format
effectors) and the end-of-record would have to be recognized as the
end of a source line, so the net effect in cases such as a FF embedded in
a comment would be the same as on non-EBCDIC-based systems.

--
Norman H. Cohen    ncohen@watson.ibm.com

Re: Text_IO and Ada source (was: Form feed comment for pragma Page)

[Robert Dewar]

Norman said

"But there would be a particular EBCDIC code representing the Latin-1
source-text linefeed character.  The real issue is that the
line-terminator would be implicit in the "logical record length" (LRECL).
However, it appears to follow from RM95 2.2(2) that *both* non-tab format
effectors (i.e., the EBCDIC codes representing the Latin-1 format
effectors) and the end-of-record would have to be recognized as the
end of a source line, so the net effect in cases such as a FF embedded in
a comment would be the same as on non-EBCDIC-based systems.
"

What is your justification for the first sentence here. I read nothing
in the RM that requires or implies that the source representation of
any format effector is a "particular code", EBCDIC or otherwise.

For example, a perfectly legitimate representation of form feed is some
special mark in the record, or even a conventional carriage control
character (i.e. a '1', remember that?) at the start of the record.

The standard has NOTHING AT ALL to say about source representation.

FOr examle, a quite legitimate source representation is to store the
source as a tree, and indeed in one sense that is exactly what he
Rational system does.

Re: Form feed comment for pragma Page

[Robert Dewar]

Rex says

"Therefore, my recommendation is to stick to the visible character
set including foreign characters which AI-00339 was actually aimed
at. Also, when debugging, examine strings in hex first to see if any
nulls are lurking about."

That's not quite right, a specific intent of AI-00339 was to allow
ESC sequences corresponding to typical methods of representing
wide characters.

Re: Form feed comment for pragma Page

[Rex Reges]

I was cut off! Sorry about that. As I was saying...

One should not put a null character in a comment since the Unix 
debuggers tend to stop printing when they encounter a null.
For example, when I examine strings while debugging, I have found 
that the full string will not be printed if a null is embedded:

    Example : Strin(1..7) ;
    Example := "ABC" & Character'Val(000) & "DEF" ;

Examinging Example will result in:
 
    Example = "ABC"

In addition, useful tools like Vax's CMS won't accept some control 
characters inthe source code (at least the old versionI am using).  

Therefore, my recommendation is to stick to the visible character 
set including foreign characters which AI-00339 was actually aimed 
at. Also, when debugging, examine strings in hex first to see if any
nulls are lurking about.

-- 
or you can call me The Fixer...
or you can e-mail me at RegesR@pgate.he.boeing.com

Re: Form feed comment for pragma Page

[Rex Reges]

It appears to me now that the problem
with a form-feed-character-in-a-comment
evolved over time to a non-problem and 
I observed the problem before compiler 
vendors had caught up.  

Although this may seem a minor point, I
would like to make some additional comments.

The current Ada 95 appears to have a different problem that I
have run into: null characters.  

In LRM 2.1 the allowed characters for
comments are intentionally not defined
causing trouble from one machine to another.
The statement is:

"The only characters allowed outside 
of comments are..."

This may allow null characters and other
troublesome control characters.

One should not put a null character in a 
comment since the Unix debuggers tend to 

-- 
or you can call me The Fixer...
or you can e-mail me at RegesR@pgate.he.boeing.com

Re: Form feed comment for pragma Page

[Ken Garlington]

> In addition, useful tools like Vax's CMS won't accept some control
> characters inthe source code (at least the old versionI am using).

I think this particular problem is fixed in later versions of DEC CMS
(used to be VAX CMS). Later versions of CMS also allow non-text files,
such as executables, to be stored.

-- 
LMTAS - "Our Brand Means Quality"

Re: Text_IO and Ada source (was: Form feed comment for pragma Page)

[Norman H. Cohen]

In article <dewar.834585066@schonberg>, dewar@cs.nyu.edu (Robert Dewar) writes: 
|> Norman said
|>
|> "But there would be a particular EBCDIC code representing the Latin-1
|> source-text linefeed character.
...
|> "
|>
|> What is your justification for the first sentence here. I read nothing
|> in the RM that requires or implies that the source representation of
|> any format effector is a "particular code", EBCDIC or otherwise.
...
|> The standard has NOTHING AT ALL to say about source representation.

Quite right, I was describing actual practice, not any requirement of the
standard.  (The usual practice is to exploit the operating system's
division of files into logical records and to treat each record as a
source line, but it is possible to sneak format effectors--or, more
precisely, EBCDIC characters that the implementation treats as the
representation of ISO 10646 BMP format effectors--into the middle of a
record.)

What RM95 2.2(2) requires is that, whatever mechanisms the implementation
uses to represent a format effector other than a tab, the implementation
must treat the logical occurrence of such a character as the end of a
line, i.e., such a character cannot be construed as occurring in the
MIDDLE of a comment.

--
Norman H. Cohen    ncohen@watson.ibm.com

Re: Text_IO and Ada source (was: Form feed comment for pragma Page)

[Robert Dewar]

Norm Cohen says

"What RM95 2.2(2) requires is that, whatever mechanisms the implementation
uses to represent a format effector other than a tab, the implementation
must treat the logical occurrence of such a character as the end of a
line, i.e., such a character cannot be construed as occurring in the
MIDDLE of a comment."

There is nothing to say that "the mechanism the implementation uses to
represent a format effector" has anything to do with any characters in
the source text (in Norm's message here, he is using character in the
logical sense). For example, the following is peculiar, but quite
legitimate:

A form feed format effector character could be the character 16#0C#
provided that it occurs outside a comment, but inside a comment
16#0C# could be regarded as not being a format effector. The occurrence
of a form feed terminating a comment (which must be permissible) could
be represented by some entirely different mechanism.

There is nothing in the RM to say that the method used for source
representation must be a simple one-to-one translation of some kind,
though of course in many systems this will indeed be the case.

Note that in particular, it is perfectly fine to represent all format
effectors that terminate a line in an identical manner, since they
all have identical lexical/syntactic/semantic effects.

For example, it is perfectly fine on the IBM mainframe to represent
CR, LF, VT, or FF or any sequence of such characters as the physical
end of record, without distinguishing between these cases.

In a Unix-based system, it would be peculiar, but perfectly permissible
to represent CR,LF,VT and FF (here and in the previous paragraph I am
using these abbreviations to abbreviate the logical Ada characters, not
the corresponding ascii representations), the same way.

For example, you can take the Ada source, and translate CR,LF,VT,FF all
to LF, and that is a legitimate source representation, since every possible
Ada program is representable, and has correct semantics.

You can take this much further, for example, all comments can be 
represented by a single space in the text that is input to your
compiler.

Of course, good taste and usability dictate against choosing source
representations that are undesirable or unworkable, but the RM itself
dictates *very* little in this area!