[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
- To: RAM@C.CS.CMU.EDU
- Subject: Which package...
- From: Jonathan A Rees <JAR@MC.LCS.MIT.EDU>
- Date: Wed, 12 Mar 86 17:08:03 EST
- Cc: common-lisp@SU-AI.ARPA
- In-reply-to: Msg of Tue 11 Mar 1986 18:42 EST from Rob MacLachlan <RAM at C.CS.CMU.EDU>
Date: Tue, 11 Mar 1986 18:42 EST
From: Rob MacLachlan <RAM at C.CS.CMU.EDU>
The Spice Lisp debugger has various commands and functions
associated with it which are packaged symbols. When I implement a
portable system, I am going to set up the package environment so that
I can use the debugger. If I can't say this in a portable way, then I
will have to edit the sources before every release or maintain a site
dependent file which does the package setup. When another site uses
the system, it is likely that they will edit it again so that they can
use their debugger. This is a totally gratuitous system dependency.
A design technique I particularly like for getting around
context-sensitivity of this sort is to make the user interface commands
(debug, trace, edit, logout, etc.) accessible through a mechanism other
than the traditional READ + EVAL interface. In liberating a user
interface from READ, it can be made useful even when the current package
doesn't use LISP or USER (a situation I often work with). By the same
token (so to speak), a separate command namespace makes short command
names possible without risk of conflict with user variables - e.g. E for
edit, Q for quit, etc.
An example of this kind of interface (which I admit has myriad problems,
but none which couldn't be fixed) is Symbolics' "command processor,"
which I usually use in the mode where user input is normally parsed as
s-expression, but user input which begins with a colon is parsed as a
carriage-return-terminated "command" of some sort. (Note that colon is
NOT a read macro.)
I don't want to argue the benefits of this paricular interface -
zillions of other syles are possible - I just want to argue against the
importance of the READ-EVAL status quo. It seems inappropriate to argue
against an important language feature for promoting robustness and
portability, like a predictable LISP (or defaultly-used) package, on the
grounds that it makes a certain kludgy kind of user interface, which
doesn't work all that well anyhow, not work.