home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #20 / NN_1992_20.iso / spool / comp / compiler / 1557 < prev    next >
Encoding:
Internet Message Format  |  1992-09-15  |  1.9 KB
  1. Xref: sparky comp.compilers:1557 comp.human-factors:2217
  2. Path: sparky!uunet!zaphod.mps.ohio-state.edu!cis.ohio-state.edu!rutgers!faatcrl!iecc!compilers-sender
  3. From: tmb@arolla.idiap.ch (Thomas M. Breuel)
  4. Newsgroups: comp.compilers,comp.human-factors
  5. Subject: Re: language design tradeoffs
  6. Keywords: C, macros, design
  7. Message-ID: <92-09-075@comp.compilers>
  8. Date: 14 Sep 92 19:45:12 GMT
  9. References: <92-09-048@comp.compilers> <92-09-066@comp.compilers>
  10. Sender: compilers-sender@iecc.cambridge.ma.us
  11. Reply-To: tmb@arolla.idiap.ch (Thomas M. Breuel)
  12. Followup-To: comp.compilers
  13. Organization: IDIAP (Institut Dalle Molle d'Intelligence Artificielle Perceptive)
  14. Lines: 24
  15. Approved: compilers@iecc.cambridge.ma.us
  16.  
  17. raveling@Unify.com (Paul Raveling) writes:
  18.  
  19.    Actually I like the idea of using EOL rather than ;.  It eliminates a
  20.    cause of several common errors in compilation that need not happen, and it
  21.    need not have particularly adverse side effects.
  22.  
  23.    Here's one example of a human factors trap in C that wouldn't be there
  24.    without ';'.  The key is C's syntax definition for <statement> -- either
  25.    one simple statement terminated by ';' or a sequence of simple statements
  26.    surrounded by {}'s. [... macro example deleted ...]
  27.  
  28. This is a misfeature of C that comes about because of a conspiracy between
  29. poorly chosen "if" syntax and poorly chosen macro semantics.  It is not
  30. very much related to how you terminate your statements (in fact, I could
  31. imagine similar problems if you chose EOL as your statement terminator).
  32.  
  33. In my experience, explicitly terminating statements with something like
  34. ";", or even better, explicitly bracketing each statement (as in Lisp), is
  35. the most effective syntax for protecting you from typos and slips.
  36.  
  37.                     Thomas.
  38. -- 
  39. Send compilers articles to compilers@iecc.cambridge.ma.us or
  40. {ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.
  41.