Usage of \ in Ada

Usage of \ in Ada

[Jerry]

I've suggested to the author of the most excellent OS X editor TextMate
that it is an error to always consider a \ in quoted text as an escape
character with respect to syntax coloring. He as asked for specific
examples and before I lead him wrong I want to check around. For
example, in the Ada snippet

    Put_Line("Hello, World");
    Put_Line("\");
    Put_Line("Hello again");

TextMate looks at the \ and says, oh--the next character, ", is
supposed to be escaped, and then proceeds to color the second half of
the second line and the first half of the third line as though it were
quoted text. It then colors the second half of the third line as though
it were _unquoted_ text--i.e., the \ causes a "quote parity" error in
the syntax coloring. The current work-around is to put a " in a comment
at the end of the second line.

At least one other editor, Xcode (Apple's own) handles this correctly
for all of C (treating the \ as the beginning of an escape sequence),
and Pascal and Ada (treating the \ as just another character).

Am I right in recommending that this behavior for Ada be such that \ is
never an escape character?

Jerry

Re: Usage of \ in Ada

[Jacob Sparre Andersen]

Jerry wrote:

> Am I right in recommending that this behavior for Ada be such that \
> is never an escape character?

Yes.

Jacob
-- 
"if a person can't communicate,
 the very least he can do is to shut up!"

Re: Usage of \ in Ada

[Jeffrey R. Carter]

Jerry wrote:
> 
> Am I right in recommending that this behavior for Ada be such that \ is
> never an escape character?

The language attributes no special meaning to any character.

In addition, string literals cannot extend across multiple lines.

A specific application may give special meanings to characters, but in 
that case, for a string to contain the sequence '\' & '"' you have to 
create it within the constraints of the language.

-- 
Jeff Carter
"What I wouldn't give for a large sock with horse manure in it."
Annie Hall
42

Re: Usage of \ in Ada

[Dmitry A. Kazakov]

On Mon, 21 Aug 2006 19:44:41 GMT, Jeffrey R. Carter wrote:

> Jerry wrote:
>> 
>> Am I right in recommending that this behavior for Ada be such that \ is
>> never an escape character?
> 
> The language attributes no special meaning to any character.

Hmm, I don't think it is true. For example, format effectors:

ARM 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."

I.e. placing LF character into a string literal, be prepared to
surprises...

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Usage of \ in Ada

[Jeffrey R. Carter]

Dmitry A. Kazakov wrote:
> 
> I.e. placing LF character into a string literal, be prepared to
> surprises...

If LF is a line terminator, you can't put it in a string literal.

-- 
Jeff Carter
"What I wouldn't give for a large sock with horse manure in it."
Annie Hall
42

Re: Usage of \ in Ada

[Dmitry A. Kazakov]

On Tue, 22 Aug 2006 02:47:48 GMT, Jeffrey R. Carter wrote:

> Dmitry A. Kazakov wrote:
>> 
>> I.e. placing LF character into a string literal, be prepared to
>> surprises...
> 
> If LF is a line terminator, you can't put it in a string literal.

That's what I mean. Only identifier letters, digits, spaces and

"Any character of the ISO 10646 BMP that is not reserved for a control
function, and is not the space_character, an identifier_letter, or a digit"

are allowed. Actually it is not different from escape sequences of C,
except that once escaped you won't get back without a compile error.

------------
P.S. it seems that OP question actually cannot be answered. Whether \ is
reserved for a control function depends on the platform.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Usage of \ in Ada

[Adam Beneschan]

Dmitry A. Kazakov wrote:

> > If LF is a line terminator, you can't put it in a string literal.
>
> That's what I mean. Only identifier letters, digits, spaces and
>
> "Any character of the ISO 10646 BMP that is not reserved for a control
> function, and is not the space_character, an identifier_letter, or a digit"
>
> are allowed. Actually it is not different from escape sequences of C,
> except that once escaped you won't get back without a compile error.
>
> ------------
> P.S. it seems that OP question actually cannot be answered. Whether \ is
> reserved for a control function depends on the platform.

No, it depends on ISO 10646.  And character 92 (\) is not reserved for
a control function in that ISO standard.  See also RM95 2.1(17).

                    -- Adam

Re: Usage of \ in Ada

[Jeffrey R. Carter]

Dmitry A. Kazakov wrote:
> 
> That's what I mean. Only identifier letters, digits, spaces and
> 
> "Any character of the ISO 10646 BMP that is not reserved for a control
> function, and is not the space_character, an identifier_letter, or a digit"
> 
> are allowed. Actually it is not different from escape sequences of C,
> except that once escaped you won't get back without a compile error.

However, any value of Character can be in a Value of type String, and 
none of them have any special significance in the language. That's the 
context that I was replying in.

-- 
Jeff Carter
"If I could find a sheriff who so offends the citizens of Rock
Ridge that his very appearance would drive them out of town ...
but where would I find such a man? Why am I asking you?"
Blazing Saddles
37

Re: Usage of \ in Ada

[Keith Thompson]

"Jeffrey R. Carter" <spam.not.jrcarter@acm.not.spam.org> writes:
> Dmitry A. Kazakov wrote:
>> That's what I mean. Only identifier letters, digits, spaces and
>> "Any character of the ISO 10646 BMP that is not reserved for a
>> control
>> function, and is not the space_character, an identifier_letter, or a digit"
>> are allowed. Actually it is not different from escape sequences of C,
>> except that once escaped you won't get back without a compile error.
>
> However, any value of Character can be in a Value of type String, and
> none of them have any special significance in the language. That's the
> context that I was replying in.

A character in a *value* of type String can be anything; that's
separate from the question of interpreting characters in string
literals in source code.  For example, a doubled '"' character in a
string literal is interpreted as a single '"' character, but there's
nothing special about a '"' character in a value of type String.
(Similarly, in C, there's nothing special about a backslash character
in a runtime string value.)

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
San Diego Supercomputer Center             <*>  <http://users.sdsc.edu/~kst>
We must do something.  This is something.  Therefore, we must do this.

Re: Usage of \ in Ada

[Dmitry A. Kazakov]

On 22 Aug 2006 11:13:28 -0700, Adam Beneschan wrote:

> Dmitry A. Kazakov wrote:
> 
>> P.S. it seems that OP question actually cannot be answered. Whether \ is
>> reserved for a control function depends on the platform.
> 
> No, it depends on ISO 10646.  And character 92 (\) is not reserved for
> a control function in that ISO standard.  See also RM95 2.1(17).

Yes, that should exclude the code position 16#5C# (\).

Its wording is interesting, because it uses "code position", and yet leaves
source representation free. I wonder, if that might lead to confusion.
Consider an HTML encoded Ada program containing a string literal
represented as &34;&10;&34; ('"' & LF & '"'). That could be illegal, if the
code position 10 (LF) is control.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Usage of \ in Ada

[Adam Beneschan]

Dmitry A. Kazakov wrote:
> On 22 Aug 2006 11:13:28 -0700, Adam Beneschan wrote:
>
> > Dmitry A. Kazakov wrote:
> >
> >> P.S. it seems that OP question actually cannot be answered. Whether \ is
> >> reserved for a control function depends on the platform.
> >
> > No, it depends on ISO 10646.  And character 92 (\) is not reserved for
> > a control function in that ISO standard.  See also RM95 2.1(17).
>
> Yes, that should exclude the code position 16#5C# (\).
>
> Its wording is interesting, because it uses "code position", and yet leaves
> source representation free. I wonder, if that might lead to confusion.

Apparently it has.  Either you're really confused, or I'm really
confused about what you're trying to say, or possibly both.

Conceptually, an Ada95 program is a sequence of characters, where a
"character" is something defined by ISO 10646 (specifically, the Basic
Multilingual Plane of that standard).  Please note that this is
*conceptually* true and has nothing to do with what bits are used to
represent those characters (on disk, or in memory, or in the bytes that
come down a socket to the compiler from a preprocessor program, or
whatever).  The disk (let's say) will contain some sequence of bits
that isn't defined by the language.  But at some point, the compiler
will interpret that as the mathematical entity that comprises an Ada
source, i.e. the sequence of ISO 10646 BMP characters.  I think that
once you separate, in your mind, the conceptual from the actual
representation on disk, there should be no more confusion.  If the
sequence of characters that makes up an Ada program includes a line
that consists of a series of non-quote characters, followed by a quote
mark, followed by a line separator (2.2(2)), followed by another quote
mark, the program is illegal.  Period.  This doesn't depend on the
platform or on the representation.  On the other hand, a \ character in
a line of the Ada source is treated exactly the same as other
characters that are not letters, digits, underscores, format effectors,
quotation marks, or delimiters; this is also true regardless of the
representation or the platform.

I'm having trouble understanding your point, and I think it's because
you're intermingling the conceptual and representational forms of the
Ada program, so that either I don't know which one you're referring to,
or you're of confusing them and sort of referring to both at the same
time.  It would help if you were clearer about which one you're
discussing.  The actual representation of an Ada source could be an
issue for the OP's question, if TextMate doesn't understand how a
particular Ada compiler converts the representation to the conceptual
form and just displays things as it sees them on disk.  But I've never
heard of an Ada compiler that treats \ in the representation of an Ada
program as having any special meaning inside string literals.  And it
would make no sense for an Ada compiler to treat \" in the disk
representation as representing a quotation mark.

                                      -- Adam

Re: Usage of \ in Ada

[Dmitry A. Kazakov]

On 23 Aug 2006 10:31:25 -0700, Adam Beneschan wrote:

> Dmitry A. Kazakov wrote:
>> On 22 Aug 2006 11:13:28 -0700, Adam Beneschan wrote:
>>
>>> Dmitry A. Kazakov wrote:
>>>
>>>> P.S. it seems that OP question actually cannot be answered. Whether \ is
>>>> reserved for a control function depends on the platform.
>>>
>>> No, it depends on ISO 10646.  And character 92 (\) is not reserved for
>>> a control function in that ISO standard.  See also RM95 2.1(17).
>>
>> Yes, that should exclude the code position 16#5C# (\).
>>
>> Its wording is interesting, because it uses "code position", and yet leaves
>> source representation free. I wonder, if that might lead to confusion.
> 
> Apparently it has.  Either you're really confused, or I'm really
> confused about what you're trying to say, or possibly both.
[...]

I have already agreed that the code position 16#5C# should pose no problem. 

What I meant is a rationale behind the choice made to reference some code
positions as potentially illegal. I don't understand the reason why,
provided that the source representation is explicitly stated as irrelevant.
As an example, I gave a program in HTML or XML encoding, which
representation allows to place *any* code position into a string literal.
According to ARM this program could be illegal, without obvious reason.

In other words, how can an Ada compiler know if the code position of, say,
LF is reserved for a control function? Why should it care?

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Usage of \ in Ada

[Adam Beneschan]

Dmitry A. Kazakov wrote:

> What I meant is a rationale behind the choice made to reference some code
> positions as potentially illegal. I don't understand the reason why,
> provided that the source representation is explicitly stated as irrelevant.
> As an example, I gave a program in HTML or XML encoding, which
> representation allows to place *any* code position into a string literal.
> According to ARM this program could be illegal, without obvious reason.

It's probably to prevent stupid errors.  If you have a string literal
with an LF in it, it's far more likely (using a fairly traditional
representation of the source) that you've forgotten a closing quote
than that you intended to put a linefeed in the literal.  And if the
language did try to allow a line separator in a string literal (even if
it were represented as something like \n in the representation), it
would have to change the definition of what constitutes a "line" since
some line separators would not really be line separators, and IMHO
things would get pretty muddled.  I don't know if there's any
particular rationale for not allowing other control characters, except
that doing so would probably reduce portability (e.g. try to port a
source program with character'val(26) in a string literal from some
other system to Windows).

                           -- Adam

Re: Usage of \ in Ada

[Jean-Pierre Rosen]

Adam Beneschan a �crit :
> It's probably to prevent stupid errors.  If you have a string literal
> with an LF in it, it's far more likely (using a fairly traditional
> representation of the source) that you've forgotten a closing quote
> than that you intended to put a linefeed in the literal.  And if the
> language did try to allow a line separator in a string literal (even if
> it were represented as something like \n in the representation)

And of course, if you really need an LF in a character string, just use 
Ada.Characters.Latin_1.LF ....

-- 
---------------------------------------------------------
            J-P. Rosen (rosen@adalog.fr)
Visit Adalog's web site at http://www.adalog.fr

Re: Usage of \ in Ada

[Dmitry A. Kazakov]

On Thu, 24 Aug 2006 10:37:21 +0200, Jean-Pierre Rosen wrote:

> Adam Beneschan a �crit :
>> It's probably to prevent stupid errors.  If you have a string literal
>> with an LF in it, it's far more likely (using a fairly traditional
>> representation of the source) that you've forgotten a closing quote
>> than that you intended to put a linefeed in the literal.  And if the
>> language did try to allow a line separator in a string literal (even if
>> it were represented as something like \n in the representation)
> 
> And of course, if you really need an LF in a character string, just use 
> Ada.Characters.Latin_1.LF ....

