Oberon Community Platform Forum
October 13, 2019, 08:41:05 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 2 [3]
  Print  
Author Topic: & and OR, why not AND and OR?  (Read 26667 times)
Dsar
Newbie
*
Posts: 40


« Reply #30 on: July 07, 2011, 01:35:31 PM »

I can not see any advanages of Oberon in this subject.
I think pascal syntax is more comfortable (same sign has same means in different places of code).
I think that ARAY OF may be converted to c-like notations:

   TYPE
      Buffer = CHAR[];
      BufPtr = ^Buffer;
   VAR
      BP: BufPtr;
   (...)
      BP^  (* 'by BP referenced' or simply 'BP-referenced' *)

In the Tremblay's compiler book (p. 100) he discusses why declaration should be different from dereferencing operator, and there is the Wirth proposal:

"The second solution basically depends on what restrictions should be placed on the pointer. There are two restrictions which appear to fill the requirements. The first is to require the pointer to point to an object of a specific type. In other words, one does not declare a variable to be of type "POINTER"; one declares it to be of type, say, "POINTER TO integer." This restriction alone eliminates most of the hazards of pointers.
The second restriction, which has been suggested by Wirth (1974), is that there should be no "address of" operator; that is, it should be possible to make a pointer to point at a named variable. Pointers should point only into anonymous, dynamically allocated heap storage. This largerly prevents the possibly serious confusion arising from referencing the same storage location under several different names."

Anyway I strongly advise to read the chapter about "Language Design" on the Tremblay's book :-)
Logged
Wlad
Newbie
*
Posts: 14


« Reply #31 on: July 08, 2011, 12:44:12 PM »

There are two restrictions which appear to fill the requirements. The first is to require the pointer to point to an object of a specific type. In other words, one does not declare a variable to be of type "POINTER"; one declares it to be of type, say, "POINTER TO integer." This restriction alone eliminates most of the hazards of pointers.
The second restriction, which has been suggested by Wirth (1974), is that there should be no "address of" operator; that is, it should be possible to make a pointer to point at a named variable. Pointers should point only into anonymous, dynamically allocated heap storage. This largerly prevents the possibly serious confusion arising from referencing the same storage location under several different names."

Hmmmmm.... I do not understand (realize) HOW DO my proposals break those requirements Huh?

Code:
TYPE
    NodeDec = RECORD ... END;
    Node = ^NodeDesc;
    ...
VAR
    node : Node;
BEGIN
    ...
    NEW(node);
    ....
    IF node.aField = ...
        aNode^ := node^
    END;
    ...
END ModuleName.

By the way:
"POINTER TO integer."
Wink
Logged
Pages: 1 2 [3]
  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!