Oberon Community Platform Forum
November 20, 2019, 07:49:14 PM *
Welcome, Guest. Please login or register.
Did you miss your activation email?

Login with username, password and session length
News:
 
   Home   Help Search Login Register  
Pages: [1] 2 3 ... 7
  Print  
Author Topic: Four questions about Oberon-07  (Read 63242 times)
kevinhely
Newbie
*
Posts: 44


« on: January 09, 2013, 11:06:38 PM »

Hi,

Four questions about Oberon-07.

Is an assignment A := B allowed, where A is an open array and B is an array (open or not) of the same element type?

Is a comparison p = q allowed, where p is of type POINTER TO Car (say) and q is of type POINTER TO SportsCar, where SportsCar is an extension of Car? (It's possible for p to point at a record of type SportsCar.)

Is the comparison s = t allowed, where s is a string and t is an array of characters? (Also, the same question for <.)

Can a field (or array element) be an argument corresponding to a VAR parameter, i.e. are fields and array elements considered "variables".

K
« Last Edit: January 10, 2013, 12:23:57 AM by kevinhely » Logged
Laksen
Newbie
*
Posts: 4


« Reply #1 on: January 11, 2013, 12:38:13 AM »

There are many type rules unexplained in the Oberon-07 specification. I just assumed that the ones where it wasn't entirely clear were using the same rules as in Oberon-2, i.e.

1) Yes, I think
2) I think so. Both are pointers, so it should work.
3) Yes. A string is just an array of char with a defined length.
4) If it's assignable to, then you can do that, yes.
Logged
Dsar
Newbie
*
Posts: 40


« Reply #2 on: January 11, 2013, 12:44:38 AM »

Hi,

Hola!

Is an assignment A := B allowed, where A is an open array and B is an array (open or not) of the same element type?

The assignment requires that the type of expression must be the same of the designator. This means you cannot assign two arrays that don't belong to a named type, open arrays are of nameless type, then you cannot assign two open arrays or a (nameless) array to an open array and viceversa.
The only exception is the (constant) string that can be assigned to any array, then they can be assigned also to open array.

Is a comparison p = q allowed, where p is of type POINTER TO Car (say) and q is of type POINTER TO SportsCar, where SportsCar is an extension of Car? (It's possible for p to point at a record of type SportsCar.)

Is the comparison s = t allowed, where s is a string and t is an array of characters? (Also, the same question for <.)

Can a field (or array element) be an argument corresponding to a VAR parameter, i.e. are fields and array elements considered "variables".

Yes
Logged
kevinhely
Newbie
*
Posts: 44


« Reply #3 on: January 11, 2013, 02:51:18 AM »

Thank you for replying.

There are many type rules unexplained in the Oberon-07 specification. I just assumed that the ones where it wasn't entirely clear were using the same rules as in Oberon-2, i.e.
I agree that there are apparently unexplained rules but it doesn't make sense to refer to a different language specification to answer questions about this language!

2) I think so. Both are pointers, so it should work.
Are you saying that p = q is valid regardless of the pointer types of p and q? I doubt that is what Wirth intended.

3) Yes. A string is just an array of char with a defined length.
No, strings are not arrays in Oberon. They may be assigned to character arrays, according to the definition of assignment in Wirth's document. There's no mention of strings in the definition of the relational operators. In an earlier version, they were mentioned explicitly in that section but that has been deleted in the latest version.

4) If it's assignable to, then you can do that, yes.
Wirth's definition only states "A variable parameter corresponds to an actual parameter that is a variable, and it stands for that variable". He gives no definition of what counts as a variable.

I like the shortness of the language definition (16 A4 pages) but not the fact that this has led to a lack of clarity.

Regards,
Kevin.
Logged
kevinhely
Newbie
*
Posts: 44


« Reply #4 on: January 11, 2013, 02:55:32 AM »

¡Hola Dsar!

Thanks for replying.

The assignment requires that the type of expression must be the same of the designator. This means you cannot assign two arrays that don't belong to a named type, open arrays are of nameless type, then you cannot assign two open arrays or a (nameless) array to an open array and viceversa.
The only exception is the (constant) string that can be assigned to any array, then they can be assigned also to open array.

Yes, that's what I figured but it's not what I expected (the ability to assign to an open array or elements of it is a useful one). And I've received different answers in other forums!

For the other points, see my other post above.

Regards,
Kevin.
Logged
Dsar
Newbie
*
Posts: 40


« Reply #5 on: January 11, 2013, 03:32:39 AM »

Yes, that's what I figured but it's not what I expected (the ability to assign to an open array or elements of it is a useful one). And I've received different answers in other forums!

What I explained is the same for Modula-2, Oberon and other languages that have loose name equivalence. Anyway, if you need to copy arrays of characters regardless the type system, there is the COPY procedure, but you cannot assign nameless arrays

Code:
MODULE array;

TYPE Name = ARRAY 32 OF CHAR;

VAR
  a : ARRAY 32 OF CHAR;
  b : ARRAY 32 OF CHAR;
  c : Name;
  d : Name;

PROCEDURE Foo(VAR arr : ARRAY OF CHAR);
BEGIN
  arr := "Hola"; (* Ok *)
  arr := b;      (* Compile time error, different (both nameless) type *)
  COPY(b, arr);  (* Ok *)
END Foo;


BEGIN
  b := "Hello"; (* Ok, constant string assigned to (any) array of char *)
  c := "Hello"; (* Ok, see above *)
  a := b;       (* Compile time error, different (both nameless) type *)
  COPY(b, a);   (* Ok *)
  Foo(a);
  c := d;       (* Ok, same type *)
  c := b;       (* Compile time error, different (c named, b nameless) type *)
