Oberon Community Platform Forum
December 14, 2019, 06:10:39 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 5 ... 7
  Print  
Author Topic: Four questions about Oberon-07  (Read 64349 times)
kevinhely
Newbie
*
Posts: 44


« Reply #30 on: January 13, 2013, 04:29:05 AM »

My conclusion is that it is non-essential (tell me if you like this):

 Smiley 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.
« Last Edit: January 13, 2013, 04:31:27 AM by kevinhely » Logged
Dsar
Newbie
*
Posts: 40


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


« Reply #32 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.
« Last Edit: January 13, 2013, 02:32:44 PM by trijezdci » Logged
kevinhely
Newbie
*
Posts: 44


« Reply #33 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.
« Last Edit: January 13, 2013, 07:06:00 PM by kevinhely » Logged
trijezdci
Newbie
*
Posts: 16


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


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

Smiley 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.
Logged
cfbsoftware
Full Member
***
Posts: 107


WWW
« Reply #36 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.
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 #37 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!


* Image1.png (11.41 KB, 940x172 - viewed 413 times.)

* Image2.png (12.5 KB, 888x214 - viewed 409 times.)
« Last Edit: January 16, 2013, 01:29:38 AM by kevinhely » Logged
cfbsoftware
Full Member
***
Posts: 107


WWW
« Reply #38 on: January 14, 2013, 03:40:41 AM »

That's a good start. What is the difference betwen 'same type' and 'identical type'?
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 #39 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.
« Last Edit: January 14, 2013, 12:56:50 PM by trijezdci » Logged
Dsar
Newbie
*
Posts: 40


« Reply #40 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
« Last Edit: January 14, 2013, 01:29:29 PM by Dsar » Logged
kevinhely
Newbie
*
Posts: 44


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


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


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


« Reply #44 on: January 14, 2013, 03:35:20 PM »

Which terms? Not "identical", surely?
« Last Edit: January 14, 2013, 03:36:57 PM by kevinhely » Logged
Pages: 1 2 [3] 4 5 ... 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!