[Oberon] Compiler behaviour for a32 := a8

[Chris Burrows]

> -----Original Message-----
> From: Oberon [mailto:oberon-bounces at lists.inf.ethz.ch] On Behalf Of
> Hans Klaver
> Sent: Monday, 1 February 2021 7:35 PM
> To: ETH Oberon and related systems
> Subject: [Oberon] Compiler behaviour for a32 := a8
> 
> The recent discussions about strings and the OR compiler and how one
> should interpret the language report reminded me of a question that
> has puzzled me for some time now.
> 
> In the change from Oberon (1990) to Oberon-07 the standard procedure
> COPY(src, dst) was discarded by NW and the type check of the
> assignment operator := for strings and character arrays was changed
> somewhat.
> 
> In Oberon (1990) str2 := str1 was only possible if str1 and str2 were
> of the *same* type; and COPY could be used if the types were
> different, truncating a string if necessary.
> 
> In Oberon-07 str2 := str1 also is possible if s1 and s2 are of
> *different* types, provided their lengths are *equal*. At least that
> is how Wirth's OR compiler behaves; at least one compiler (OBNC)
> still precludes assignment if str1 and str2 are of different types.
> 
> Now, in Wirth's document 'Differences between Revised Oberon and
> Oberon' (https://people.inf.ethz.ch/wirth/Oberon/Oberon07.pdf) under
> '4. Assignment of arrays and records' one can read:
> '(...) But now we handle array and record assignments just like other
> assignments, writing dst := src, and discard the COPY procedure. The
> destination array must not be shorter than the source array. (...)'
> 
> So I would expect that something like the following should be
> possible:
> 
>    ...
>    VAR
>      a8:  ARRAY 8 OF CHAR;
>      a32: ARRAY 32 OF CHAR;
>    BEGIN
>      ...
>      a32 := a8;  (* error: illegal assignment *)
> 
> But unfortunately this is not possible with the current
> implementation of the Oberon-07 language. So now we have to use a
> Strings procedure to get this done:
>    Strings.Copy(a8, a32)  (* equivalent to:  a32 := "";
> Strings.Insert(a8, 0, a32) *)
> 
> Whereas the following *is* possible when using the OR compiler, which
> I would regard as not in the spirit of the Oberon language (and
> that's why I think OBNC has the proper behaviour):
> 
>    TYPE
>      Man      = ARRAY 32 OF CHAR;
>      Woman    = ARRAY 32 OF CHAR;
>      NoGender = ARRAY 32 OF CHAR;
>    VAR
>      m: Man;
>      n: NoGender;
>      w: Woman;
>    BEGIN
>      ...
>      m := w;  (* OR: no error;  OBNC: incompatible types in
> assignment *)
>      n := m;  (* OR: no error;  OBNC: incompatible types in
> assignment *)
> 
> 
> In my view a32 := a8 should be allowed and m := w or n := m not!
> 
> What do you think?
> 
> 
> Hans Klaver
> 

The document you referred to, 'Differences between Revised Oberon and
Oberon' is dated 22.03.2008 / 15.7.2011 and is now obsolete. The latest
version of the Language Report is dated Revision 1.10.2013 / 3.5.2016.

At the time the 'Differences' document was written, section 9.1.
'Assignments' of the Language Report listed the following exceptions:

--------------------------------------------------
1. The constant NIL can be assigned to variables of any pointer or procedure
type.
2. Arrays must have the same element type, and the length of the destination
array must not be
less than the length of the source array.
3. Strings can be assigned to any array of characters, provided the length
of the string is less than
that of the array.
4. In the case of records, the type of the destination must be an extension
of the type of the
source.
--------------------------------------------------

Revision 1.10.2013 / 3.5.2016 of the Language Report now states the
exceptions as:

--------------------------------------------------
1. The constant NIL can be assigned to variables of any pointer or procedure
type.
2. Strings can be assigned to any array of characters, provided the number
of characters in the
string is less than that of the array. (A null character is appended).
Single-character strings can
also be assigned to variables of type CHAR.
3. In the case of records, the type of the source must be an extension of
the type of the destination.
4. An open array may be assigned to an array of equal base type. 
--------------------------------------------------

The key point is that Item 2 in the earlier definition has been removed and
the rule "The type of the expression must be the same as that of the
designator" now applies to array assignments. Hence a32 := a8 is no longer
allowed.

Note that SYSTEM.COPY is now provided to efficiently copy n words from an
array of one type to another of the same or different type.

Regards,
Chris Burrows
CFB Software
https://www.astrobe.com/RISC5