END array.
« Last Edit: January 11, 2013, 03:52:54 AM by Dsar » Logged
kevinhely
Newbie
*
Posts: 44


« Reply #6 on: January 11, 2013, 04:11:24 AM »

Alas, Wirth's definition has almost nothing to say about COPY, certainly nothing about it ignoring the type rules. As I said to Laksen above, what may or may not hold in Modula-2 etc. cannot be taken as a definitive statement about the corresponding notion in Oberon-07. The purpose of a programming language specification is to give unambiguous answers to questions about it. On a different forum, I've received differing answers to these questions. I think that is a problem for Oberon-07. (Also, whether or not a given compiler accepts/rejects something can't be taken as a definitive answer to questions about the language. I'm in the process of designing a compiler for Oberon-07 myself!)
« Last Edit: January 11, 2013, 04:13:31 AM by kevinhely » Logged
Dsar
Newbie
*
Posts: 40


« Reply #7 on: January 11, 2013, 04:16:11 AM »

The only difference is the compatibility of constant string with any kind of array, the type system is the same.

(I assume you have never programmed in Oberon before)

Logged
Dsar
Newbie
*
Posts: 40


« Reply #8 on: January 11, 2013, 04:26:37 AM »

Wirth's definition only states "A variable parameter corresponds to an actual parameter that is a variable, and it stands for that variable". He gives no definition of what counts as a variable.

9.2 Procedure calls:

In the case of variable parameters, the actual parameter must be a designator denoting a variable.
If it designates an element of a structured variable, the selector is evaluated when the formal/actual
parameter substitution takes place, i.e. before the execution of the procedure.

(Page 9)
Logged
kevinhely
Newbie
*
Posts: 44


« Reply #9 on: January 11, 2013, 02:46:43 PM »

Hi,

The only difference is the compatibility of constant string with any kind of array, the type system is the same.

No, in Oberon, strings are strings and arrays are arrays (e.g. you cannot write "abcde"[3] or str[3], where str is a constant defined to be "abcde".) The defining document used to mention the possibility of comparing strings with strings/arrays but that was deleted from the current version. If I'm wrong, please show me the relevant sentence(s) from the report.

(I assume you have never programmed in Oberon before)
I have programmed extensively in Oberon!

K
Logged
kevinhely
Newbie
*
Posts: 44


« Reply #10 on: January 11, 2013, 02:48:01 PM »

In the case of variable parameters, the actual parameter must be a designator denoting a variable.
If it designates an element of a structured variable, the selector is evaluated when the formal/actual
parameter substitution takes place, i.e. before the execution of the procedure.

Yes! Thanks!
Logged
kevinhely
Newbie
*
Posts: 44


« Reply #11 on: January 11, 2013, 02:52:18 PM »

By the way, I received this reply on a different forum:

> This suggests that A := B is disallowed.

No it doesn't. It suggests that A := B in your example is disallowed only if the length of A is different from the length of B. If the lengths are the same the statement is valid. In your example it is not possible to completely determine if "the type of the expression is the same as that of the designator" at compile-time. However, it can be checked at runtime and that is what is done in applications created by the Astrobe compiler. A runtime trap occurs if the lengths are different.

One example of way to avoid such runtime errors would be to write:

IF LEN(A) = LEN(B) THEN A := B END


I'm not sure I buy this argument. What do you think?

K
Logged
Dsar
Newbie
*
Posts: 40


« Reply #12 on: January 11, 2013, 05:08:06 PM »

No, in Oberon, strings are strings and arrays are arrays (e.g. you cannot write "abcde"[3] or str[3], where str is a constant defined to be "abcde".) The defining document used to mention the possibility of comparing strings with strings/arrays but that was deleted from the current version. If I'm wrong, please show me the relevant sentence(s) from the report.

Sorry, I was talking about assignment compatibility, not compatibility of all operator.

With a deep analysis of changes between 2008 and 2011 report, strings are no more fully compatible with arrays, but only with assignment. Then you cannot compare strings with array, you have to assign it to an array.

Code:
CONST
  greeting = "Hello";
VAR
  a : ARRAY 10 OF CHAR;
  b : ARRAY 10 OF CHAR;
BEGIN
  a := greeting; (* Ok *)
  b := "Hola";   (* Ok *)
  IF a = b THEN  (* Correct *)
  [...]
  IF a = "Hello" THEN (* Compile time error *)
  [...]

My original reply (where I wrote Yes) is wrong, it is No

I'm not sure I buy this argument. What do you think?

Maybe that user has in mind the old (2008) Oberon-07 report:

9.1. Assignments
[...]
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.


But this rule doesn't hold no more for what I got
Logged
kevinhely
Newbie
*
Posts: 44


« Reply #13 on: January 11, 2013, 05:47:50 PM »

Maybe that user has in mind the old (2008) Oberon-07 report:

Yes, maybe he has. I've emailed him again about it.

K
Logged
cfbsoftware
Full Member
***
Posts: 107


WWW
« Reply #14 on: January 12, 2013, 12:20:31 AM »

Maybe that user has in mind the old (2008) Oberon-07 report:
No he (Chris Burrows) hasn't. The Astrobe Oberon compiler is based on the definitions in document "The Programming Language Oberon
Revision 22.9.2011". See my responses to Kevin Hely's questions in the Astrobe forum:

http://www.astrobe.com/forum/viewtopic.php?f=4&t=255
Logged

Chris Burrows
Astrobe v7.0 (Feb 2019): Oberon for ARM Cortex-M3, M4 and M7 Microcontrollers
http://www.astrobe.com
Pages: [1] 2 3 ... 7
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.21 | SMF © 2015, Simple Machines Valid XHTML 1.0! Valid CSS!