Oberon Community Platform Forum
October 16, 2019, 03:17:15 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
  Print  
Author Topic: & and OR, why not AND and OR?  (Read 26708 times)
hansklav
Newbie
*
Posts: 3


« Reply #15 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 ∧ ¬ 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 ≠ (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...
Logged

Hans Klaver
cfbsoftware
Full Member
***
Posts: 107


WWW
« Reply #16 on: November 23, 2010, 04:25:08 AM »

Ok, what about POINTER TO?

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

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


« Reply #17 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' *)


Logged

Hans Klaver
Dsar
Newbie
*
Posts: 40


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

Logged
hansklav
Newbie
*
Posts: 3


« Reply #19 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'.
Logged

Hans Klaver
leledumbo
Jr. Member
**
Posts: 96



WWW
« Reply #20 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 Grin
Logged
cfbsoftware
Full Member
***
Posts: 107


WWW
« Reply #21 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 Grin

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

 Wink
« Last Edit: November 24, 2010, 01:05:31 PM by cfbsoftware » Logged

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


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

Logged
cfbsoftware
Full Member
***
Posts: 107


WWW
« Reply #23 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 Wink 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  Lips sealed
Logged

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


« Reply #24 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 ;-)

Logged
leledumbo
Jr. Member
**
Posts: 96



WWW
« Reply #25 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? Huh
Logged
Dsar
Newbie
*
Posts: 40


« Reply #26 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? Huh

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

Logged
leledumbo
Jr. Member
**
Posts: 96



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


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

Logged
Wlad
Newbie
*
Posts: 14


« Reply #29 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' *)
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!