[Oberon] Compiler behaviour for a32 := a8

Hans Klaver hklaver at dds.nl
Mon Feb 1 14:39:50 CET 2021


Chris wrote:

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

Contrary to the latter rule that you cite a variable of one character array type now can be assigned to a variable of quite another character array type (provided the two array types have the same length). This is a breach in the type checking that amazes me.

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

I would consider it an abuse of SYSTEM.COPY to use it for assignment of one variable of an anonymous ARRAY len1 OF CHAR type to a variable of another anonymous ARRAY len2 OF CHAR, and using it would be unwieldy and unhelpful:
- unwieldy because it would involve several SYSTEM-dependend type casts, 
- unhelpful because it would not warn for string truncation. 

Such assignments already can be done SYSTEM-independently with a String.Copy procedure, but it would be nicer if the compiler would allow such assignments of variables of anomymous character array types of different length and check for the suitability of the lengths.

So my point is that the logic of the language changes (and their implementation) escape me.


Hans 
 




> 
> Op 1 feb. 2021, om 11:30 heeft Chris Burrows <chris at cfbsoftware.com> het volgende geschreven:
> 
>> -----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
> 
> 
> --
> Oberon at lists.inf.ethz.ch mailing list for ETH Oberon and related systems
> https://lists.inf.ethz.ch/mailman/listinfo/oberon



More information about the Oberon mailing list