Dylan

["pierce" <pierce@at-mail-server.vitro.com>]

I have read through the Dylan specification and I strongly agree with its
goals. The language looks very much like a subset of CLtL2 that retains many of
the best features of Common Lisp while keeping memory requirements at a
minimum.

Please consider the following recommendations as ways of improving the Dylan
language, rather then criticisms.

********************************************************I S S U E  1 : 
********************************************************

Dylan deviates from Common Lisp terminology, syntax, and functionality with no
apparent effeciency benefit.

I think Dylan should be defined as a proper subset of Common Lisp with some
extensions. With that in mind, I'd like to see the Dylan spec adhere to the
following guidelines:

Everything in Dylan is an object, and all functions are methods. This is good,
I see no problem with making Dylan <Methods> with the same name as Common Lisp
<Functions> and Dylan <Classes> from Common Lisp <Built-In-Classes>.

Common Lisp terminolgy should be used whenever a Dylan method provides
functionality that already exists in Common Lisp.

For example:

Dylan <Id?> resembles Common Lisp <Eq>
Dylan <=> resembles Common Lisp <Equal>
Dylan <Table> resembles Common Lisp <Hash-table>
Dylan <Module> resembles Common Lisp <Package>
Dylan <Define> resembles Common Lisp <Setq>
Dylan <Make> resembles Common Lisp <Make-Instance>
etc.

Common Lisp syntax should be used whenever a Dylan method provides
functionality that already exists in Common Lisp and there is no obvious
benefit to a new syntax.

For example:

Dylan <Define-Class> resembles Common Lisp <Defclass>

Dylan methods should not reduce the functionality of their corresponding Common
Lisp functions unless their is no efficient way to implement the functionality
described by Common Lisp.

For example:

Dylan <set!> seems to be a version of Common Lisp <Setf> that takes only two
arguments rather than an alternating sequence of <Place> and <Value> forms.

********************************************************
 I S S U E  2 :
>> "The overriding goal of Dylan is rapid development and delivery of
>>applications and application components on very small computers." 

Dylan by itself is not sufficient for achieving this goal.
********************************************************
There are three main reasons why Lisp is not used very often for delivering
commercial applications.  These include excessive memory requirements, runtime
speed efficiency, and the ability to integrate with pre-existing code developed
in other languages.

Since Dylan is smaller than Common Lisp, it addresses the memory requirement
issue for small machines where memory is limited by factoring out much of the
bundled functionality of Common Lisp into loadable libraries.  Developers can
customize the size of their Dylan environment by choosing not to load libraries
that aren't needed.

Runtime speed efficiency is still an issue that needs to be addressed.  Dylan
claims to improve speed efficiency by removing from the language those
constructs which they do not know how to implement efficiently.  Runtime
dispatching is still slower than the object systems provided by static
languages, especially on very small machines which may have relatively slow
hardware.

The third limitation which dynamic languages such as Dylan need to address for
delivery is the ability to integrate pre-existing code developed in other
languages.  This is especially important so that Dylan applications can take
full advantage of optimized user interface code.

Rather than have Dylan developers develop interface classes from scratch, Dylan
developers could build Dylan classes by calling externally defined functions
from existing user interface management systems.  

>>"Dylan is a simple and expressive language, one that is efficient but >>
which protects the programmer from crashes and machine level >>debugging."

Developers of Dylan user interface classes who take advantage of user interface
code written in other languages will not be protected from crashes since they
will be using externally defined code.
I realize that the discussion of a foreign function interface is an issue for
Dylan implementations to deal with rather than a programming language issue. 
The issue should not be neglected by the Dylan designers however, since
successful user interfaces are essential to successful application delivery.  

Perhaps a Dylan implementation could be developed that is shipped in an MPW
linkable form.  This would allow Dylan developers to customize their Dylan
implementation to take advantage of the foreign code of their choice. 

In particular, I'd like to see a Dylan based MACAPP implementation.  This might
be accomplished by defining Dylan classes that correspond to MACAPP classes. 
Dylan instances and MACAPP instances could coexist using indirection to refer
to each other.

A portable Dylan implementation could easily be coded entirely in Common Lisp. 
Unless a Common Lisp implementation is made available which addresses the
issues outlined above,  a Dylan implementation would have to address them and
be coded from scratch.

I look forward to your feedback.

-Jonathan