- The range of values for INTEGER, REAL and LONGREAL are not prescribed.
- LONGREAL and REAL may be identical
- There is no longer any distinction between a character constant and a string constant containing a single character. Both are enclosed in double-quotes.
- Single-character strings can be assigned to variables of type CHAR.
- Single-quotes can no longer be used as an alternative for double-quotes for string constants.
- Strings can be assigned to any array of characters, provided the number of characters in the string is not greater than that of the array. If it is less, a null character is appended. (i.e. a null character is no longer always present).
- The character set is a standard character set but is not necessarily Latin-1.
- CASE labels can be single-character strings. The selector is CHAR.
- INCL, EXCL are reintroduced from the original version of Oberon for including / excluding an element in a SET
- SHORT and LONG are reintroduced for converting LONGREAL to REAL and vice versa.
- FLOOR can be used with LONGREALs as well as REALs.
- LSR has been replaced by ROR.
- ORD can be used with a SET as a parameter
- ABS can no longer be used with a SET as a parameter
I think the elimination of single quote string delimiters is unfortunate (there is no \" convention for including double quotes in a string).
Is ORD now the way to determine the number of elements in a set? (The report states that it returns the "ordinal", whatever that is.)
The double-quote character can be specified as the hex char 22X. You would need to replace / insert / append it to a string at runtime. I agree it would be a nuisance but fortunately it is only likely to occur on rare occasions.I think the elimination of single quote string delimiters is unfortunate
Thankfully not! That 'solution' creates more problems than it solves.(there is no \" convention for including double quotes in a string).
It is a typecast function i.e. equivalent to SYSTEM.VAL(INTEGER, <set>). You can try it out for yourself as it already exists as an 'undocumented feature' in the current Astrobe compiler.Is ORD now the way to determine the number of elements in a set? (The report states that it returns the "ordinal", whatever that is.)
What I would also find useful is the inverse function for typecasting an INTEGER to a SET. Component Pascal has such a function which is called BITS.
I agree, but not because I need to include double quotes in strings very often. AFAIK single quotes as string delimiters were supported ever since Pascal, and I always use them because they are easier to type in the US keyboard layout. You can't type double quotes without pressing the Shift key. I see it as a usability issue.kevinhely wrote:I think the elimination of single quote string delimiters is unfortunate (there is no \" convention for including double quotes in a string).
Hmm... I notice that on the German keyboard layout both the single-quote and double-quote are shifted characters...because they are easier to type in the US keyboard layout
Perhaps auto-capitalisation of quote characters should be added as an option in Astrobe?
It is also interesting to note the asymmetry between the types CHAR and String - you can declare a variable or formal parameter of type CHAR but there are no character constants, whereas with the type String there are literals but you cannot declare a variable or formal parameter of that type.
The decision to remove single quotes as a string delimiter may seem drastic at first, but the previous solution of having two alternative quote marks was not sufficient either. Even if you have N different quote marks you still cannot represent a string literal containing all N quote marks. So instead of trying to solve one special case we now have only one way to represent a string literal that will be sufficient in most cases.
Praise to Prof Wirth for finally getting it right.
In theory perhaps but in practice the differences between CHARs and strings have now all but been eliminated. The key point is that now a CHAR and a single character string are compatible. "C" is both a CHAR and an ARRAY 1 OF CHAR depending on the context in which it is used and you can now pass CHAR constants and variables to string (ARRAY OF CHAR) parameters. Some example code which runs in the 2011 revision of Oberon-07 but would not have been been possible in the 2008 revision is:It is also interesting to note the asymmetry between the types CHAR and String
Code: Select all
MODULE CharString3; IMPORT Out, Main, Strings; CONST quotes = 22X; TYPE String = ARRAY 255 OF CHAR; VAR s: String; (* ch: CHAR; Correction: *) ch: ARRAY 1 OF CHAR; PROCEDURE Substitute(newCh, oldCh: CHAR; VAR s: ARRAY OF CHAR); VAR i: INTEGER; BEGIN i := 0; WHILE (i < LEN(s)) & (s[i] # 0X) DO IF s[i] = oldCh THEN s[i] := newCh END; INC(i) END; END Substitute; PROCEDURE ProcessEscapes(VAR s: ARRAY OF CHAR); BEGIN (* Replace '\\' with '\' '\q' with '"' This is an exercise for the reader .... *) END ProcessEscapes; BEGIN (* Ex.1 *) Out.String("\q = "); Out.Char(quotes); Out.Ln; (* Ex.2 *) s := "\q = ?"; s := quotes; Out.String(s); Out.Ln; (* Ex.3 *) s := "\q = ?"; Substitute(quotes, "?", s); Out.String(s); Out.Ln; (* Ex.4 *) s := "\q = "; Strings.Append(quotes, s); Out.String(s); Out.Ln; (* Ex.5 *) s := "\q = "; ch := quotes; Strings.Append(ch, s); Out.String(s); Out.Ln; (* Ex.6 *) s := "\\q = \q"; ProcessEscapes(s); Out.String(s); Out.Ln END CharString3.
Code: Select all
\q = ' \q = ' \q = ' \q = ' \q = ' \\q = \q
Code: Select all
PROCEDURE Append*(src: ARRAY OF CHAR; VAR dest: ARRAY OF CHAR);
It is also worth noting that the string 0X needs special interpretation. According to section three "...a single-character string may be specified by the ordinal number of the character..." and according to section 9.1 "Single-character strings can also be assigned to variables of type CHAR." Since the null character cannot be contained in any string (it is the string terminator) it cannot be a single-character string. It is therefor not even clear if 0X is a valid string. I am a bit confused about this.
Maybe so in the 2008 version but not any more. Consider the following valid Oberon-07 (2011) statements:it is a central property of Oberon-07 that each literal constant (and expression) has a unique and unambiguous type
Code: Select all
VAR char: CHAR; charString: ARRAY 1 OF CHAR; string: ARRAY 2 OF CHAR; char := "X"; charString := "X"; (* Identical to charString := "X"; *) string := "X"; (* Identical to string := "X"; string := 0X; *) string := "XX"; (* Identical to string := "X"; string := "X"; *) CASE char OF "X": .....