Oberon Community Platform Forum

Development => Oberon & Active Oberon => Topic started by: leledumbo on November 02, 2010, 07:06:27 AM



Title: & and OR, why not AND and OR?
Post by: leledumbo on November 02, 2010, 07:06:27 AM
I would like to know the reason why Oberon (or was it Modula?) uses & for logical AND operator and OR for logical OR operator. A mix of keywords and symbols that often confuses me (I'm a Pascal programmer, so I use AND for logical AND).


Title: Re: & and OR, why not AND and OR?
Post by: soren renner on November 02, 2010, 06:50:04 PM
So "and/or" should really be "andslashor"?


Title: Re: & and OR, why not AND and OR?
Post by: cfbsoftware on November 03, 2010, 01:14:27 PM
& is not the only operator that changed in the evolution of Oberon from Pascal via Modula-2:

Pascal     Modula-2    Oberon
AND         AND / &         &
NOT         NOT / ~        ~
<>             <> / #        #






Title: Re: & and OR, why not AND and OR?
Post by: leledumbo on November 04, 2010, 06:23:04 AM
Quote
So "and/or" should really be "andslashor"?
Err... no. I think it's better if Wirth uses AND and OR or & and |. Just to stay consistent between symbolic and wordic operators.


Title: Re: & and OR, why not AND and OR?
Post by: cfbsoftware on November 04, 2010, 06:55:36 AM
Err... no. I think it's better if Wirth uses AND and OR or & and |. Just to stay consistent between symbolic and wordic operators.
Consistency is only one of many factors to be considered in the design of a language.

Should DIV, MOD and IN be converted into symbols just for the sake of being consistent?

Alternatively, I hope you are not suggesting that + and - should become PLUS and MINUS?

etc. etc.


Title: Re: & and OR, why not AND and OR?
Post by: sage on November 04, 2010, 09:32:53 AM
"|"
it's used for CASE operator ;)


Title: Re: & and OR, why not AND and OR?
Post by: leledumbo on November 08, 2010, 02:44:48 PM
Quote
Should DIV, MOD and IN be converted into symbols just for the sake of being consistent?
Hmm... I agree with that. But at least they're not alone in the group. For logical operators, OR is the only one that stays as word operator.
Quote
Alternatively, I hope you are not suggesting that + and - should become PLUS and MINUS?
No, of course not.
Quote
it's used for CASE operator
Yes, I think it comes from CFG's alternative operator and to eliminate begin - end.


Title: Re: & and OR, why not AND and OR?
Post by: Dsar on November 18, 2010, 08:52:09 PM
IMHO this is a big flaw.
An advantage of Pascal/Modula-2 over C was readability and I see the removal of the NOT (and others) operator keyword as a drawback.

This sentence:
Code:
IF NOT found THEN

is more readable than:

Code:
IF ~found THEN



Title: Re: & and OR, why not AND and OR?
Post by: leledumbo on November 20, 2010, 09:50:17 AM
Quote
IMHO this is a big flaw.
An advantage of Pascal/Modula-2 over C was readability and I see the removal of the NOT (and others) operator keyword as a drawback.
Agree ;)


Title: Re: & and OR, why not AND and OR?
Post by: soren renner on November 21, 2010, 06:41:21 PM
Agree.

NOT!


Title: Re: & and OR, why not AND and OR?
Post by: cfbsoftware on November 22, 2010, 12:09:51 AM
IMHO this is a big flaw.
An advantage of Pascal/Modula-2 over C was readability and I see the removal of the NOT (and others) operator keyword as a drawback.

"big flaw"? You're surely not serious??? Be wary of the unconscious influence of ingrained habits, preconceived ideas and the inability of old dogs to learn new tricks when making such observations.

For some proper examples of "big flaws" read Section 4 "Programming Language Features" in of "Good Ideas, Through the Looking Glass" by Niklaus Wirth:

www.inf.ethz.ch/personal/wirth/Articles/GoodIdeas.pdf



Title: Re: & and OR, why not AND and OR?
Post by: Dsar on November 22, 2010, 04:15:48 AM
"big flaw"? You're surely not serious??? Be wary of the unconscious influence of ingrained habits, preconceived ideas and the inability of old dogs to learn new tricks when making such observations.

Indeed I've prefixed IMHO :-) In my opinion it's a big flaw. Ok maybe it's not a big flaw, but surely it's a drawback.
I'm a casual programmer (a physicist) and readability is a priority because I'm not used to coding everyday. The code should be obvious at first sight and ~ is a small character that can be easily skipped by eyes.

