Oberon Community Platform Forum
December 10, 2019, 09:49:05 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 ... 4 5 [6] 7
  Print  
Author Topic: Four questions about Oberon-07  (Read 64222 times)
kevinhely
Newbie
*
Posts: 44


« Reply #75 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).
« Last Edit: January 17, 2013, 06:13:36 PM by kevinhely » Logged
Dsar
Newbie
*
Posts: 40


« Reply #76 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?)

Logged
kevinhely
Newbie
*
Posts: 44


« Reply #77 on: January 17, 2013, 07:08:09 PM »

Instead you look too confident about it

?
Logged
kevinhely
Newbie
*
Posts: 44


« Reply #78 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.)
Logged
Dsar
Newbie
*
Posts: 40


« Reply #79 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
Logged
kevinhely
Newbie
*
Posts: 44


« Reply #80 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.
Logged
Dsar
Newbie
*
Posts: 40


« Reply #81 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.
Logged
kevinhely
Newbie
*
Posts: 44


« Reply #82 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...
Logged
Dsar
Newbie
*
Posts: 40


« Reply #83 on: January 19, 2013, 11:54:08 PM »

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

Uhm, what kind of response?
Logged
cfbsoftware
Full Member
***
Posts: 107


WWW
« Reply #84 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?
Logged

Chris Burrows
Astrobe v7.0 (Feb 2019): Oberon for ARM Cortex-M3, M4 and M7 Microcontrollers
http://www.astrobe.com
Dsar
Newbie
*
Posts: 40


« Reply #85 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

Logged
kevinhely
Newbie
*
Posts: 44


« Reply #86 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 (<=).
« Last Edit: January 22, 2013, 07:40:52 PM by kevinhely » Logged
Dsar
Newbie
*
Posts: 40


« Reply #87 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

Logged
cfbsoftware
Full Member
***
Posts: 107


WWW
« Reply #88 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; (* Huh *)

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.
« Last Edit: January 23, 2013, 03:34:35 AM by cfbsoftware » Logged

Chris Burrows
Astrobe v7.0 (Feb 2019): Oberon for ARM Cortex-M3, M4 and M7 Microcontrollers
http://www.astrobe.com
Dsar
Newbie
*
Posts: 40


« Reply #89 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

Logged
Pages: 1 ... 4 5 [6] 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!