Oberon Community Platform Forum

Development => Oberon & Active Oberon => Topic started by: kevinhely on January 09, 2013, 11:06:38 PM



Title: Four questions about Oberon-07
Post by: kevinhely 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


Title: Re: Four questions about Oberon-07
Post by: Laksen 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.


Title: Re: Four questions about Oberon-07
Post by: Dsar 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


Title: Re: Four questions about Oberon-07
Post by: kevinhely 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.


Title: Re: Four questions about Oberon-07
Post by: kevinhely 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.


Title: Re: Four questions about Oberon-07
Post by: Dsar 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.


Title: Re: Four questions about Oberon-07
Post by: kevinhely 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!)


Title: Re: Four questions about Oberon-07
Post by: Dsar 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)



Title: Re: Four questions about Oberon-07
Post by: Dsar 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)


Title: Re: Four questions about Oberon-07
Post by: kevinhely 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


Title: Re: Four questions about Oberon-07
Post by: kevinhely 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!


Title: Re: Four questions about Oberon-07
Post by: kevinhely 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


Title: Re: Four questions about Oberon-07
Post by: Dsar 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


Title: Re: Four questions about Oberon-07
Post by: kevinhely 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


Title: Re: Four questions about Oberon-07
Post by: cfbsoftware 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


Title: Re: Four questions about Oberon-07
Post by: cfbsoftware on January 12, 2013, 12:25:38 AM
Alas, Wirth's definition has almost nothing to say about COPY
There is a discussion related to the use of COPY in the Astrobe forum:

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


Title: Re: Four questions about Oberon-07
Post by: Dsar on January 12, 2013, 11:53:45 AM
Hi Chris!

Uhm, in every wirthian language (or derived) that I used with loose/strict name equivalence, open arrays are of nameless type and assignment between them is not possible (except in Modula-3, where the type system is structural).

My interpretation is that in the 2008 report the concept of the array was changed to structural equivalence (with that clause), but in 2011 Wirth came back with the old behavior and this is why COPY is again present (for the case of arrays of characters).


Title: Re: Four questions about Oberon-07
Post by: kevinhely on January 12, 2013, 03:23:23 PM
Alas, the fact that we're debating here highlights my problem with the definition document. The answers to my questions seem to be based not only on that document but on "folklore" that has arisen from the earlier Oberon (and even Modula-2) languages.

A preceding version of Oberon permits array assignment A := B if both have the same element type and LEN(A) >= LEN(B). That statement is an explicit exception to the "name equivalence" of types that has been a key ingredient of Wirth languages. But the fact that it has been deleted from the latest definition betokens a change of policy, surely?

K


Title: Re: Four questions about Oberon-07
Post by: trijezdci on January 12, 2013, 04:11:11 PM
In response to ...

Quote
responses to Kevin Hely's questions in the Astrobe forum:

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

... and thus actually in response to ...

Quote
Be careful what you wish for - read Pat Terry's reminiscenses of a similar exercise to 'improve' the Modula-2 definition:

http://scifac.ru.ac.za/cspt/sc22wg13.htm

The quote accompanying the photo says it all:
Willi Steiger is clutching a much loved copy of PIM, which included Wirth's 33 page report, and Roger Henry, chairman at that stage, is holding an early draft by Don Ward of what was to become a standard document of about 700 pages.

This is a mischaracterisation.

There are several reasons why the standard document grew to around 700 pages. Resolving ambiguities in PIM has not had any significant impact on the volume. The factors with the most significant impact on the size of the document are:

(1) it contains two different versions of the same specification: a plain language version and a formal VDM-SL version
(2) it defines a fairly complete standard library, here again in plain language, and in formal notation
(3) it defines plenty of redundant aliases in the grammar so as to use self-explanatory names

for example instead of simply referring to Ident, a grammar rule may refer to ModuleId which then requires another rule to define ModuleID as an alias for Ident. This is redundant and increases the space that the grammar occupies but it also leads to better readability of the grammar.

Had WG13 actually stuck to its original mission of merely resolving ambiguities in PIM, then the size of the standard document could have well remained within the 100 pages ball park. The draft specification of a revised and modernised Modula-2 dialect R.Sutcliffe and I have been working on is proper evidence for this.

https://bitbucket.org/trijezdci/m2r10/src/tip/_LANGUAGE

The dialect is roughly the same size as PIM4 and the draft is about 148 pages using point 11.5 font while Wirth's PIM used 10 point. The draft also includes things that people usually do not account for when they make statements such as "The XYZ specification is only N pages", for example a glossary, a table of contents, syntax diagrams in addition to EBNF, etc. If our primary goal had been to minimise the number of pages, the draft could well have been reduced to half the number of pages but without sacrificing the goal of avoiding ambiguities.

CFB's conclusion that omission of ambiguities in a language specification will automatically lead to bloat is thus unfounded at best. At the very least, the ISO Modula-2 standard cannot serve as evidence for such a conclusion.

... and further in response to the following, also found in the referenced post ...

Quote
I try to take the approach of a pragmatic dogmatist. If ... there is more than one possible interpretation I then apply the following tests to decide how it should be implemented:

1. Which solution is of more use to a practising Oberon programmer?
2. Which solution would result in more reliable programs?
3. Which solution would result in more efficient programs?
4. Is it feasible to implement the solution?
5. Which solution makes more sense?
6. How likely Is the question likely to arise in real world programming scenarios?
7. Does it really matter?

These are good common sense guidelines for a language *designer*, but they shouldn't have to be necessary for an implementor. Ambiguities in the language design ultimately lead to different interpretations by different implementors. Unless the implementation comes with its own clarified unambiguous language specification, it also leads to different interpretations by users which in turn leads to assumptions that lead to bugs.

The safety of a language is thus inversely proportional to the amount of undefined behaviour in its language specification.




Title: Re: Four questions about Oberon-07
Post by: Dsar on January 12, 2013, 04:54:00 PM
The answers to my questions seem to be based not only on that document but on "folklore" that has arisen from the earlier Oberon (and even Modula-2) languages.

Eheh I would not call it "folklore", Modula-2 and Oberon have a lot in common but of course this mean nothing, I know.
I've read all Modula-2 report from pim1 to 4 and all Oberon paper (87, 88, 89 and 90), not only for historical interest, but also to understand Wirth style writing. This is very important if you want to interpret his reports, a small comma can change everything. This, imho, is bad if you are going to implement a language with a precise type system and rules, but we have this.

But the fact that it has been deleted from the latest definition betokens a change of policy, surely?

