home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #16 / NN_1992_16.iso / spool / comp / compiler / 1267 < prev    next >
Encoding:
Text File  |  1992-07-29  |  2.9 KB  |  71 lines
  1. Newsgroups: comp.compilers
  2. Path: sparky!uunet!gatech!destroyer!sol.ctr.columbia.edu!eff!world!iecc!compilers-sender
  3. From: Elliot H. Mednick <elliot@wellspring.com>
  4. Subject:   Interactive stamtment execution
  5. Reply-To: Elliot H. Mednick <elliot@wellspring.com>
  6. Organization: Wellspring Solutions
  7. Date: Wed, 29 Jul 1992 17:32:49 GMT
  8. Approved: compilers@iecc.cambridge.ma.us
  9. Message-ID: <92-07-088@comp.compilers>
  10. Keywords: yacc, interpreter, question
  11. Sender: compilers-sender@iecc.cambridge.ma.us
  12. Lines: 57
  13.  
  14. I am writing an interpreter that uses YACC to parse the language.  I want
  15. the interpreter to also be able to execute statements interactively.  I
  16. would like to use the same YACC description file to parse both the program
  17. and the interactive statements, which are identical to the procederal
  18. statements.  However, there are some difficulties.
  19.  
  20. The language that is to be parsed includes header and declarative
  21. information that YACC needs to know about, as well as the procedural
  22. statements.  In "interactive mode", entering declarations would be
  23. illegal; only the statements would be allowed.  At the top level, a common
  24. YACC description might look something like this:
  25.  
  26. S
  27.  : program
  28.  | statement
  29.  ;
  30.  
  31. program
  32.  : header declaration statment_list
  33.  ;
  34. ...
  35.  
  36. However, I want YACC to distinguish between parsing a program file and
  37. parsing interactively: i.e. flag syntax errors if a program does not have
  38. declaration and header info and if declaration info is typed
  39. interactively.
  40.  
  41. The obvious alternative is to use two YACC descriptions.  The big problem
  42. with two descriptions is that the vast majority of the description would
  43. be common between the two files, since the same statements are used and
  44. they would have the same actions.  I am considering using BISON since the
  45. sources are avalable, and modifying it to support file inclusion; except
  46. that the interpreter would be sold commercially.
  47.  
  48. Are there techniques for using the SAME YACC file for parsing different
  49. aspects of a langauge, while excluding undesired aspects?  If not, is
  50. there a way to use a common description for two YACC files?  And if not
  51. for that, any suggestions on a small source control mechanism for ensuring
  52. both files are up to date w.r.t each other?
  53.  
  54. Thanks in advance.
  55. -Elliot
  56. -- 
  57. Elliot H. Mednick                                        P.O. Box 150
  58. Wellspring Solutions                                     Sutton, MA. 01590
  59. elliot@Wellspring.com                                    +1 508 865 7271
  60. [The easiest technique is to use a fake initial token to distinguish the
  61. two cases, e.g.:
  62.  
  63. toplevel: FAKE1 single-statement | FAKE2 statement-list ;
  64.  
  65. and have the lexer return the appropriate initial fake statement.  A harder
  66. problem is to have the lexer return an end marker at the end of a single
  67. statement when the syntax doesn't make that obvious. -John]
  68. -- 
  69. Send compilers articles to compilers@iecc.cambridge.ma.us or
  70. {ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.
  71.