home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #20 / NN_1992_20.iso / spool / comp / lang / cplus / 13609 < prev    next >
Encoding:
Internet Message Format  |  1992-09-14  |  3.0 KB
  1. Path: sparky!uunet!pmafire!news.dell.com!swrinde!gatech!concert!sas!mozart.unx.sas.com!sasghm
  2. From: sasghm@theseus.unx.sas.com (Gary Merrill)
  3. Newsgroups: comp.lang.c++
  4. Subject: Re: C++ Grammar
  5. Message-ID: <BuKq65.Cx7@unx.sas.com>
  6. Date: 14 Sep 92 15:10:52 GMT
  7. References: <Bu07v4.F66@csfb1.fir.fbc.com> <1992Sep6.232016.6573@cssc-syd.tansu.com.au> <BuD9Lx.JoD@unx.sas.com> <1992Sep12.021515.23609@cs.brown.edu>
  8. Sender: news@unx.sas.com (Noter of Newsworthy Events)
  9. Organization: SAS Institute Inc.
  10. Lines: 48
  11. Originator: sasghm@theseus.unx.sas.com
  12. Nntp-Posting-Host: theseus.unx.sas.com
  13.  
  14.  
  15. In article <1992Sep12.021515.23609@cs.brown.edu>, ted@cs.brown.edu (Tony Davis) writes:
  16. |> 
  17. |> Another common approach to parsing C++ with yacc is to make
  18. |> the lexicl analyzer more powerful.  With this approach yacc
  19. |> can indeed be used to parse non-LR(k) languages.  Granted,
  20. |> this might be called cheating since the lexical analyzer is
  21. |> doing enough parsing so that the language that the yacc portion
  22. |> of the system must parse IS now LR(k).  Strictly speaking
  23. |> yacc does not parse a non-LR(k) language, but the parser as
  24. |> a whole does.
  25.  
  26. This is either inaccurate or misleading (touche!).  The lexical
  27. analyzer of course doesn't do the parsing.  It does the lexical
  28. analysis -- which in this case means, among other things, the
  29. determination/insertion of artificial tokens.  It may call a
  30. parser in order to make this determination.
  31.  
  32. |> A C++ parser that one of my advisors has recently produced takes
  33. |> this approach.  The lexer does look ahead to produce artificial
  34. |> tokens which yacc uses as ques to yield a correct parse (modulo
  35. |> any bugs that remain in the system).  Soon I will be making that
  36. |> parser available for ftp.  When it becomes available I will
  37. |> announce it here.
  38.  
  39. I'm sure we all use basically the same technique here (whether
  40. the underlying parser is yacc-based or recursive descent).  I do,
  41. nonethless, look forward to seeing how someone else has done this.
  42. Note, however, that in any case -- if the parsing is ultimately
  43. done correctly -- then either yyparse() must be called recursively
  44. as part of the lookahead process or some other method (recursive
  45. descent, for example) must be used in the "local" or "trial" parses
  46. necessary to determine what (if any) artificial token to insert.
  47. My changes to yacc include the recursive callability of yyparse(),
  48. a distinction between conditional and unconditional actions, a
  49. simple type of reduction tracking, and optimized dynamically allocated
  50. parser stacks.  These are all relatively simple modifications to
  51. the code.  Actually, quite a bit of work needs to go into the
  52. buffering of tokens and into error detection/recovery and diagnostics.
  53.  
  54. Again, after going through this, I would advise anyone starting
  55. from scratch to use a recursive descent parser since I feel that
  56. it offers advantages in the areas of diagnostics, recovery, and
  57. maintainability.
  58. -- 
  59. Gary H. Merrill  [Principal Systems Developer, C Compiler Development]
  60. SAS Institute Inc. / SAS Campus Dr. / Cary, NC  27513 / (919) 677-8000
  61. sasghm@theseus.unx.sas.com ... !mcnc!sas!sasghm
  62.