Yes, the key ingredient of name equivalence in Oberon type system is in the assignment: "The type of the expression must be the same as that of the designator."
Exceptions are for NIL (because it's an untyped constant), strings and assignment in the case type extension with records (pointers follow the same rules of records, as specified in the pointer type section).

This section is not different from older reports and modula-2 reports, the 2008 one is the first that intruduced a structural assignment for an entity different from string constants and procedure variables


Title: Re: Four questions about Oberon-07
Post by: kevinhely on January 12, 2013, 05:39:23 PM
Quote
I try to take the approach of a pragmatic dogmatist. If ... there is more than one possible interpretation I then apply the following tests to decide how it should be implemented:

1. Which solution is of more use to a practising Oberon programmer?
2. Which solution would result in more reliable programs?
3. Which solution would result in more efficient programs?
4. Is it feasible to implement the solution?
5. Which solution makes more sense?
6. How likely Is the question likely to arise in real world programming scenarios?
7. Does it really matter?

These are good common sense guidelines for a language *designer*, but they shouldn't have to be necessary for an implementor. Ambiguities in the language design ultimately lead to different interpretations by different implementors. Unless the implementation comes with its own clarified unambiguous language specification, it also leads to different interpretations by users which in turn leads to assumptions that lead to bugs.

The safety of a language is thus inversely proportional to the amount of undefined behaviour in its language specification.

I agree. However, although it is commendable for each implementation to clarify its interpretation of ambiguous rules, the ambiguity still affects the portability of programs written in the language. I'm not talking about extensions to the language (such as additional procedures in module SYSTEM) but essential parts of the "language proper" (such as type rules for assignment).

(By the way, where is the above quote from?)

Kevin


Title: Re: Four questions about Oberon-07
Post by: kevinhely on January 12, 2013, 05:55:57 PM
Alas, Wirth's definition has almost nothing to say about COPY
There is a discussion related to the use of COPY in the Astrobe forum:

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

I read that discussion before and I completely agree with you on not hiding erroneous use through default behaviour.

However, the quotation from Reiser & Wirth about COPY is moot since, in the latest specification document, the definition of assignment includes the business about appending 0X when a string of shorter length is assigned to a character array. In any case, it's the same problem as before, viz. that this information is not given in the specification but elsewhere.

Kevin.


Title: Re: Four questions about Oberon-07
Post by: trijezdci on January 12, 2013, 06:19:51 PM
although it is commendable for each implementation to clarify its interpretation of ambiguous rules, the ambiguity still affects the portability of programs written in the language. I'm not talking about extensions to the language (such as additional procedures in module SYSTEM) but essential parts of the "language proper" (such as type rules for assignment).

Indeed.

By the way, where is the above quote from?

It is from the same post CFB linked to, that is to say, the post in the Astrobe forum and whose content I responded to here.


Title: Re: Four questions about Oberon-07
Post by: trijezdci on January 12, 2013, 10:08:06 PM

By the way, where is the above quote from?

It is from the same post CFB linked to, that is to say, the post in the Astrobe forum and whose content I responded to here.

I noticed, that CFB has meanwhile removed this particular chunk from his post, so you won't find it there anymore. At the time I posted it, the original post was still there.



Title: Re: Four questions about Oberon-07
Post by: cfbsoftware on January 12, 2013, 11:27:07 PM
I noticed, that CFB has meanwhile removed this particular chunk from his post, so you won't find it there anymore. At the time I posted it, the original post was still there.
Correct. I obviously wasn't quick enough!  ;)

Having read the discussion here I believe that my responses to a couple of of Kevin Hely's questions were incorrect. The problem was not the language specification but my misreading of it.  :(

I'll be responding to the Astrobe-specific issues further in the Astrobe forum.


Title: Re: Four questions about Oberon-07
Post by: trijezdci on January 13, 2013, 12:18:13 AM
Having read the discussion here I believe that my responses to a couple of of Kevin Hely's questions were incorrect. The problem was not the language specification but my misreading of it.

Do you mean to say this part was removed because it wasn't specific to Astrobe?


Title: Re: Four questions about Oberon-07
Post by: kevinhely on January 13, 2013, 12:26:23 AM
My question on the validity of p = q for p and q of differently named pointer types (regardless of whether one is an extension of the other) is still up for grabs... ;)


Title: Re: Four questions about Oberon-07
Post by: cfbsoftware on January 13, 2013, 01:35:23 AM
Uhm, in every wirthian language (or derived) that I used with loose/strict name equivalence, open arrays are of nameless type and assignment between them is not possible.
I agree. I was mistaken in my initial response to Kevin Hely - the fact that it is currently allowed in Astrobe does not conform to the 2011 language report and will be fixed.


Title: Re: Four questions about Oberon-07
Post by: cfbsoftware on January 13, 2013, 01:58:15 AM
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 *)
  [...]
While it will compile I suspect that you won't get the result that you expect. A character array comparison like this will compare *every* character in the array, even ones that follow a null character. If you assign a string to an array that is longer than the string the remaining elements of the array are undefined. If you want to compare null terminated strings contained in character arrays you will have to compare each array element individually and stop comparing if you reach a null character or the last element of the array.

As well as being able to assign strings to character arrays I believe that you can also pass strings as actual parameters to a procedure with a formal parameter declared as ARRAY OF CHAR. Do you agree?


Title: Re: Four questions about Oberon-07
Post by: kevinhely on January 13, 2013, 04:02:34 AM
As well as being able to assign strings to character arrays I believe that you can also pass strings as actual parameters to a procedure with a formal parameter declared as ARRAY OF CHAR. Do you agree?

Absolutely, as long as the formal parameter is a value parameter. From section (9.2) of the report:

Quote
If the parameter is a value parameter, the corresponding actual parameter must be an expression.

and a string is most definitely an expression; from the Appendix:

Quote
factor = number | string | ...


Title: Re: Four questions about Oberon-07
Post by: kevinhely on January 13, 2013, 04:29:05 AM
My conclusion is that it is non-essential (tell me if you like this):

 :) I don't like it already! I think the specification should have an unambiguous "yes" or "no" answer to this question.

In Oberon the core of strong typing is on the assignment, with this you protect your typed variable from invalid values.

Well, no, that's not the whole story. For example, in section (8.2.2) on arithmetic operators, the rule is "both operands must be of the same type". This is not repeated in section (8.2.4) on relations, but it still holds. I emailed Prof Wirth about it and he replied

Quote
Of course the rule that both operands must be of the same type applies also to relations. I thought that this would be obvious. Mentioning everything that could possibly be misused, if omitted, would make such a report very bloated.

I don't believe the final sentence characterises what I was asking for. I think that explicitly specifying the domain of a relation is a pretty elementary requirement in any software specification.

If you find two equal pointers p and q, the fact that pointer assignment is protected by the type system you are going to access or use the same location in the same typed way. If they are different pointers, it doesn't matter that you are testing an instance of a dog and an instance of a car, they don't refer to the same location, this is not going to crack something.

I understand but think that it is completely at odds with the "spirit" of the language. I suspect that either the types of p and q must be identical (i.e same name) or the type of one is an extension of the type of the other, so that you could write p = q or maybe p(SportsCar) = q. I would be very surprised if the base types of the pointer types of p and q are, as you suggest, irrelevant.

But it's the same old problem: the spec is not clear.


