home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #19 / NN_1992_19.iso / spool / comp / sys / mac / programm / 14692 < prev    next >
Encoding:
Internet Message Format  |  1992-08-29  |  3.6 KB

  1. Path: sparky!uunet!haven.umd.edu!darwin.sura.net!zaphod.mps.ohio-state.edu!uwm.edu!ogicse!das-news.harvard.edu!cantaloupe.srv.cs.cmu.edu!crabapple.srv.cs.cmu.edu!andrew.cmu.edu!sr0o+
  2. From: sr0o+@andrew.cmu.edu (Steven Ritter)
  3. Newsgroups: comp.sys.mac.programmer
  4. Subject: Re: incrementation differences/THINK C 4.0 vs. 5.0
  5. Message-ID: <webbHVm00WBM842pMu@andrew.cmu.edu>
  6. Date: 28 Aug 92 10:48:01 GMT
  7. Article-I.D.: andrew.webbHVm00WBM842pMu
  8. References: <1992Aug27.182157.16567@qualcomm.com> <38188@unix.SRI.COM> <1992Aug28.130710.18938@qualcomm.com>
  9.     <1992Aug28.143614.22079@phri.nyu.edu>
  10. Organization: Doctoral student, Psychology, Carnegie Mellon, Pittsburgh, PA
  11. Lines: 67
  12. In-Reply-To: <1992Aug28.143614.22079@phri.nyu.edu>
  13.  
  14. roy@alanine.phri.nyu.edu (Roy Smith) writes:
  15.  
  16. >sdorner@qualcom.qualcomm.com (Steve Dorner) writes:
  17. >>It does *not* know where the missing ";" should go.  It knows where
  18. >>something is missing.  An '=' would be a perfectly good choice, too.
  19. >    I've been thinking about this for a day or so.  In the fragment
  20. >"a=b=c d=e;" the blank could be replaced with just about anything and make
  21. >a syntactically correct statement:
  22. >    Any alphanumeric would turn "c d" into a variable name.
  23. >    Any binary arithmentic operator (+, -, *, /)would be fine.
  24. >    Any relational operator (==, !=, <, >, <=, >=) would be fine.
  25. >    Any boolean operator (||, &&) would be fine.
  26. >    Any binary logical operator (&, |, etc) would be fine.
  27. >    Any assignment operator (=, =+, =-, =*, =/) would be fine.
  28. >
  29. >    Deleting the space completely would give you the variable "cd".
  30. >    A comma would be fine, giving you two sequential assignments.
  31. >    All things considered, the a-priori probability that you need to
  32. >replace the space by a semicolon is pretty slim.
  33.  
  34. This is an AI problem, and not a very difficult one. In principle, the
  35. compiler can know as much as you know. Suppose you were modifying
  36. someone else's code and came across the line:
  37. a=b=c d=e;
  38. What would you do?
  39.  
  40. Most of the above suggestions are illegal. You can't add a binary
  41. arithmetic operator (you'd get c+d=e). Same with a boolean, relational
  42. or logical operator or any of the arithmatic assignment operators (=+,
  43. etc.).
  44.  
  45. You could add an alpha character (or delete the space) to turn
  46. it into a variable name. Unless there is a variable in scope (and of the
  47. right type) of the form c*d, this is highly unlikely to be the right answer.
  48.  
  49. Your remaining choices are semi-colon, comma and =. In this case,
  50. semi-colon and comma are semantically identical, so that's not much of a
  51. problem. Deciding between = and the others is slightly tricky. You can
  52. resolve this, in part, by seeing which variables have been initialized.
  53. If only one of the five variables has been initialized, the answer is
  54. almost certainly = (otherwise, you'd be assigning something to an
  55. uninitialized variable). Similarly, if both c and e (for example) have
  56. just been initialized, you're almost certainly missing a semi-colon.
  57.  
  58. The "if (a=b) case is much trickier, but I think we could do a pretty
  59. good job on this as well. There are some idioms [like if
  60. (fp=fopen(...))] that are clearly intended. For something like "if
  61. (a=b)" I'd check whether 'a' was unassigned before the 'if' and is used
  62. only in the body of that conditional (at least, up to a later
  63. assignment). If so, the assignment is probably intended.
  64.  
  65. The point of all this is that, in the vase majority of cases, a compiler
  66. with a little intelligence could guess right most of the time. Whether
  67. the occasional errors would be worth it (after all, it's just finding
  68. typos) is a separate question. Natural language grammar checkers guess
  69. right most of the time as well but I find them more annoying than useful.
  70.  
  71. Steve
  72.