[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Newton and Dylan
- To: Steve Ford <email@example.com>, firstname.lastname@example.org
- Subject: Re: Newton and Dylan
- From: Jeff Dalton <email@example.com>
- Date: Fri, 4 Dec 92 11:51:36 GMT
- In-reply-to: Steve Ford's message of Thu, 3 Dec 92 13:36:02 CST
> PC Week August 17 1992
> Its main advantage over LISP is that it is a language, not an environment,
> and can work easily in standard operating environments (or in Newton's)."
0. Dylan is a dialect of Lisp.
1. There are a number of Lisps that are languages, not environments.
Moreover, the move towards being a language (not an enviroment) is
a general trend within Lisp. For example: EuLisp, Scheme (to a
large extent), ISLisp (the ISO dialect).
2. Lisp's problems working in standard environments are for the most
part not due to the environmental aspects of Lisp. Instead, they're
due to storage management and data representation issues.
3. It seems reasonable to say InterLisp is an environment, but how
about Common Lisp? To a large extent, it depends on how it's
implemented. Common Lisp can be packaged as a shared library
(see WCL), and (given a suitable linker) could be linked with C
procedures rather than being an environment into which C procedures
4. Of course, there are environmental aspects to Common Lisp such as
TRACE, COMPILE, LOAD, DESCRIBE, and (some would say) SYMBOL-FUNCTION.
Some of them (TRACE, DESCRIBE) could be defined in a language-only
Lisp (assuming we allow an I/O library). Others (COMPILE-FILE,
LOAD) are there to make it possible to define systems tools in
Lisp in an operating system independent way. I find it hard to
see this as a bad thing, although it's not the only good way to
do a Lisp.