Title: Re: Four questions about Oberon-07
Post by: Dsar on January 13, 2013, 11:44:57 AM
But it's the same old problem: the spec is not clear.

I've deleted my previous post, I know it is unfair but I admit it was a desperate attempt of interpretation due to a missing sentence. I always try to follow strictly his report, but sometimes this lead to bad result.

Sorry

I think the specification should have an unambiguous "yes" or "no" answer to this question.

Not with the Oberon report, or the Wirth style writing


Title: Re: Four questions about Oberon-07
Post by: trijezdci on January 13, 2013, 02:13:10 PM
I emailed Prof Wirth about it and he replied

Quote
Mentioning everything that could possibly be misused, if omitted, would make such a report very bloated.

I have to respectfully disagree with that statement. Language reports are not bloated because they are precise and unambiguous, they are bloated because of feature creep.

In the draft language report of our Modula-2 revision we have specified the compatibility and convertibility of types for every single type in very precise detail. And yet, this only occupies pages 33 to 36 in the current draft:


4 Data Types ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 33
4.1 Type Compatibility ~~~~~~~~~~~~~~~~~~~~~~~~ 33
4.1.1 Alias Type Compatibility ~~~~~~~~~~~~~~~~ 33
4.1.2 Subrange Type Compatibility ~~~~~~~~~~~~~ 33
4.1.3 Compatibility of Literals ~~~~~~~~~~~~~~~ 33
4.1.4 Assignment Compatibility ~~~~~~~~~~~~~~~~ 34
4.1.5 Parameter Passing ~~~~~~~~~~~~~~~~~~~~~~~ 34
4.1.5.1 Named Type Parameters ~~~~~~~~~~~~~~~~~ 34
4.1.5.2 Open Array Parameters ~~~~~~~~~~~~~~~~~ 34
4.1.5.3 Auto-Casting Open Array Parameters ~~~~ 34
4.1.5.4 Variadic Parameters ~~~~~~~~~~~~~~~~~~~ 34
4.2 Type Conversions ~~~~~~~~~~~~~~~~~~~~~~~~~~ 35
4.2.1 Convertibility of Ordinal Types ~~~~~~~~~ 35
4.2.2 Convertibility of Pervasive Numeric Types 35
4.2.3 Convertibility of Set Types ~~~~~~~~~~~~~ 35
4.2.4 Convertibility of Array Types ~~~~~~~~~~~ 35
4.2.5 Convertibility of Record Types ~~~~~~~~~~ 35
4.2.6 Convertibility of Pointer Types ~~~~~~~~~ 35
4.2.7 Convertibility of Procedure Types ~~~~~~~ 35
4.2.8 Convertibility of Opaque Types ~~~~~~~~~~ 36
4.2.9 Convertibility of Scalar Types ~~~~~~~~~~ 36
4.2.10 Non-Convertibility of SYSTEM Types ~~~~~ 36


The total space for this precise per-use-case description of type compatibility and convertibility is only 3 pages in the current draft. Considering that Oberon is a smaller language a similar approach would take even less space, 1 or 2 pages at most. By any definition of bloat, this ain't bloat.


I don't believe the final sentence characterises what I was asking for.

Indeed, we have to give Professor Wirth some credit there. Imagine how much email he must be getting. Unlike many other computer scientists of fame, he tends to actually reply even though it can take a while. Yet, we should not expect him to be able to take time for an in-depth analysis of every question put before him by email. That would be unreasonable. Unless one can narrow one's question very precisely without requiring external context, such as a need to read a discussion thread to fully appreciate the subtlety of the issue, he will only be able to answer in a generic sense. In other words, we should take his responses with a grain of salt and read them as if they were enclosed with the words "In principle ..." and "but ...".


I think that explicitly specifying the domain of a relation is a pretty elementary requirement in any software specification.

Agreed. This belongs into the realm of best engineering practises.

It is also possible to refer to a well documented and established type regime and then only describe in detail those use cases that have exceptions to that regime. This is what we did in our revision of Modula-2 where we made strict name equivalence the default and forbade the use of anonymous types which we consider a consequence of strict name equivalence. To this end, our glossary provides a brief definition of structural equivalence, loose and strict name equivalence, then we use those terms in the specification proper and state that strict name equivalence is the default when nothing is stated to the contrary. This further avoids potential for uncertainty.

As for why there are such exceptions, note that even in a language with strict name equivalence, some use cases may still have to follow structured equivalence. For example, procedure types almost certainly have to follow structured equivalence rules for assignment of discreet procedures to variables of a procedure type. This is so because a procedure is not declared with reference to a procedure type. Its compatibility with a procedure type is determined by comparing its signature with that of the procedure type, which is structural equivalence. If terminology is properly introduced, a language report can make these kinds of exceptions very transparent with very little text by referencing the defined terminology. This doesn't take that much more space, and it tends to improve the readability of the document.


Title: Re: Four questions about Oberon-07
Post by: kevinhely on January 13, 2013, 07:03:59 PM
I have to respectfully disagree with that statement. Language reports are not bloated because they are precise and unambiguous, they are bloated because of feature creep.

I agree. I like the crisp simplicity of Oberon-07's removal of automatic type conversion, though.

Indeed, we have to give Professor Wirth some credit there. Imagine how much email he must be getting. Unlike many other computer scientists of fame, he tends to actually reply even though it can take a while. Yet, we should not expect him to be able to take time for an in-depth analysis of every question put before him by email. That would be unreasonable. Unless one can narrow one's question very precisely without requiring external context, such as a need to read a discussion thread to fully appreciate the subtlety of the issue, he will only be able to answer in a generic sense. In other words, we should take his responses with a grain of salt and read them as if they were enclosed with the words "In principle ..." and "but ...".

Well, the question I sent had nothing to do with this (or any other) forum. I sent it about two years ago when I was working on my compiler for Oberon-07. My question was worded precisely. Moreover, I hardly think the solution required an "in-depth analysis" or a "bloated" solution! (The question was essentially "do the arguments of relations have to be of the same type, the way they are for arithmetic operators?")

A specification is supposed to be a precise and concise description of the desired behaviour of a yet-to-be-constructed system. A specification that requires guesswork, "folklore", and mind-reading skills to answer simple yet crucial questions because of omissions (intended or otherwise) is not to be trusted. How can it be?

I understand the reasons for the rules and the exceptions and I agree with you about clear accurate wording. I think it's possible to write down the rules for Oberon-07 more precisely, without increasing the size of the report in any way worth talking about.


Title: Re: Four questions about Oberon-07
Post by: trijezdci on January 13, 2013, 08:14:05 PM
I like the crisp simplicity of Oberon-07's removal of automatic type conversion

