home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #27 / NN_1992_27.iso / spool / comp / lang / fortran / 4370 < prev    next >
Encoding:
Text File  |  1992-11-19  |  1.9 KB  |  44 lines

  1. Newsgroups: comp.lang.fortran
  2. Path: sparky!uunet!zaphod.mps.ohio-state.edu!saimiri.primate.wisc.edu!caen!hellgate.utah.edu!lanl!cochiti.lanl.gov!jlg
  3. From: jlg@cochiti.lanl.gov (J. Giles)
  4. Subject: Re: Logical operators and operands
  5. Message-ID: <1992Nov19.200731.13443@newshost.lanl.gov>
  6. Sender: news@newshost.lanl.gov
  7. Organization: Los Alamos National Laboratory
  8. References: <BxwrJC.GME@cs.uiuc.edu> <30476@nntp_server.ems.cdc.com> <30502@nntp_server.ems.cdc.com>
  9. Date: Thu, 19 Nov 1992 20:07:31 GMT
  10. Lines: 32
  11.  
  12. In article <30502@nntp_server.ems.cdc.com>, mstemper@ems.cdc.com (Michael Stemper) writes:
  13. |> [...]
  14. |> This seems dumb! Why shouldn't the operators for equality and
  15. |> inequality be the same, no matter what type of operands are
  16. |> used? It seems to me that this is poor language design. Can
  17. |> somebody come up with a plausible excuse for this? Is it:
  18. |>  a) Tradition
  19. |>  b) History
  20. |>  c) Easier to optimize compilers
  21. |>  d) Grandfathered in
  22.  
  23. I agree that it's dumb.  I think I can say *why* it was done.  There
  24. are a number of relations defined in the predecate calculus like
  25. equivalence, implication, AND, OR, NOT, etc..  These have inherently 
  26. lower precedence than the relational operations on numeric types so
  27. that such relational expressions can be used as operands to the 
  28. predecate calculus operations.  However, this is a fairly weak
  29. connection since LOGICAL expressions are not predecate calculus:
  30. they don't define relationships between assertions but merely 
  31. values.  For example, if I say that assertion A is equivalent
  32. to assertion B, that means that they *always* have identical 
  33. meaning.  Whereas, the Fortran .EQV. operator can only tell
  34. you whether the expressions corresponding to the two assertions
  35. presently evaluate to the same truth-value.  That's quite a
  36. difference.
  37.  
  38. In any case, as long as we've got .EQV. and .NEQV. in the
  39. language, why not add .IMPLIES. as well?  I need it rather
  40. more often than the others.
  41.  
  42. -- 
  43. J. Giles
  44.