Further revision of Oberon-07

[augustk]

Maybe so in the 2008 version but not any more. Consider the following valid Oberon-07 (2011) statements:

Your example only shows the assignment compatibility between single-character strings and CHAR and between strings and character arrays. Both "X" and "XX" are still just strings. You previously stated that character variables are assignment compatible with open character arrays. However, I cant find any information about this in the manual. Where does it say so?

[cfbsoftware]

You previously stated that character variables are assignment compatible with open character arrays. However, I cant find any information about this in the manual.

Now that I look again I can't see it either. That is a pity - I would have found it useful.

That means the declaration in my CharString3 example should be changed from

Code: Select all

ch: CHAR;

to

Code: Select all

ch: ARRAY 1 OF CHAR;

for it to work properly.

[augustk]

That is a pity - I would have found it useful.

As far as I understand it's the assignment compatibility between strings and character arrays that allows a string to be passed to a procedure expecting a character array (even though no copying of characters take place). So if character variables were to be compatible with character array parameters I reason that they would also have to be assignment compatible with character arrays. Implementation-wise the parameter passing part would probably be a bit difficult though, as a character variable cannot be simply converted to a character array.

[cfbsoftware]

It is also worth noting that the string 0X needs special interpretation.

Our interpretation of the 2011 report led to the following test program which demonstrates various ways of creating a null string:

Code: Select all

MODULE NullStr1;

IMPORT 
  Main, Out, Strings;
  
VAR
  ch: CHAR;
  s: ARRAY 1 OF CHAR;

PROCEDURE Length(s: ARRAY OF CHAR);
BEGIN
  Out.Int(Strings.Length(s), 0); Out.Ln
END Length;

PROCEDURE Run();  
BEGIN
  s := "";      ASSERT(s = "", 100); Length(s);
  s := 0X;      ASSERT(s = "", 101); Length(s);
  s[0] := 0X;   ASSERT(s = "", 102); Length(s); 
  ch := 0X;    
  s[0] := ch;   ASSERT(s = "", 103); Length(s);
END Run;

BEGIN
  Run();
  Out.String("NullStr1 Finished OK"); Out.Ln
END NullStr1.

When compiled with the Oberon 2011 compiler it produces the following (expected) output when run:

0
0
0
0
NullStr1 Finished OK

[augustk]

Does the compiler reject the statement

Code: Select all

ch := ""

If it does I guess the scanner uses a distinct token type for string ordinals. Otherwise the parser would not be able to tell the empty string from the null string (0X) as both compare equal and are of length zero.

[cfbsoftware]

Correct. "" is not a single-character string so it cannot be assigned to a CHAR variable. Single-character strings are interpreted in either of two ways in the Astrobe Oberon 2011 compiler depending on whether the context is a CHAR or an ARRAY OF CHAR. The following example illustrates the two different uses:

Code: Select all

MODULE CharString7;

IMPORT Strings;

TYPE
  String = ARRAY 32 OF CHAR;

VAR
  ch: CHAR;
  i: INTEGER;
  s: String;

PROCEDURE CharProc(ch: CHAR);
BEGIN
END CharProc;
  
PROCEDURE StringProc(s: String);
BEGIN
END StringProc;
  
BEGIN
  (* Single-character strings used as CHARs *)
  ch := 0X;
  ch := 22X;
  ch := "x";
  ch := "'"; (* Single-quote enclosed in double-quotes *)
  i := ORD(0X);
  i := ORD(22X);
  i := ORD("x");
  i := ORD("'"); 
  IF (ch = 0X) OR (ch = 22X) OR (ch = "x") OR (ch = "'") THEN (* Do something *) END; 
  CharProc(0X);
  CharProc(22X);
  CharProc("x");
  CharProc("'"); 
  CASE ch OF
    0X, 22X, "x", "'": (* Do something *)
  END;
 
  (* Single-character strings used as ARRAY OF CHARs *)
  s := 0X;
  s := 22X;
  s := "x";
  s := "'";
  Strings.Append(s, 0X);
  IF (s = 0X) OR (s = 22X) OR (s = "x") OR (s = "'") THEN (* Do something *) END; 
  StringProc(0X);
  StringProc(22X);
  StringProc("x");
  StringProc("'")
END CharString7.

[augustk]

OK, but the scanner does not know about these contexts (CHAR or ARRAY OF CHAR). Although the language was simplified to use only strings, as far as I can tell the scanner still needs two token types (like charString and ordString) so that the parser can tell the empty string ("") from the null string (0X).

[augustk]

Never mind, I found a rather simple solution: In the case of the empty string ("") the scanner can store it as s[0] := 0X; s[1] := 1X to differentiate it from the null string (0X) which is typically stored as s[0] := 0X; s[1] := 0X.

[kevinhely]

Hi,

I was away and missed this conversation.

Thankfully not! That 'solution' creates more problems than it solves.

What problems? (I ask because I implemented it on my Oberon compiler without difficulty.)

Kevin.

[cfbsoftware]

If you nominate a character as an escape character e.g. "\" then you also have to specify how to represent that escape character in the situations where you want to use it as literal character, not an escape. Typically this is done by doubling the character e.g. "\\". Unfortunately in computing contexts the "\" character is quite common (e.g. in pathnames).

e.g. If you used "\" to escape a " character, as proposed, then to output the text:

"C:\temp"

I assume you would would need to write:

Code: Select all

Out.String("\"C:\\temp\\\"");   (* ??? *)

Personally, although it is more 'wordy', I prefer to be able to write:

Code: Select all

CONST
  quotes = 22X;

Out.Char(quotes); Out.String("C:\temp\"); Out.Char(quotes);

and find this easier to comprehend at a glance.