I never understood why Oberon featured type inclusion in the first place. Clearly this weakens type safety and implicit conversions are a potential source of confusion leading to bugs. Of course explicit type conversions can be inconvenient. In Modula-2 the names of conversion functions were also inconsistent. But that is not a good reason to make them implicit. Instead one should realise that type conversions are important enough to deserve a specific conversion operator. Introducing a conversion operator not only makes the language cleaner, it also makes the specification smaller because the operator only needs to be explained once whereas each conversion function requires its own explanation. It doesn't increase complexity either because under an implicit conversion regime, the conversions have to be implemented anyway and the compiler needs to figure out from context which conversion applies. This latter part is not required when conversions are explicit.


the question I sent had nothing to do with this (or any other) forum. I sent it about two years ago when I was working on my compiler for Oberon-07. My question was worded precisely. Moreover, I hardly think the solution required an "in-depth analysis" or a "bloated" solution! (The question was essentially "do the arguments of relations have to be of the same type, the way they are for arithmetic operators?")

I didn't mean to suggest you had not put your question precisely and without context. I was merely cautioning not to read gospel into each and every statement that Professor Wirth once made. Some people often appear to be doing just that.

A specification is supposed to be a precise and concise description of the desired behaviour of a yet-to-be-constructed system. (...) I think it's possible to write down the rules for Oberon-07 more precisely, without increasing the size of the report in any way worth talking about.

Agreed. Even if the report was to double or triple in size, and that is a very big "if", then it might hurt pride and bragging rights of some Oberon afficionados but it would hardly make the report bloated. It would still be very small.


Title: Re: Four questions about Oberon-07
Post by: kevinhely on January 13, 2013, 09:09:24 PM
I never understood why Oberon featured type inclusion in the first place...

I completely agree. There's an extra bonus to omitting automatic type conversion: it makes the compiler writer's job easier and the resulting (compiler) code nicer!

I didn't mean to suggest you had not put your question precisely and without context. I was merely cautioning not to read gospel into each and every statement that Professor Wirth once made.

:) No offence taken! But, a specification is gospel! It has to be.

Agreed. Even if the report was to double or triple in size, and that is a very big "if", then it might hurt pride and bragging rights of some Oberon afficionados but it would hardly make the report bloated. It would still be very small.

Well, I think some careful rewording and a little rearranging here and there of the defining document would sort out all of the difficulties I've had and probably not affect the page count. But, you've hit on an important point: part of the "spirit" of Oberon-07 is to demonstrate that "small is good" (I remember Wirth's "Plea for Lean Software") but achieving conciseness by committing the "sin of omission" (Dijkstra) weakens that message.


Title: Re: Four questions about Oberon-07
Post by: cfbsoftware on January 13, 2013, 09:36:24 PM
I think it's possible to write down the rules for Oberon-07 more precisely, without increasing the size of the report in any way worth talking about.
Then do it.


Title: Re: Four questions about Oberon-07
Post by: kevinhely on January 14, 2013, 01:03:24 AM
Then do it.

Well, I'll do it if I get unambiguous answers to the questions I've posed. But here's a simple example: alternative specifications of the arithmetic operators below, one from the report, the other correct!


Title: Re: Four questions about Oberon-07
Post by: cfbsoftware on January 14, 2013, 03:40:41 AM
That's a good start. What is the difference betwen 'same type' and 'identical type'?


Title: Re: Four questions about Oberon-07
Post by: trijezdci on January 14, 2013, 12:01:25 PM
What is the difference betwen 'same type' and 'identical type'?

That depends on the default type equivalence regime and it underlines why it makes sense to state the prevailing type equivalence regime in a language specification. Even then terminology may be open to interpretation and would likely be interpreted differently depending on the prevailing type regime.

Under name equivalence type identity is defined by the name of a type, thus a type can only be identical to itself, never to any other type. The term "same type" could then be interpreted as a type that is compatible but not identical. Compatibility then depends on the type regime and whether or not anonymous types are permitted.

A commonly used terminology is "alias type" or "derived type".

TYPE Celsius = REAL; Fahrenheit = REAL;

In this example both Celsius and Fahrenheit are alias types of REAL. Under lose name equivalence derived types are compatible with the type they are derived from and with each other. Under strict name equivalence they are not. Languages with strict name equivalence often provide a means to declare intentionally compatible alias types though. Such an intentionally compatible alias type may then be considered "the same type".

TYPE INT = ALIAS OF INTEGER;

Here, INT and INTEGER are "the same type" even under strict name equivalence.

In any event, the point is that it is important to clearly define the type regime and terminology first.

My recommendation would be to do something like this ...

Definition of Expression Compatibility
Two types T1 and T2 are expression compatible:
- if T1 is identical to T2, or
- if T1 is an alias type of T2, or
- if T2 is an alias type of T1, or
...

Definition of Type Identity
Two types are identical if they have the same type identifier.

Definition of Alias Type
For every type declaration of the form:
TYPE T1 = T2;
T1 is called an alias type of T2.

etc etc

At this point it suffices to state that all operands in an expression must be expression compatible.

PS: It is easy to overlook borderline cases with anonymous types and leave room for interpretation. Therefore, use cases with anonymous types need to be carefully considered and covered in compatibility definitions.


Title: Re: Four questions about Oberon-07
Post by: Dsar on January 14, 2013, 01:16:51 PM
The report should be improved in more parts, for example I would move all assignment rules under the assignment statement, in particular procedure type and pointer assignment in the case of type extension. Pointer assignment is implicitly related to the record type, and it is not clear to get in one shot.

Also latest changes make thing more confusing:
In Oberon '90 we had: "The type of the expression must be included by the type of the variable, or it must extend the type of the variable."
It is clear that this covers pointer and record type.

We have now:
"The type of the expression must be the same as that of the designator. The following exceptions hold:
[...]
3. In the case of records, the type of the source must be an extension of the type of the destination."

Does it include the pointer type?

This uncertainty is also in the variable parameter part:

"For variable parameters, it must be identical to the corresponding actual parameter's type, except in the case of a record, where it must be a base type of the corresponding actual parameter's type."

Does it include the pointer type?

The fact that the pointer relation with record type extension is now moved to the Pointer Type section, imho, make the understanding more difficult.

In Oberon '87 the sentence was clearer: "For variable parameters, it must be a base type of the type of the corresponding actual parameter."

The semantic of value parameters was clear in the Oberon '90, because there was the statement: "For value parameters, the rule of assignment holds (see 9.1)."
In Oberon '87 we also had: "For value parameters, the rule of assignment holds (see 9.1), except if the parameter is an open array: [...]."

With this sentence it was clear the nature of value parameter passing and that open arrays follow structural equivalence only during parameter passing.

Now that we have structured value parameters in read only mode, this statement was removed and now it is hard to get. In my opinion the old sentence could be left because in the assignment statement we have the clause that if a value parameter is structured no assignment is possible.


Older Oberon report:
1987: http://e-collection.library.ethz.ch/view/eth:3189
1989: http://e-collection.library.ethz.ch/view/eth:3205
1990: http://e-collection.library.ethz.ch/view/eth:3279


Title: Re: Four questions about Oberon-07
Post by: kevinhely on January 14, 2013, 01:56:03 PM
That's a good start. What is the difference betwen 'same type' and 'identical type'?

In this instance, the word "identical type" is the phrase to use ("two objects have identical type" meaning they have the same type name). In the example I posted, I made the minimum change to illustrate the point. I have more examples but I'm waiting for clarification on an issue or two.


Title: Re: Four questions about Oberon-07
Post by: kevinhely on January 14, 2013, 02:12:40 PM
3. In the case of records, the type of the source must be an extension of the type of the destination."

Does it include the pointer type?

I think so, because 6.4 states
Quote
Pointer types inherit the extension relation of their base types, if there is any
I didn't find that difficult to locate but, I agree, it would do no harm to mention it explicitly in the section on assignment. I've restructured some sections (for my own clarification) and it seems to make things clearer.

Now that we have structured value parameters in read only mode, this statement was removed and now it is hard to get. In my opinion the old sentence could be left because in the assignment statement we have the clause that if a value parameter is structured no assignment is possible.
I agree.


Title: Re: Four questions about Oberon-07
Post by: trijezdci on January 14, 2013, 02:29:32 PM
In this instance, the word "identical type" is the phrase to use ("two objects have identical type" meaning they have the same type name).

I very much doubt you can do an unambiguous specification without providing definitions for those terms.


Title: Re: Four questions about Oberon-07
Post by: kevinhely on January 14, 2013, 03:35:20 PM
Which terms? Not "identical", surely?


Title: Re: Four questions about Oberon-07
Post by: trijezdci on January 14, 2013, 06:32:56 PM
Which terms? Not "identical", surely?

Personally, I would even define type identity, yes. I wouldn't use the term "same type" but if I did, I would define it. It is better to define even a seemingly obvious term than leave opportunity to misinterpret it.

With the report for our revision of M2 we started out not giving definitions for terminology we considered obvious. But what seemed obvious to us wasn't always obvious to others, some very smart people included. Now we provide definitions for just about everything, including terms that might be considered obvious such as actual and formal parameter, named and anonymous type, open array, type transfer, type cast, type conversion and even procedure.

Also, consider that for many "obvious" terms there are subtle but significant differences in meaning between languages. Readers who are not already familiar with the specific meaning of a term as it relates to Oberon will likely misinterpret the specification if the terminology is obvious to them in the context of another language. To avoid any surprises, it is advisable to provide a definition for every term you use.


Title: Re: Four questions about Oberon-07
Post by: kevinhely on January 14, 2013, 08:22:04 PM
What other meaning could you ascribe to the word "identical"?

Now we provide definitions for just about everything, including terms that might be considered obvious such as actual and formal parameter, named and anonymous type, open array, type transfer, type cast, type conversion and even procedure.

I think perhaps that's better left to an introductory textbook on programming. I don't think it's necessary in a programming language specification, which is not intended to be read by people who don't know established elementary programming concepts.


Title: Re: Four questions about Oberon-07
Post by: trijezdci on January 14, 2013, 08:31:30 PM
What other meaning could you ascribe to the word "identical"?

It's not about the word identical, but about a definition of type identity, as opposed to mere type equivalence. The distinction is not as obvious as it may seem.

Consider the type declaration

TYPE Celsius = REAL;

Somebody unfamiliar with name equivalence may be forgiven to think that Celsius is identical to REAL.


Title: Re: Four questions about Oberon-07
Post by: trijezdci on January 14, 2013, 08:36:29 PM
I think perhaps that's better left to an introductory textbook on programming. I don't think it's necessary in a programming language specification, which is not intended to be read by people who don't know established elementary programming concepts.

That's what I thought initially but feedback from peer review convinced me otherwise. Mind you, the people who convinced me are not the ones who don't know established elementary programming concepts ;-)

