home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #20 / NN_1992_20.iso / spool / comp / compiler / 1529 < prev    next >
Encoding:
Internet Message Format  |  1992-09-08  |  4.2 KB
  1. Xref: sparky comp.compilers:1529 comp.human-factors:2122
  2. Path: sparky!uunet!cis.ohio-state.edu!rutgers!faatcrl!iecc!compilers-sender
  3. From: kotula@milli.cs.umn.edu (Jeff Kotula)
  4. Newsgroups: comp.compilers,comp.human-factors
  5. Subject: language design tradeoffs
  6. Keywords: design, question, comment
  7. Message-ID: <92-09-048@comp.compilers>
  8. Date: 7 Sep 92 15:43:09 GMT
  9. Sender: compilers-sender@iecc.cambridge.ma.us
  10. Reply-To: kotula@milli.cs.umn.edu (Jeff Kotula)
  11. Organization: University of Minnesota
  12. Lines: 83
  13. Approved: compilers@iecc.cambridge.ma.us
  14.  
  15. Hi.  I work with a very large MCAD package and am in the process of
  16. revamping the interface.  One of the sub-projects involved is to update
  17. and expand the command language interface.
  18.  
  19. The way the product works is that every graphic interface action boils
  20. down to a single command in the language.  In addition, the user is given
  21. a command line to type in frequently used (and therefore, remembered)
  22. commands.
  23.  
  24. A very powerful side-effect of this system is that by recording the
  25. sequence of commands entered (either via the graphic parts of the
  26. interface or the command line) users can construct what we call command
  27. files, or scripts.  (It is also a useful feature for bug reporting and
  28. debugging.)
  29.  
  30. Now on to the problem I'm facing and that I humbly request assistance
  31. with...
  32.  
  33. The current command language is rather unstructured.  It contains all the
  34. necessary constructs (sequence, selection, iteration) and a handful of
  35. built-in data types.  On of the most out-dated limitations it has though
  36. is that the end-of-line is used as the command separator (or
  37. end-of-command indicator).  The EOL also indicates that any quoted string
  38. be closed off.  To handle nesting of commands as arguments, the command
  39. must be enclosed in [].
  40.  
  41. Following are a few examples of currently legal commands :
  42.  
  43.     zoomwindow 1.24
  44.     activelayer "layerfoo
  45.     writefile [readfile "from"], "to
  46.  
  47. Like I said, the language is a bit outdated.  What I'd like to do is
  48. modernize it and expand it.  Unfortunately, the ability to type in
  49. commands at the command line must still be supported.  Also, since command
  50. line typeins are done during an interactive session, the speed with which
  51. users can enter these commands is important.  (Note that the user
  52. community ranges from those who don't know how to make capital letters to
  53. very advanced power users.)
  54.  
  55. To make the language more flexible, I'd like to incorporate the good-old
  56. ';' as the command separator; however, mandating that this be included in
  57. the command line is somewhat redundant, since the command line only allows
  58. a single line (and that is the canonical use).  On the other hand, users
  59. would like to be able to have multiple commands per command line :
  60.  
  61.     zoomwindow 1.24; panwindow 3.4; panwindow -1.2
  62.  
  63. Note that the ; serves fine as a separator here, but keep in mind that
  64. these commands will be used in constructing scripts, so they cannot be
  65. looked at in quite so isolated an environment.  I have thought of taking
  66. each command line and doctoring it (adding ; and string quotes, etc.) to
  67. make it a legal statement in the language, but I'd prefer it if users
  68. didn't have two see two different types of syntax.  (Perhaps this could be
  69. a user-settable option for power users?  But is requiring the full syntax
  70. for novices practical?  Does it make more sense to only require it of
  71. those who want to write the command language scripts?)
  72.  
  73. Well, that should give you the flavor (rather rancid I think) of the types
  74. of requirements I'm working with.  It seems there are two essentially
  75. different problems; the interface command line needs to be quick but the
  76. command language needs to be coherent, simple, and powerful.
  77.  
  78. Has anyone had similar situations or references to related work?
  79.  
  80. Also, are there any empirical results that might indicate how much longer
  81. it takes to type
  82.     zoomwindow(1.24);
  83. than
  84.     zoomwindow 1.24
  85. ?
  86.  
  87. Also, how can you write a LR or LALR grammar to parse a language where
  88. EOL's are significant?
  89.  
  90. --
  91. jeff
  92. kotula@cs.umn.edu
  93. [Parsing a language where line endings matter is no big deal -- you make the
  94. end-of-line character one of the tokens. -John]
  95. -- 
  96. Send compilers articles to compilers@iecc.cambridge.ma.us or
  97. {ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.
  98.