Of course I'm not in favour of readability at any cost. For example in a book about programming language design (I don't remember the title) there is a candy form of CASE like this:
Code:
CASE ch
  OF  '0' TO '9' DO (* code *)
  OR  'a' TO 'z' DO (* code *)
  OR  'A' TO 'Z' DO (* code *)
END CASE
But in my opinion this is too verbose and it doesn't improve readability over the classic CASE statement.
Code:
CASE ch
  OF  '0' .. '9' : (* code *)
  |   'a' .. 'z' : (* code *)
  |   'A' .. 'Z' : (* code *)
END
This is more concise and readable than the previous one.

But sorry, the NOT keyword helps a lot in readability! And I know a lot of casual programmers like me that switched to alternatives in scientific computing just for readability.

(With alternatives I mean Pascal/Modula-2/Ada etc.)


Title: Re: & and OR, why not AND and OR?
Post by: leledumbo on November 22, 2010, 07:41:08 AM
Even for a non-casual programmer, those who work with codes everyday (like me), readability is still a big concern. I really have no idea why Prof. Wirth do that, is it to make the lexer simpler? Well, keyword looking could be done in O(lg n) where n is the number of keywords time using binary search, but even so Oberon (and other Pascal family) doesn't have many keywords like, for instance, COBOL (300 keywords, ridiculous enough for a programming language) thus making the search time negligible. If you wanna go even faster, store it in a suffix tree but that would violate Prof. Wirth's basic principle in compiler writing: simplicity. And still, Pascal family is the fastest programming language family to parse so I don't think the change would give benefit in speed.


Title: Re: & and OR, why not AND and OR?
Post by: cfbsoftware on November 23, 2010, 12:16:30 AM
I really have no idea why Prof. Wirth do that, is it to make the lexer simpler?

Read "Project Oberon. The Design of an Operating System and Compiler." If you read the commentary in Section 12.5 "The Scanner" and inspect the source code there that might give you some insights into why some decisions were made. You will see that single character symbols are recognised instantly by the scanner in procedure "Get". Multi-character keywords have to be distinguished from identifiers which is a significantly less efficient process handled by procedure "Identifier".

Keep in mind that all of this work was done more than 20 years ago and the entire system was designed to run efficiently on a system with 2 Mb of RAM with a CPU running at a clock speed of 30 MHz or less. That was not a bad specification for a late 1980's machine - it was the first commercially available processor with a 32-bit wide bus. A sensible software designer never assumes that everybody will have access to a machine as powerful as his own.


Title: Re: & and OR, why not AND and OR?
Post by: Dsar on November 23, 2010, 02:34:57 AM
Read "Project Oberon. The Design of an Operating System and Compiler." If you read the commentary in Section 12.5 "The Scanner" and inspect the source code there that might give you some insights into why some decisions were made. You will see that single character symbols are recognised instantly by the scanner in procedure "Get". Multi-character keywords have to be distinguished from identifiers which is a significantly less efficient process handled by procedure "Identifier".
rybody will have access to a machine as powerful as his own.
Ok, what about POINTER TO?
In this case the keyword TO is 100% syntactic sugar, it is totally useless to the meaning of the program; and here the scanner wastes time to hash it and search it in the hash table.
Anyway, I don't agree that the gap between ~ and NOT is noticeable during scanning. Scanning is a slow process in a compiler, whatever decision you take how many seconds do you gain?
Of course in an old machine we are talking about some microseconds, and I think it isn't worth it.



Title: Re: & and OR, why not AND and OR?
Post by: hansklav on November 23, 2010, 04:17:03 AM
IMHO this is a big flaw.
An advantage of Pascal/Modula-2 over C was readability and I see the removal of the NOT (and others) operator keyword as a drawback.

There is good evidence that Wirth made these operator changes over the years with readability in mind, readability in the sense "best resembling mathematical notation":

* In his early books (e.g. 'Systematic Programming' and 'Algorithms + Data Structures = Programs') he uses the mathematical symbols for the Boolean operators (conjunction, disjunction, negation) in Algol and Pascal code listings.

* In the first implementation of the Pascal compiler (for the CDC 6000) these mathematical symbols could be used in Pascal code because the CDC Scientific Character set (6-bits) contained them as valid characters (see the first and second editons of Pascal User Manual and Report by Jensen & Wirth, page 95).

* Also see http://www.pascal-central.com/docs/pascal1973.pdf.