As I had mentioned, programming terminology is not consistent across all programming languages.


Title: Re: Four questions about Oberon-07
Post by: cfbsoftware on January 14, 2013, 11:09:19 PM
In this instance, the word "identical type" is the phrase to use ("two objects have identical type" meaning they have the same type name). In the example I posted, I made the minimum change to illustrate the point. I have more examples but I'm waiting for clarification on an issue or two.
'Identical' is commonly used to compare two different objects. e.g. Identical twins *look* the same but they are not the same; "A similar crime was committed by an identical person" is very different from "A similar crime was committed by the same person".

If you mean they have the *same* type name rather than an *identical* type name then you should say they have the same type name.


Title: Re: Four questions about Oberon-07
Post by: kevinhely on January 15, 2013, 01:27:43 AM
'Identical' is commonly used to compare two different objects. e.g. Identical twins *look* the same but they are not the same; "A similar crime was committed by an identical person" is very different from "A similar crime was committed by the same person".

If you mean they have the *same* type name rather than an *identical* type name then you should say they have the same type name.

Can you give me an example of identical type names that are not the same name in Oberon-07?


Title: Re: Four questions about Oberon-07
Post by: kevinhely on January 15, 2013, 01:31:11 AM
Consider the type declaration

TYPE Celsius = REAL;

Somebody unfamiliar with name equivalence may be forgiven to think that Celsius is identical to REAL.

You cannot have such a declaration in Oberon-07. And I think that's the result of a conscious design decision. My goals are modest and confined to a precise and concise description of Oberon-07 (and nothing else, for the moment)!


Title: Re: Four questions about Oberon-07
Post by: trijezdci on January 15, 2013, 02:34:12 AM
You cannot have such a declaration in Oberon-07. And I think that's the result of a conscious design decision.

Gosh, this was just an example to illustrate how perception or different background can lead to different interpretation. Oberon does allow anonymous types, or does it not?! So, here's another example ...

TYPE Foo, Bar = ARRAY Baz OF Bam;

or ...

TYPE Foo = ARRAY Baz OF Bam;
TYPE Bar = ARRAY Baz OF Bam;


In the former case they would likely be considered equivalent but perhaps not identical under name equivalence, yet they may well be considered identical under structural equivalence. In the latter case they are unlikely to be considered equivalent nor identical under name equivalence, but would be considered equivalent, possibly even identical under structural equivalence.

Point in case, it is not always as obvious as it may seem. (Mis-)Interpretation is possible, depending on background. Definition of terminology avoids such uncertainty.


Title: Re: Four questions about Oberon-07
Post by: cfbsoftware on January 15, 2013, 03:48:06 AM
Can you give me an example of identical type names that are not the same name in Oberon-07?
ModuleX.TypeA;
ModuleY.TypeA;


Title: Re: Four questions about Oberon-07
Post by: cfbsoftware on January 15, 2013, 03:59:20 AM
Definition of terminology avoids such uncertainty.
Definition of terminology *lessens the possibility of* such uncertainty.

A non-trivial Programming Language specification written using a language like English will always be subject to some level of uncertainty if used in isolation. Useful additional resources to clarify potential uncertainties and ambiguities include complete examples (both working and non-working), a validation suite, a reference compiler and a programmers tutorial.


