language design tradeoffs

Hi. I work with a very large MCAD package and am in the process of
revamping the interface. One of the sub-projects involved is to update
and expand the command language interface.


The way the product works is that every graphic interface action boils
down to a single command in the language. In addition, the user is given
a command line to type in frequently used (and therefore, remembered)
commands.


A very powerful side-effect of this system is that by recording the
sequence of commands entered (either via the graphic parts of the
interface or the command line) users can construct what we call command
files, or scripts. (It is also a useful feature for bug reporting and
debugging.)


Now on to the problem I'm facing and that I humbly request assistance
with...


The current command language is rather unstructured. It contains all the
necessary constructs (sequence, selection, iteration) and a handful of
built-in data types. On of the most out-dated limitations it has though
is that the end-of-line is used as the command separator (or
end-of-command indicator). The EOL also indicates that any quoted string
be closed off. To handle nesting of commands as arguments, the command
must be enclosed in [].


Following are a few examples of currently legal commands :


        zoomwindow 1.24
        activelayer "layerfoo
        writefile [readfile "from"], "to


Like I said, the language is a bit outdated. What I'd like to do is
modernize it and expand it. Unfortunately, the ability to type in
commands at the command line must still be supported. Also, since command
line typeins are done during an interactive session, the speed with which
users can enter these commands is important. (Note that the user
community ranges from those who don't know how to make capital letters to
very advanced power users.)


To make the language more flexible, I'd like to incorporate the good-old
';' as the command separator; however, mandating that this be included in
the command line is somewhat redundant, since the command line only allows
a single line (and that is the canonical use). On the other hand, users
would like to be able to have multiple commands per command line :


        zoomwindow 1.24; panwindow 3.4; panwindow -1.2


Note that the ; serves fine as a separator here, but keep in mind that
these commands will be used in constructing scripts, so they cannot be
looked at in quite so isolated an environment. I have thought of taking
each command line and doctoring it (adding ; and string quotes, etc.) to
make it a legal statement in the language, but I'd prefer it if users
didn't have two see two different types of syntax. (Perhaps this could be
a user-settable option for power users? But is requiring the full syntax
for novices practical? Does it make more sense to only require it of
those who want to write the command language scripts?)


Well, that should give you the flavor (rather rancid I think) of the types
of requirements I'm working with. It seems there are two essentially
different problems; the interface command line needs to be quick but the
command language needs to be coherent, simple, and powerful.


Has anyone had similar situations or references to related work?


Also, are there any empirical results that might indicate how much longer
it takes to type
        zoomwindow(1.24);
than
        zoomwindow 1.24
?


Also, how can you write a LR or LALR grammar to parse a language where
EOL's are significant?


--
jeff
kotula@cs.umn.edu
[Parsing a language where line endings matter is no big deal -- you make the
end-of-line character one of the tokens. -John]
--

Return to the comp.compilers page.
Search the comp.compilers archives again.