* In mathematical texts the symbols '&' and '~' are sometimes used for logical conjunction and negation (see: http://en.wikipedia.org/wiki/List_of_logic_symbols), so these are reasonable alternatives for the more familiar &and; &not; if only ASCII-characters can be used.

* Within the confines of the ASCII symbol set the symbol # is a good alternative for the mathematical 'unequal' symbol &ne; (at least in Europe, where # is not used as a number sign), so this prompted Wirth to use it in Modula-2 and Oberon.

Because the Restricted ASCII (6-bits) character set which had to be used on most computers in Algol and early Pascal days only contained the '&' character and not the '~' character, only the former was used as an alternative symbol in early Pascal implementations. In the days of Modula-2 the full ASCII (7-bit) character set was used and both '&' and '~' could be used as alternatives for AND and NOT.

That '|' is not used by Wirth as an alternative for OR has good reasons IMHO, also having to do with readability:

The sizes of the operators  '~'  '&' and 'OR' beautifully reflect their operator precedence, the operator with the highest precedence and thus the strongest binding ('~') having the smallest size:

    (p & (~q)) OR (r & s)      =     (p & ~q) OR (r & s)      =     p & ~q OR r & s

With the parentheses removed the order of evaluation of the expression is still easily recognized, largely thanks to the increasing relative size of the operators '~' '&' and 'OR'.

One of the reasons I like Oberon so much...


Title: Re: & and OR, why not AND and OR?
Post by: cfbsoftware on November 23, 2010, 04:25:08 AM
Ok, what about POINTER TO?

Different consideration. Symbols used in expressions vs. words used in declarations.


Title: Re: & and OR, why not AND and OR?
Post by: hansklav on November 23, 2010, 12:05:52 PM
Ok, what about POINTER TO?
In this case the keyword TO is 100% syntactic sugar, it is totally useless to the meaning of the program; and here the scanner wastes time to hash it and search it in the hash table.
Anyway, I don't agree that the gap between ~ and NOT is noticeable during scanning. Scanning is a slow process in a compiler, whatever decision you take how many seconds do you gain?
Of course in an old machine we are talking about some microseconds, and I think it isn't worth it.

I don't think compiler efficiency has anything to do with these syntax changes Wirth made from Pascal to Modula-2 to Oberon. I think the only consideration was readability, both in the AND, OR, NOT case (see my previous posting) and in the case of POINTER TO.

In Pascal the '^' symbol was used both in declarations and in expressions, whereas the meaning and pronunciation was slightly different in both.

  Pascal:

   TYPE
      Buffer = ARRAY [256] OF CHAR;
      BufPtr = ^Buffer;  (* 'pointer to Buffer' *)
   VAR
      BP: BufPtr;  (* pointer type *)
   (...)
      BP^  (* 'by BP pointed to' or 'by BP referenced', i.e. not a pointer type! *)

When I first tried to understand pointers the above syntax was rather confusing.

I found the Modula-2 and later the Oberon syntax more understandable, because there is only one meaning for '^', namely 'by this variable referenced'.

   TYPE
      Buffer = ARRAY OF CHAR;
      BufPtr = POINTER TO Buffer;
   VAR
      BP: BufPtr;
   (...)
      BP^  (* 'by BP referenced' or simply 'BP-referenced' *)




Title: Re: & and OR, why not AND and OR?
Post by: Dsar on November 23, 2010, 05:00:03 PM
There is good evidence that Wirth made these operator changes over the years with readability in mind, readability in the sense "best resembling mathematical notation":

Doing programming and doing mathematics are different beasts. A typical mathematical/physical proof is at most 1-2 pages. Source codes may reach million of pages or more! The understanding should be relaxed for the reader. Software codes should be written like a novel.

The sizes of the operators  '~'  '&' and 'OR' beautifully reflect their operator precedence, the operator with the highest precedence and thus the strongest binding ('~') having the smallest size:

    (p & (~q)) OR (r & s)      =     (p & ~q) OR (r & s)      =     p & ~q OR r & s

With the parentheses removed the order of evaluation of the expression is still easily recognized, largely thanks to the increasing relative size of the operators '~' '&' and 'OR'.

One of the reasons I like Oberon so much...

I will never remove parentheses in expressions because the precedence is obvious by the sizes of the operators. Parentheses are the universal way to organize precedence in expression. People who don't know Oberon in detail can read an expression with parentheses and can recognize precedence at first shot.

Different consideration. Symbols used in expressions vs. words used in declarations.

You were talking about scanning efficiency. In this case there is no different consideration to do.


In Pascal the '^' symbol was used both in declarations and in expressions, whereas the meaning and pronunciation was slightly different in both.

I wasn't issuing that POINTER TO should be a one character symbol, I agree that dereferencing operator shouldn't be used as pointer declaration. I was issuing that TO is purely syntactic sugar and doesn't change the semantic of the program. I can define a language with TYPE Str = POINTER String; without TO and there is no ambiguity.
Wirth accepted the syntactic sugar TO in pointer declaration and removed NOT in favour of ~ for efficiency? I don't think so.



Title: Re: & and OR, why not AND and OR?
Post by: hansklav on November 23, 2010, 09:24:44 PM
There is good evidence that Wirth made these operator changes over the years with readability in mind, readability in the sense "best resembling mathematical notation":

Doing programming and doing mathematics are different beasts. A typical mathematical/physical proof is at most 1-2 pages. Source codes may reach million of pages or more! The understanding should be relaxed for the reader. Software codes should be written like a novel.

Agreed: programming code should read like a novel! But to read and enjoy this 'novel' you have to understand the language. And you understand the language better if it resembles a language you already know. Most programmers are familiar with the language (notation) of mathematics, at least the parts of math that are used frequently in programming languages. So if the programming notation resembles the already familiar mathematical notation it will be easier to learn, understand and enjoy. The resemblance will never be perfect because of the limitations of the characters set we have to use in coding our programs, but Wirth has given us 'the Best You Can Get'.

Another example along this line is the change in set notation from Pascal to Modula-2 and Oberon. In Pascal brackets '[' and ']' were used for sets, and in Modula-2 and Oberon the more familiar braces '{' and '}' used in mathematics. Everybody with only a very faint knowledge of sets recognizes {} as the empty set and {0, 1, 7} as a set of three integers, which in the Pascal notation [] and [0, 1, 7] was not so obvious. This makes the 'novel' of the programming code easier to understand and better to read and enjoy.

The sizes of the operators  '~'  '&' and 'OR' beautifully reflect their operator precedence, the operator with the highest precedence and thus the strongest binding ('~') having the smallest size:

    (p & (~q)) OR (r & s)      =     (p & ~q) OR (r & s)      =     p & ~q OR r & s

With the parentheses removed the order of evaluation of the expression is still easily recognized, largely thanks to the increasing relative size of the operators '~' '&' and 'OR'.

One of the reasons I like Oberon so much...

I will never remove parentheses in expressions because the precedence is obvious by the sizes of the operators. Parentheses are the universal way to organize precedence in expression. People who don't know Oberon in detail can read an expression with parentheses and can recognize precedence at first shot.

OK. But to put the parentheses in the right places you will have to learn the rules of precedence. And the Oberon notation for the logical operators is of help here once you realize that 'operator size matters'.


Title: Re: & and OR, why not AND and OR?
Post by: leledumbo on November 24, 2010, 07:43:54 AM
Ok, now I get it. We, most programmers, view Oberon's readability from different point of view that was used by Prof. Wirth. The professor has a strong physics (and therefore mathematics) background and consider that expressions in programs as mathematical expressions, while many programmers don't (and don't really care about it, for example, many prefers an incremental based O(n) solution rather than mathematical O(1) solution simply because finding an O(1) solution is much harder). The change of pointer declaration IMO does improve readability, though for me there's no ambiguity in Pascal syntax as well. Consider:
Code:
var
  p: ^Integer; // p is a pointer to an integer
begin
  ... p^ ... // what p is pointing to, that is, an integer
Maybe someday another Pascal grand{grand}child would appear with /\ as AND and \/ as OR since they reflect the mathematical logical operator for the corresponding operation ;D


Title: Re: & and OR, why not AND and OR?
Post by: cfbsoftware on November 24, 2010, 01:00:37 PM
Maybe someday another Pascal grand{grand}child would appear with /\ as AND and \/ as OR since they reflect the mathematical logical operator for the corresponding operation ;D

You are 50 years too late. Pascal's father, Algol 60 allowed expressions such as:

(http://www.cfbsoftware.com/images/algol60.gif)  ;)


Title: Re: & and OR, why not AND and OR?
Post by: Dsar on November 25, 2010, 03:11:50 AM
Agreed: programming code should read like a novel! But to read and enjoy this 'novel' you have to understand the language. And you understand the language better if it resembles a language you already know. Most programmers are familiar with the language (notation) of mathematics, at least the parts of math that are used frequently in programming languages. So if the programming notation resembles the already familiar mathematical notation it will be easier to learn, understand and enjoy. The resemblance will never be perfect because of the limitations of the characters set we have to use in coding our programs, but Wirth has given us 'the Best You Can Get'.

Ok, like leledumbo said, readability is a matter of taste. Anyway when I describe an algorithm I prefer to do it in a language like english (Pascal/Modula-2/Ada help a lot in this!), at the beginning I did an example: IF NOT found THEN, like in a binary search algorithm. There is no math involved here. It is true that an algorithm can be described in a mathematical way, I agree that with Haskell or another functional language, but not with Oberon.

Many people claim that Haskell is very readable, I agree with that for some small algorithms or small projects, it is also very elegant, but what about large scale software? With complex algorithms I begin to go mad. Just for curiosity I've tried to read an operating system written in Haskell, it is unreadable (at least for me). At this level this is not what I call "maintainable software" (by everyone).

Ok lets change the view. In a one-man project of course one can choose any language he likes, it doesn't matter if another person doesn't understand your coding style. If you are going to make a project where other people in the future can extend/improve/hack it, you have to do it in a way that "any level of mind" can read/understand, also stupid people (like me? maybe ;-)). This is my opinion. There are a lot of physics that understand Pascal without knowing Pascal, and there are a lot of them (an huge number!) that don't understand C. Accessibility is a requirement for my project. For this reason I will code in a language that permits to write english-like sentences.

Anyway, I'm coding a project in Oberon-2 without the NOT keyword (sob) in this way:

Code:
IF found THEN
  (* code *)
ELSE (* NOT found *)
  (* code for error messages *)
END;

This goes against my coding style because I manage errors at the beginning of a procedure, but it's ok if readability is not compromised.


Maybe someday another Pascal grand{grand}child would appear with /\ as AND and \/ as OR since they reflect the mathematical logical operator for the corresponding operation ;D

I know a lot of mathematicians that still make confusion between /\ and \/. If a person is used to them from primary school (like < and >) it is another story. But these symbols are only used when you enter university and only some textbooks adopt them in place of AND and OR.



Title: Re: & and OR, why not AND and OR?
Post by: cfbsoftware on November 25, 2010, 04:19:53 AM
Anyway, I'm coding a project in Oberon-2 without the NOT keyword (sob) in this way:

I can't bear to see a grown man cry ;) so if you are really that desperate you could always include this procedure at the beginning of your modules where you want to use NOT:

Code:
PROCEDURE NOT(b: BOOLEAN): BOOLEAN;
BEGIN
  RETURN ~b
END NOT;

... but please don't tell anybody that I suggested it  :-X


Title: Re: & and OR, why not AND and OR?
Post by: Dsar on November 25, 2010, 12:09:06 PM
Code:
PROCEDURE NOT(b: BOOLEAN): BOOLEAN;
BEGIN
  RETURN ~b
END NOT;

Ummh.. nice, but I have to do IMPORT MyNOT; everywhere :-( or I have to predeclare it in every modules.

My initial solution was to invert the logic, declaring the variable notFound, but I ended up with a lot of variables with a prefixed "not", it was so weird and I've abandoned this way.

I've all reasons of this world to cry ;-)



Title: Re: & and OR, why not AND and OR?
Post by: leledumbo on November 25, 2010, 12:50:49 PM
Quote
You are 50 years too late. Pascal's father, Algol 60 allowed expressions such as:
How do they type those operators? ???


Title: Re: & and OR, why not AND and OR?
Post by: Dsar on November 25, 2010, 01:05:27 PM
Quote
You are 50 years too late. Pascal's father, Algol 60 allowed expressions such as:
How do they type those operators? ???

Algol was designed for this layout: http://en.wikipedia.org/wiki/IBM_2741



Title: Re: & and OR, why not AND and OR?
Post by: leledumbo on November 26, 2010, 02:40:52 PM
Quote
Algol was designed for this layout: http://en.wikipedia.org/wiki/IBM_2741
What the...?! Thank God US Standard Keyboard doesn't have that layout...


Title: Re: & and OR, why not AND and OR?
Post by: Dsar on November 26, 2010, 05:00:25 PM
Quote
Algol was designed for this layout: http://en.wikipedia.org/wiki/IBM_2741
What the...?! Thank God US Standard Keyboard doesn't have that layout...

This is the perfect keyboard layout for a perfect world where math is used everywhere (since primary school).
Anyway, reality is another story.

What I really miss in the Latin-1 character set is ≠ that is the best (of course) compared to any alternatives like !=,  <>,  /=  and  #.



Title: Re: & and OR, why not AND and OR?
Post by: Wlad on July 07, 2011, 11:09:02 AM
   TYPE
      Buffer = ARRAY OF CHAR;
      BufPtr = POINTER TO Buffer;
   VAR
      BP: BufPtr;
   (...)
      BP^  (* 'by BP referenced' or simply 'BP-referenced' *)

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' *)


Title: Re: & and OR, why not AND and OR?
Post by: Dsar 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 :-)


Title: Re: & and OR, why not AND and OR?
Post by: Wlad 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 ????

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."
;)