Title: Re: Four questions about Oberon-07
Post by: kevinhely on January 15, 2013, 12:08:42 PM
Can you give me an example of identical type names that are not the same name in Oberon-07?
ModuleX.TypeA;
ModuleY.TypeA;

??! These are two different qualified identifiers. In a given module, the first type name is not TypeA, it's ModuleX.TypeA, which is different from ModuleY.TypeA!


Title: Re: Four questions about Oberon-07
Post by: kevinhely on January 15, 2013, 12:17:04 PM
Point in case, it is not always as obvious as it may seem. (Mis-)Interpretation is possible, depending on background. Definition of terminology avoids such uncertainty.

The best way to avoid uncertainty with such terminology is not to use it, IMO. All this discussion about name equivalence etc. is all very interesting but not relevant (I think) to the issue I opened this thread with, which is to clarify a couple of questions about the Oberon-07 specification. The only type "equivalences" or "compatibilities" that need to be clarified in Oberon-07 are the ones that matter (e.g. for the assignment command, operators, and procedure call/parameter correspondence).


Title: Re: Four questions about Oberon-07
Post by: kevinhely on January 15, 2013, 12:24:02 PM
Definition of terminology *lessens the possibility of* such uncertainty.
I agree.

A non-trivial Programming Language specification written using a language like English will always be subject to some level of uncertainty if used in isolation. Useful additional resources to clarify potential uncertainties and ambiguities include complete examples (both working and non-working), a validation suite, a reference compiler and a programmers tutorial.
I agree that the additional resources may be useful but they can't replace the specification or even be a (longer-winded) part of it.

As I've said above, I think the remaining ambiguities in the definition of Oberon-07 can be addressed in a concise way. I don't have any problem with a specification that demands to be read with care and attention.


Title: Re: Four questions about Oberon-07
Post by: trijezdci on January 15, 2013, 12:36:47 PM
The only type "equivalences" or "compatibilities" that need to be clarified in Oberon-07 are the ones that matter (e.g. for the assignment command, operators, and procedure call/parameter correspondence).

Which is why I suggested to define compatibility, such as expression compatibility. Yes, there is also assignment compatibility and parameter passing compatibility and each may require its own definition.


Title: Re: Four questions about Oberon-07
Post by: kevinhely on January 15, 2013, 01:48:27 PM
The only type "equivalences" or "compatibilities" that need to be clarified in Oberon-07 are the ones that matter (e.g. for the assignment command, operators, and procedure call/parameter correspondence).

Which is why I suggested to define compatibility, such as expression compatibility. Yes, there is also assignment compatibility and parameter passing compatibility and each may require its own definition.

Actually, I think it's possible to define compatibility as a function of type alone, independently of assignment, parameter passing, etc. and define the latter in terms of the one concept. I'll post a draft later for your inspection (I'm on a train at the moment)...


Title: Re: Four questions about Oberon-07
Post by: trijezdci on January 15, 2013, 02:13:54 PM
I think it's possible to define compatibility as a function of type alone, independently of assignment, parameter passing, etc. and define the latter in terms of the one concept.

Yes and no.

Yes because expression compatibility and assignment compatibility may well be interchangeable, that is, if an expression e1 is assignment compatible with another expression e2, then e1 and e2 are also expression compatible.

No because type compatibility is often different for parameter passing. For example when passing an argument to an open array parameter, type compatibility is loose, any type may be passed in. There may be other scenarios where parameter compatibility is tightened relative to assignment and expression compatibility.



Title: Re: Four questions about Oberon-07
Post by: kevinhely on January 15, 2013, 04:33:25 PM
Yes because expression compatibility and assignment compatibility may well be interchangeable, that is, if an expression e1 is assignment compatible with another expression e2, then e1 and e2 are also expression compatible.

No because type compatibility is often different for parameter passing. For example when passing an argument to an open array parameter, type compatibility is loose, any type may be passed in. There may be other scenarios where parameter compatibility is tightened relative to assignment and expression compatibility.

Ok, let me rephrase my previous post. I believe I have managed to define "type compatibility" conditions for certain types and used them to clarify the description of operators, the type correctness of assignment, and of parameter correspondence. I've defined compatibility for types, not for statements or expressions that may use them.


Title: Re: Four questions about Oberon-07
Post by: trijezdci on January 15, 2013, 05:20:42 PM
Procedure types are compatible if their signatures match.

Then define signature (although it is a term of those you call "obvious" to people who know fundamentals of programming) and you're done. Trust me, it *does* help to have properly defined terminology.


Title: Re: Four questions about Oberon-07
Post by: kevinhely on January 15, 2013, 06:49:32 PM
Procedure types are compatible if their signatures match.

Then define signature (although it is a term of those you call "obvious" to people who know fundamentals of programming) and you're done. Trust me, it *does* help to have properly defined terminology.

I didn't use the term "signature". Neither does the Oberon-07 report!

In any case, I've deleted the samples from my preceding post because I'm still working on them.

Trust me, it *does* help to have properly defined terminology.

Who says otherwise? All I'm arguing is that unnecessary terminology is just that --- unnecessary!


Title: Re: Four questions about Oberon-07
Post by: trijezdci on January 15, 2013, 07:20:59 PM
Neither does the Oberon-07 report!

Heaven forbid!


Title: Re: Four questions about Oberon-07
Post by: kevinhely on January 16, 2013, 01:31:41 AM
That's a good start. What is the difference betwen 'same type' and 'identical type'?

In this instance, the word "identical type" is the phrase to use ("two objects have identical type" meaning they have the same type name). In the example I posted, I made the minimum change to illustrate the point. I have more examples but I'm waiting for clarification on an issue or two.

I've revised my suggested modification of the rule for arithmetic operations so that it has "same type" from the original rather than my "identical type". (Why? Because it's possible, via a type declaraction, to make the name that referred to a type in one scope refer to a different type in another scope in the same module.)


Title: Re: Four questions about Oberon-07
Post by: cfbsoftware on January 16, 2013, 04:01:21 AM
I've revised my suggested modification of the rule for arithmetic operations so that it has "same type" from the original rather than my "identical type".
Good to hear! It makes more sense to me.


Title: Re: Four questions about Oberon-07
Post by: kevinhely on January 17, 2013, 02:49:56 AM
I've received an email from Prof Wirth, who stated that the report is not "entirely clear" on these matters, and concluded that (after some studying) the answer to all four questions is "YES"!  :)


Title: Re: Four questions about Oberon-07
Post by: leledumbo on January 17, 2013, 06:55:50 AM
Quote
I've received an email from Prof Wirth, who stated that the report is not "entirely clear" on these matters, and concluded that (after some studying) the answer to all four questions is "YES"!
Looks like he'll make the 4th revision of the report...


