Oberon Community Platform Forum
November 22, 2019, 06:50:41 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]
  Print  
Author Topic: Assignment to FOR-Loop variable  (Read 11015 times)
BohdanT
Sr. Member
****
Posts: 271


Life is difficult, but fortunately is short!


WWW
« on: January 20, 2009, 04:40:00 PM »

Today made a typo.
And there was unpleasantly surprised that the compiler does not give to me any a warning  Angry
   
IMHO the compiler should give an error when you try to modify a FOR-Loop variable. It is doing very badly!
Example:
Code:
MODULE ForVar;
IMPORT KernelLog;
PROCEDURE TestFor*;
VAR
 i:LONGINT;
BEGIN
 FOR i:=0 TO 5 DO
KernelLog.String("di= "); KernelLog.Int(i, 0);
  FOR i:=0 TO 2 DO
   (*bla bla bla*)
  END;
 END;
END TestFor;
END ForVar.TestFor~
Gives the result:
Quote
di= 0di= 4di= 4di= 4di= 4di= 4di= 4di= 4di= 4di= 4di= 4di= 4di= 4di= 4di= 4di= 4di= 4di= 4di= 4di= 4di= 4di= 4di= 4di= 4..........
Logged
BohdanT
Sr. Member
****
Posts: 271


Life is difficult, but fortunately is short!


WWW
« Reply #1 on: January 21, 2009, 04:52:51 PM »

Yesterday I've tried to install a cycle variable readonly flag.
In parser FOR-variable is PCT.Symbol type var.

Need to establish readonly-flag in PCB.Designator - Is this correct?

How do I get PCB.Designator from PCT.Symbol ?
Designator.readonly - available only for reading. I.e. establish when creating Designator. Need recreate Designator?

Unfortunately, I was never able to do anything Sad
Logged
cfbsoftware
Full Member
***
Posts: 107


WWW
« Reply #2 on: January 23, 2009, 12:46:12 AM »

IMHO the compiler should give an error when you try to modify a FOR-Loop variable. It is doing very badly!

Unless you are keen to invent a new programming language, I recommend that you think about the situation that you encountered in some more depth.

For example, consider the following points:

* It is not an error according to the definition of the Oberon Language.

* A FOR-Loop variable is not strictly local to the FOR-Loop. While it is highly likely that modifying a FOR-loop control variable is a bludner (sic) it is quite reasonable to expect the variable to be modified elsewhere within its scope.

* It is possible to alias variables via a) pointers and b) globals / parameters. To implement a 100% foolproof warning system without limiting other features of the language might not be feasible.

* A system that sometimes warns, and sometimes doesn't, risks the danger of giving a false sense of security.

* How much complexity should be added to the compiler to save the programmer from his own carelessness? Note that additional complexity usually results in reduced reliability.

* Should the following 'obvious' careless mistake also result in a compiler error?

  i := 0; WHILE i < 100 DO KernelLog.String("di= "); KernelLog.Int(i, 0) END;

* Nature's way of encouraging humans to learn from mistakes is called 'pain'. Systems that encourage continual improvement rather than promoting error-prone activity should be commended. I have a feeling you may make less typos in future.


 
Logged

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


Life is difficult, but fortunately is short!


WWW
« Reply #3 on: January 23, 2009, 11:28:42 AM »

Quote
Unless you are keen to invent a new programming language, I recommend that you think about the situation that you encountered in some more depth.
   
No I do not want!
Need a compiler that would warn of a possible error (My experiments of the last post does not take into account. I want to recompile the whole system that would check how often such a situation. I.e. do the audit)

I want to give another example:
The fact that the function must have RETURN operator also said nothing.

Code:
PROCEDURE a():LONGINT;
BEGIN END a;
You get a compiler warning:
Quote
313: no RETURN in function
I know: that things were not always.
Of course the compiler does not always able to determine that you forgot to return the result.
But he tells about the obviously bug.

Quote
* Should the following 'obvious' careless mistake also result in a compiler error?
  i := 0; WHILE i < 100 DO KernelLog.String("di= "); KernelLog.Int(i, 0) END;
Do not error, as a warning. And it would be cool!

Quote
Nature's way of encouraging humans to learn from mistakes is called 'pain'.
I get pleasure from programming errors, and I was not frustrating. What do you wish Smiley

Quote
Systems that encourage continual improvement rather than promoting error-prone activity should be commended. I have a feeling you may make less typos in future.
   
The system should help to avoid mistakes! This main difference Oberon and С!
« Last Edit: January 23, 2009, 11:33:24 AM by BohdanT » Logged
Pages: [1]
  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!