Evolution of character constants and strings

[August Karlstrom]

The permissible syntax of (non-numeric) character constants and strings
has changed more than once since the original definition of the Oberon
language. In Oberon-2 we can express every character constant including
quotation mark and apostrophe (any string of length one can be used as a
character constant). In Oberon-07, however, it is not possible to use an
apostrophe in a character constant so instead we have to add a constant
declaration like

CONST apos = 27X;

which feels a bit awkward. I can't see why Oberon-07 didn't adopt the
definition of character constants from Oberon-2. Does it have any subtle
drawbacks?


/August

[Chris Burrows]

Post by August Karlstrom
The permissible syntax of (non-numeric) character constants and strings
has changed more than once since the original definition of the Oberon
language. In Oberon-2 we can express every character constant including
quotation mark and apostrophe (any string of length one can be used as a
character constant). In Oberon-07, however, it is not possible to use an
apostrophe in a character constant so instead we have to add a constant
declaration like
CONST apos = 27X;
which feels a bit awkward. I can't see why Oberon-07 didn't adopt the
definition of character constants from Oberon-2. Does it have any subtle
drawbacks?

I have this strange feeling of 'Deja Vu' ...

There was a previous discussion about the ambiguity of "A" in Oberon-2 (is
it a char or a single-character string?) in this newsgroup.

Search comp.lang.oberon for the thread titled "A somewhat tricky question"
started on 26 July 2005. You should recognise the author ;-)

Regards,
Chris Burrows

CFB Software
Astrobe v3.2: ARM Oberon-07 Development System
http://www.astrobe.com

[August Karlstrom]

Post by Chris Burrows
I have this strange feeling of 'Deja Vu' ...
There was a previous discussion about the ambiguity of "A" in Oberon-2 (is
it a char or a single-character string?) in this newsgroup.

Yes, I remember starting that thread. But the problem doesn't go away by
preventing double quoted character constants - it is still not clear
what the type of e.g. 'A' is. If we want to allow both double and single
quoted strings we might as well do the same for character constants with
the added benefit of being able to express all character constants.


/August

[Chris Burrows]

Post by August Karlstrom
Yes, I remember starting that thread. But the problem doesn't go away by
preventing double quoted character constants - it is still not clear what
the type of e.g. 'A' is. If we want to allow both double and single quoted
strings we might as well do the same for character constants with the
added benefit of being able to express all character constants.

The problem does go away because single-quoted, single-character strings do
not exist in Oberon-07. 'A' is defined to be a character. If you want a
single-character string you must use "A". This is clarified in the section
'Character vs String' in Wirth's document 'Remaining Trouble Spots in
Oberon'.

Hence, given the declarations:

TYPE
String = ARRAY 32 OF CHAR;

VAR
s: String;
c: CHAR;

the following are examples of legal and ilegal string and character
assignments in Oberon-07:

(* valid string assignments *)
s[0] := 0X; (* null string *)
s := ""; (* null string *)
s := ''; (* null string *)
s := "A";
s := "'"; (* single quote *)
s := "AB";
s := 'AB';
s := "A single-quote character is ' ";
s := 'A double-quote character is " ';
s[0] := 'A'; s[1] := 0X;
s[0] := 22X; s[1] := 0X; (* A string containing a single double-quote
character *)

(* invalid string assignments *)
s := 'A'; (* a single character *)
s := '"'; (* a single character *)

(* valid characters *)
c := 'A';
c := '"';
c := 27X; (* single-quote character *)

(* invalid character assignments *)
c := "A"; (* a single-character string *)
c := ''; (* a null string *)
c := "'"; (* single-character string *)
c := '''; (* null string followed by an unterminated string *)

Regards,
Chris

Chris Burrows
CFB Software
Astrobe v3.2: ARM Oberon-07 Development System
http://www.astrobe.com

[August Karlstrom]

Post by Chris Burrows
The problem does go away because single-quoted, single-character strings do
not exist in Oberon-07.

I can't find it mentioned anywhere in the language report:

http://www.inf.ethz.ch/personal/wirth/Articles/Oberon/Oberon07.Report.pdf

Post by Chris Burrows
This is clarified in the section
'Character vs String' in Wirth's document 'Remaining Trouble Spots in
Oberon'.

Here is the relevant part:

In Oberon, we now let "x" denote the singleton string,
whereas 'x' denotes the character constant x.

For some reason this important sentence is put inside parentheses. It
definitely needs to be mentioned in the language report. Anyway, I think
the decision is great since now every literal constant has a unique type.

By the way, in section 8.2.4. in the language report it is not mentioned
that strings and character arrays can be compared for equality (and
inequality). This must be an oversight, right?


/August

[Chris Burrows]

Post by August Karlstrom

Post by Chris Burrows
The problem does go away because single-quoted, single-character strings do
not exist in Oberon-07.

http://www.inf.ethz.ch/personal/wirth/Articles/Oberon/Oberon07.Report.pdf

It isn't spelt out but IMHO it is the most sensible of the possible
conclusions given the syntax rules in the report.

All the compiler implementor now has to do when parsing code is to process
the syntax rules in the order they appear in the report. i.e. the
'CharConst' rule is processed before the 'string' rule.

Post by August Karlstrom
Anyway, I think the decision is great since now every literal constant has
a unique type.

I agree.

Post by August Karlstrom
By the way, in section 8.2.4. in the language report it is not mentioned
that strings and character arrays can be compared for equality (and
inequality). This must be an oversight, right?

I disagree. Section 8.2.4. says "The ordering relations <, <=, >, >= apply
to the numeric types, CHAR, and character arrays (strings)."

I might agree with you if instead it said "The ordering relations <, <=, >,

Post by August Karlstrom
= apply to the numeric types, CHAR, character arrays and strings."

Additionally, it has previously been stated in 3.4:

"Strings can be assigned to and compared with arrays of characters"

Regards,
Chris

[August Karlstrom]

Post by Chris Burrows

Post by August Karlstrom

Post by Chris Burrows
The problem does go away because single-quoted, single-character strings do
not exist in Oberon-07.

http://www.inf.ethz.ch/personal/wirth/Articles/Oberon/Oberon07.Report.pdf

It isn't spelt out but IMHO it is the most sensible of the possible
conclusions given the syntax rules in the report.

From reading the report in isolation I think an equally sensible (and
less strict) conclusion is that e.g. 'A' can be either a character
constant or a string depending on the context (as in Oberon-2).

Post by Chris Burrows
All the compiler implementor now has to do when parsing code is to process
the syntax rules in the order they appear in the report. i.e. the
'CharConst' rule is processed before the 'string' rule.

Yes, that is a nice consequence for the implementor. It is not clear
though that the order of (independent) productions is significant.

In this case I still believe that a clarification is needed in the report.

Post by Chris Burrows

Post by August Karlstrom
By the way, in section 8.2.4. in the language report it is not mentioned
that strings and character arrays can be compared for equality (and
inequality). This must be an oversight, right?

I disagree. Section 8.2.4. says "The ordering relations<,<=,>,>= apply
to the numeric types, CHAR, and character arrays (strings)."

OK, so the reasoning goes like this: Since the equality relation can be
defined in terms of <= and >= it is therefore also applicable for these
types.


/August