Title: Re: Four questions about Oberon-07
Post by: Dsar on January 17, 2013, 09:48:19 AM
I've received an email from Prof Wirth, who stated that the report is not "entirely clear" on these matters, and concluded that (after some studying) the answer to all four questions is "YES"!  :)

Then any thought about the constant string is wrong, it is compatible with arrays of characters, or better.. the constant string is an array of characters. The only exception is that the assignment of a constant string to an array is structural.

Open arrays are of structural equivalence not only during parameter assignment but also inside a procedure body? Then the parameter passing for open array is not an exception, but it is full of generality also in the assignment.

By the way, this goes against any Oberon and Modula-2 compiler I used in the past, just tried with ethoberon and it returns "err 113  incompatible assignment" with v := e (v as open array and e as a fixed array).

Looks like he'll make the 4th revision of the report...

He's already doing it, it will contain the basic type BYTE



Title: Re: Four questions about Oberon-07
Post by: cfbsoftware on January 17, 2013, 11:37:08 AM
He's already doing it, it will contain the basic type BYTE
Because of its wide application to embedded software we introduced a built-in BYTE type in Astrobe as an Oberon language extension last year. I will be pleased if and when it does get included in the base language definition.


Title: Re: Four questions about Oberon-07
Post by: kevinhely on January 17, 2013, 04:22:28 PM
Then any thought about the constant string is wrong, it is compatible with arrays of characters, or better.. the constant string is an array of characters.
No. A string may be assigned to or compared with an array of characters but they are not the same, e.g. you cannot apply the array element operator to a string.

By the way, this goes against any Oberon and Modula-2 compiler I used in the past...
That's ok: they're not the same language!  :)


Title: Re: Four questions about Oberon-07
Post by: Dsar on January 17, 2013, 05:09:17 PM
No. A string may be assigned to or compared with an array of characters but they are not the same, e.g. you cannot apply the array element operator to a string.

You cannot be sure of that, because if Wirth says that an array is comparable with a string, then he used the term array in place of string.
Also, [ ] can be used on constants (not constant literals):

8.1. Operands
With the exception of sets and literal constants, i.e. numbers and strings, operands are denoted by
designators. A designator consists of an identifier referring to the constant, variable, or procedure to
be designated.
[...]
and it may be followed by selectors, if the designated object is an element of a structure.

In the Oberon for ARM Processor paper, Wirth repeatedly says that string is the only exception for a structured constant.

By the way, I stopped to follow the report word by word

That's ok: they're not the same language!

Well, tell me where the difference is written comparing both Oberon and Oberon-07 report

(P.S. Could you share the content of these email via a private message?)


Title: Re: Four questions about Oberon-07
Post by: kevinhely on January 17, 2013, 05:47:58 PM
You cannot be sure of that, because if Wirth says that an array is comparable with a string, then he used the term array in place of string.
A string is a constant, an array is not.

In the Oberon for ARM Processor paper, Wirth repeatedly says that string is the only exception for a structured constant.

By the way, I stopped to follow the report word by word
Well, I'm afraid, I'm interested at the moment in Oberon-07, which is defined in the Oberon-07 report (however precise or not). Oberon for ARM is (slightly) different.

Well, tell me where the difference is written comparing both Oberon and Oberon-07 report.
Don't you have a copy of the older Oberon report? I've attached one. There are significant differences.



Title: Re: Four questions about Oberon-07
Post by: Dsar on January 17, 2013, 05:57:01 PM
A string is a constant, an array is not.

[ ] applies also to constants and Wirth uses the term array of characters in place of strings

Don't you have a copy of the older Oberon report? I've attached one. There are significant differences.

I have all Oberon reports, I asked you to point me the differences on open arrays between Oberon and Oberon-7


Title: Re: Four questions about Oberon-07
Post by: kevinhely on January 17, 2013, 06:06:51 PM
You wrote:
Well, tell me where the difference is written comparing both Oberon and Oberon-07 report

All I'm saying is, what holds for Oberon does not hold for Oberon-07, unless it is specified in the Oberon-07 report. If something also isn't specified in the original Oberon report, then I don't see how it can (be said to) hold for that language either. It is the same issue I've highlighted above, viz. that the report is unclear in places. But the way to address that problem is to talk to the author of the report (designer of the language).


Title: Re: Four questions about Oberon-07
Post by: Dsar on January 17, 2013, 06:29:41 PM
If something also isn't specified in the original Oberon report, then I don't see how it can (be said to) hold for that language either. It is the same issue I've highlighted above, viz. that the report is unclear in places. But the way to address that problem is to talk to the author of the report (designer of the language).

Ok, the point is: the report is too untrustworthy for a precise definition of all behaviours like that on open arrays, because there a lot (not some) of missing points. Instead you look too confident about it

(P.S. Could you share the content of these email via a private message?)



Title: Re: Four questions about Oberon-07
Post by: kevinhely on January 17, 2013, 07:08:09 PM
Instead you look too confident about it

?


