Oberon Community Platform Forum
December 14, 2019, 06:34:36 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 6 7
  Print  
Author Topic: Four questions about Oberon-07  (Read 64352 times)
trijezdci
Newbie
*
Posts: 16


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


« Reply #46 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.
« Last Edit: January 14, 2013, 08:27:31 PM by kevinhely » Logged
trijezdci
Newbie
*
Posts: 16


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


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


WWW
« Reply #49 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.
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 #50 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?
Logged
kevinhely
Newbie
*
Posts: 44


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


« Reply #52 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.
« Last Edit: January 15, 2013, 03:17:39 AM by trijezdci » Logged
cfbsoftware
Full Member
***
Posts: 107


WWW
« Reply #53 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;
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 #54 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.
« Last Edit: January 15, 2013, 06:10:56 AM by cfbsoftware » 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 #55 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!
« Last Edit: January 16, 2013, 01:34:52 AM by kevinhely » Logged
kevinhely
Newbie
*
Posts: 44


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


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


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


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