Sure, but that is not the point. The problem is which code positions are
illegal (non-graphic_character). Consider it from the position of the
designer of a compiler/parser/scanner. (That was the OP question all about)
The same question arises for the designer of an automated code generator
tool. Which encoding-legal code positions can be safely put into string
literals?

ARM 2.1(17) reads "Every code position of ISO 10646 BMP that is not
reserved for a control function is defined to be a graphic_character by
this International Standard. This includes all code positions other than
0000 - 001F, 007F - 009F, and FFFE - FFFF."

I am not a native English speaker, so it is difficult to me to decipher the
above.

Let S be the set of code positions 0..1F U 7F..9F U FFFE..FFFF.

My question to language lawyers is about the relation between S and
graphic_character:

1. Can some x of S be graphic_character?
      (do S and graphic_character intersect)

2. Is any y outside S graphic_character?
      (is complement of S a subset of graphic_character)

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Usage of \ in Ada

[Jean-Pierre Rosen]

Dmitry A. Kazakov a �crit :
> Let S be the set of code positions 0..1F U 7F..9F U FFFE..FFFF.
> 
> My question to language lawyers is about the relation between S and
> graphic_character:
> 
> 1. Can some x of S be graphic_character?
>       (do S and graphic_character intersect)
No
> 2. Is any y outside S graphic_character?
>       (is complement of S a subset of graphic_character)
Yes.