Title: Re: Four questions about Oberon-07
Post by: kevinhely on January 17, 2013, 07:10:33 PM
He's already doing it, it will contain the basic type BYTE
Because of its wide application to embedded software we introduced a built-in BYTE type in Astrobe as an Oberon language extension last year. I will be pleased if and when it does get included in the base language definition.
Unfortunately, that will partially bring back the business of subtypes, which complicates things. (Don't get me wrong: I understand the need for a BYTE type.)


Title: Re: Four questions about Oberon-07
Post by: Dsar on January 17, 2013, 07:33:02 PM
Instead you look too confident about it

?

I mean, it would be fair to say "maybe", there is no unambiguous answer to every questions about the report.
For me it looks strange that Wirth allows the assignment to open arrays, for example in the first oberon report he stated that open array can only be accessed element by element (this to prevent string assignment to an open array). This because of the fragility of open array due to runtime errors.

This is why I asked for the email


Title: Re: Four questions about Oberon-07
Post by: kevinhely on January 17, 2013, 07:58:39 PM
I mean, it would be fair to say "maybe", there is no unambiguous answer to every questions about the report.
For me it looks strange that Wirth allows the assignment to open arrays, for example in the first oberon report he stated that open array can only be accessed element by element (this to prevent string assignment to an open array). This because of the fragility of open array due to runtime errors.

I don't think you're getting my point (or I'm not being clear), which is that a specification is by definition (supposed to be) the gospel truth! What is written there is the definition of the language. If it is ambiguously worded, then the only trustworthy recourse is (in this instance) to talk to the person who wrote the specification.

The question of why the language is designed that way may be interesting but it is a separate matter from deciding whether or not something is permitted by the definition.


Title: Re: Four questions about Oberon-07
Post by: Dsar on January 19, 2013, 09:44:09 PM

For what I understand, Wirth came back to the original intent of structural equivalence between arrays but open arrays are (of course) not assignable.

Quote
Yes, the Report is somewhat vague about the assignment to arrays and open arrays. My opinion and intention is that arrays cannot be assigned to open array variables. Assume

    PROCEDURE P(x, y: ARRAY OF INTEGER);
        VAR a: ARRAY 10 OF INTEGER;
            b: ARRAY 20 OF INTEGER;
    BEGIN a := b; b := a; a := x; x := a; x := y
    END P;

Of these only a := b and a := x are admitted. In the first case, the length of a must not be greater than the length of b. Assignments to open arrays are not admitted, even if x and y are declared as VAR parameters.


Title: Re: Four questions about Oberon-07
Post by: kevinhely on January 19, 2013, 11:34:01 PM
For what I understand, Wirth came back to the original intent of structural equivalence between arrays but open arrays are (of course) not assignable.

I received that email too, and am awaiting a further response...


Title: Re: Four questions about Oberon-07
Post by: Dsar on January 19, 2013, 11:54:08 PM
I received that email too, and am awaiting a further response...

Uhm, what kind of response?


Title: Re: Four questions about Oberon-07
Post by: cfbsoftware on January 21, 2013, 04:02:24 AM
Quote
Assume

    PROCEDURE P(x, y: ARRAY OF INTEGER);
        VAR a: ARRAY 10 OF INTEGER;
            b: ARRAY 20 OF INTEGER;
    BEGIN a := b; b := a; a := x; x := a; x := y
    END P;

Of these only a := b and a := x are admitted. In the first case, the length of a must not be greater than the length of b.

1. Which revision of the Oberon report is being referenced for this example?

2. If it is a revision of the Oberon report which allows different length arrays of the same type to be assignment compatible, shouldn't it say:

  "Of these only b := a and a := x are admitted."

or am I missing something?


Title: Re: Four questions about Oberon-07
Post by: Dsar on January 21, 2013, 12:30:04 PM
I think Wirth refers to the last report. He come back to the behaviour of the 2008 report, but there was an error.

In the assignment statement there was:

Quote
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.
[...]
4. In the case of records, the type of the destination must be an extension of the type of the source.

But this was an error, because it doesn't follow subtype rules (and this was not what Wirth intended, because the original general type rule of Oberon-90 was: "The type of the expression must be included by the type of the variable, or it must extend the type of the variable.")

Indeed it is now:

Quote
3. In the case of records, the type of the source must be an extension of the type of the destination.

For array it has to work like the projection of record type, an array with a greater length is like an extension of one with a shorter length. This is why a := b is permitted in that example



Title: Re: Four questions about Oberon-07
Post by: kevinhely on January 21, 2013, 07:57:50 PM
From Prof Wirth:

Quote
1. For a := b, the condition len(a) = len(b) was relaxed to len(a) <= len(b), in analogy to records, where an extension can be assigned to a base type.

2. x := "abc" is indeed admitted (even if x is dynamic), because a string is not an array, although it can be assigned to an array.

(a := b is from the procedure quoted in preceding posts, and x is an open character array.)

Alas, this means there is a disturbing difference in the rules for assigning arrays to arrays (>=) and strings to arrays (<=).


Title: Re: Four questions about Oberon-07
Post by: Dsar on January 23, 2013, 12:45:22 AM
Alas, this means there is a disturbing difference in the rules for assigning arrays to arrays (>=) and strings to arrays (<=).

An array of three reals is useful if considered an extension of an array of two reals, but.. a string larger than an array is not (useful as) an extension of it, and in that case you have a truncation. In a strong type system it should be that the string has to have the same length with the array, but this is very uncomfortable. I see the string assignment to array as an "utility" (like the old COPY) that doesn't belong to the type system. With COPY it was consistent, but it is ok for me this little concession.

In Ada for example if you have an array of strings, all strings have to be of the same length with the array, then you have to add padding spaces and the result is something like "Hello world!           ". In Ada the type system is very strong but often uncomfortable where there is no danger



Title: Re: Four questions about Oberon-07
Post by: cfbsoftware on January 23, 2013, 03:29:48 AM
An array of three reals is useful if considered an extension of an array of two reals,
"is useful" --> "might be useful"

Unfortunately in some circumstances assignment compatibility of different sized arrays might be less than useful. e.g:

TYPE
   DailyTotals = ARRAY 7 OF INTEGER;
   WeeklyTotals = ARRAY 52 OF INTEGER;

VAR
   d: DailyTotals;
   w: WeeklyTotals;
...
...
  d := w; (* ??? *)

To avoid these sorts of problems, if an array type is to be considered to be an extension of another array type then the programmer needs some mechanism to be able to declare that it so.


Title: Re: Four questions about Oberon-07
Post by: Dsar on January 23, 2013, 12:12:15 PM
"is useful" --> "might be useful"

Yes, you are right, but as physicist I like this behaviour, but it doesn't follow any logic if one uses the array type as a general container.

Of course the old behaviour (with no structural assignment) keeps the type system more consistent



Title: Re: Four questions about Oberon-07
Post by: kevinhely on January 26, 2013, 06:21:16 PM
Latest news: that new rule for array assignment is revoked. For array assignment x := y, Prof. Wirth states:

Quote
length of x must be not less than length of y.


Title: Re: Four questions about Oberon-07
Post by: cfbsoftware on January 27, 2013, 03:03:18 AM
Latest news: that new rule for array assignment is revoked. For array assignment x := y, Prof. Wirth states:

Quote
length of x must be not less than length of y.
Sounds like we are back to square one i.e. as described in exception #2 of Section 9.1 "Assignments" of the 2007 / 2008 revisions of the Oberon Language Report:

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

This is consistent with the sort of behaviour that is described in detail (with examples of the code generated) in section 17. "Assignment of Arrays" of the document "An Oberon Compiler for the ARM Processor":

http://www.inf.ethz.ch/personal/wirth/Articles/Oberon.html


Title: Re: Four questions about Oberon-07
Post by: kevinhely on January 27, 2013, 11:44:32 AM
Sounds like we are back to square one i.e. as described in exception #2 of Section 9.1 "Assignments" of the 2007 / 2008 revisions of the Oberon Language Report

Indeed it does. Alas, the exception is not present in the latest (22.9.2011) version...


Title: Re: Four questions about Oberon-07
Post by: augustk on February 04, 2013, 05:34:16 PM
As a (very) minor note, I also hope that the upcoming revision of the language report will have corrected the jarring italic left parenthesis after the Einstein quote.


Title: Re: Four questions about Oberon-07
Post by: augustk on February 16, 2013, 12:05:24 PM
Below are a couple of pointer declarations where it is also hard to tell from the language report whether declaration two and three is valid or not (this was brought up by me in comp.lang.oberon some time ago).

TYPE
        P0 = POINTER TO RECORD END;
        P1 = POINTER TO RECORD (P0) END;
        P = POINTER TO RECORD x: P END;


Section 26.1 and 26.3 of "An Oberon Compiler for the ARM Processor" by Niklaus Wirth confirm that they are indeed valid.

http://www.inf.ethz.ch/personal/wirth/Articles/Oberon/Oberon.ARM.Compiler.pdf