Oberon Community Platform Forum
November 19, 2019, 07:35:29 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 27302 times)
leledumbo
Jr. Member
**
Posts: 96



WWW
« 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).
Logged
soren renner
Global Moderator
Full Member
*****
Posts: 216



« Reply #1 on: November 02, 2010, 06:50:04 PM »

So "and/or" should really be "andslashor"?
Logged
cfbsoftware
Full Member
***
Posts: 107


WWW
« Reply #2 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 / ~        ~
<>             <> / #        #




Logged

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



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


WWW
« Reply #4 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.
Logged

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



WWW
« Reply #5 on: November 04, 2010, 09:32:53 AM »

"|"
it's used for CASE operator Wink
Logged
leledumbo
Jr. Member
**
Posts: 96



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


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

« Last Edit: November 20, 2010, 01:47:39 AM by Dsar » Logged
leledumbo
Jr. Member
**
Posts: 96



WWW
« Reply #8 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 Wink
Logged
soren renner
Global Moderator
Full Member
*****
Posts: 216



« Reply #9 on: November 21, 2010, 06:41:21 PM »

Agree.

NOT!
Logged
cfbsoftware
Full Member
***
Posts: 107


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

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 #11 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.)
« Last Edit: November 22, 2010, 03:05:15 PM by Dsar » Logged
leledumbo
Jr. Member
**
Posts: 96



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


WWW
« Reply #13 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.
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 #14 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.

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!