Oberon Community Platform Forum
December 14, 2019, 05:24:38 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 ... 3 4 [5] 6 7
  Print  
Author Topic: Four questions about Oberon-07  (Read 64340 times)
trijezdci
Newbie
*
Posts: 16


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

Logged
kevinhely
Newbie
*
Posts: 44


« Reply #61 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.
« Last Edit: January 15, 2013, 06:50:03 PM by kevinhely » Logged
trijezdci
Newbie
*
Posts: 16


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


« Reply #63 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!
« Last Edit: January 15, 2013, 06:54:58 PM by kevinhely » Logged
trijezdci
Newbie
*
Posts: 16


« Reply #64 on: January 15, 2013, 07:20:59 PM »

Neither does the Oberon-07 report!

Heaven forbid!
Logged
kevinhely
Newbie
*
Posts: 44


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


WWW
« Reply #66 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.
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 #67 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"!  Smiley
Logged
leledumbo
Jr. Member
**
Posts: 96



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


« Reply #69 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"!  Smiley

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

Logged
cfbsoftware
Full Member
***
Posts: 107


WWW
« Reply #70 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.
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 #71 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!  Smiley
« Last Edit: January 17, 2013, 05:05:39 PM by kevinhely » Logged
Dsar
Newbie
*
Posts: 40


« Reply #72 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?)
« Last Edit: January 17, 2013, 05:11:51 PM by Dsar » Logged
kevinhely
Newbie
*
Posts: 44


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


* Oberon.Report.pdf (82.84 KB - downloaded 310 times.)
« Last Edit: January 17, 2013, 05:56:30 PM by kevinhely » Logged
Dsar
Newbie
*
Posts: 40


« Reply #74 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
Logged
Pages: 1 ... 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!