This is perfectly defined. The only issue is whether a non-graphic 
character is allowed in a character string in Ada. The answer is that, 
appart from format effector, it is not portable.


-- 
---------------------------------------------------------
            J-P. Rosen (rosen@adalog.fr)
Visit Adalog's web site at http://www.adalog.fr

Re: Usage of \ in Ada

[Dmitry A. Kazakov]

On Thu, 24 Aug 2006 14:15:07 +0200, Jean-Pierre Rosen wrote:

> Dmitry A. Kazakov a �crit :
>> Let S be the set of code positions 0..1F U 7F..9F U FFFE..FFFF.
>> 
>> My question to language lawyers is about the relation between S and
>> graphic_character:
>> 
>> 1. Can some x of S be graphic_character?
>>       (do S and graphic_character intersect)
> No
>> 2. Is any y outside S graphic_character?
>>       (is complement of S a subset of graphic_character)
> Yes.

OK

> The only issue is whether a non-graphic 
> character is allowed in a character string in Ada.

It seems that ARM 2.6(2-4) requires it be a graphic_character.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Usage of \ in Ada

[Jean-Pierre Rosen]

Dmitry A. Kazakov a �crit :
>> The only issue is whether a non-graphic 
>> character is allowed in a character string in Ada.
> 
> It seems that ARM 2.6(2-4) requires it be a graphic_character.
> 
Sorry, I meant in program source. Control characters are not allowed in 
strings.

