Oberon Community Platform Forum
December 16, 2019, 03:00:51 AM *
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 4 ... 7
  Print  
Author Topic: Four questions about Oberon-07  (Read 64423 times)
cfbsoftware
Full Member
***
Posts: 107


WWW
« Reply #15 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
 
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 #16 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).
« Last Edit: January 17, 2013, 10:14:17 PM by Dsar » Logged
kevinhely
Newbie
*
Posts: 44


« Reply #17 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
Logged
trijezdci
Newbie
*
Posts: 16


« Reply #18 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.


« Last Edit: January 12, 2013, 06:13:27 PM by trijezdci » Logged
Dsar
Newbie
*
Posts: 40


« Reply #19 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
« Last Edit: January 12, 2013, 05:15:26 PM by Dsar » Logged
kevinhely
Newbie
*
Posts: 44


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


« Reply #21 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.
Logged
trijezdci
Newbie
*
Posts: 16


« Reply #22 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.
Logged
trijezdci
Newbie
*
Posts: 16


« Reply #23 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.

Logged
cfbsoftware
Full Member
***
Posts: 107


WWW
« Reply #24 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!  Wink

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

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

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


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


« Reply #26 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... Wink
Logged
cfbsoftware
Full Member
***
Posts: 107


WWW
« Reply #27 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.
Logged

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


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

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


« Reply #29 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 | ...
Logged
Pages: 1 [2] 3 4 ... 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!