-- 
---------------------------------------------------------
            J-P. Rosen (rosen@adalog.fr)
Visit Adalog's web site at http://www.adalog.fr

Re: Usage of \ in Ada

[Adam Beneschan]

Dmitry A. Kazakov wrote:
> On Thu, 24 Aug 2006 10:37:21 +0200, Jean-Pierre Rosen wrote:
>
> > Adam Beneschan a écrit :
> >> It's probably to prevent stupid errors.  If you have a string literal
> >> with an LF in it, it's far more likely (using a fairly traditional
> >> representation of the source) that you've forgotten a closing quote
> >> than that you intended to put a linefeed in the literal.  And if the
> >> language did try to allow a line separator in a string literal (even if
> >> it were represented as something like \n in the representation)
> >
> > And of course, if you really need an LF in a character string, just use
> > Ada.Characters.Latin_1.LF ....
>
> Sure, but that is not the point.

Well, J-P's point is sort of pertinent.  The question I was trying to
answer was, what was the reason for Ada not allowing control characters
inside string literals.  And whatever reasons the authors might have
had for thinking allowing them was a bad idea, the fact is that it's
relatively easy in Ada to find another way to include such characters
in a string value, simply by using the concatenate operator and
A.C.L.LF or whatever, so there's no pressing need to find a way to
represent them inside string literals.  Trying to do the same thing in
C, without using the special escape sequences, is pretty painful.

                                  -- Adam