Re: Dylan

[zilla@ccrl.nj.nec.com (John Lewis)]

You're obviously not familiar with scheme.  The surface syntax of Dylan
is much closer to scheme than to lisp.  Names deviate from scheme
in a couple places, and these deviations do seem to be consistent
with the stated goal of making Dylan attractive to programmers outside
of the lisp community.

Given that it was decided to make Dylan a new language, it does make
sense to change some lisp names which are historically rather than
logically derived.  Mapping our knowledge of lisp onto these names
will be much easier than telling a pascal programmer why he needs to
type #'(.

I agree with the comments about the language spec not being enough to
address the goal of making this language suitable for commercial products.

In fact i believe that the foreign function interface is vital and 
*should* be included in the language spec: the requirements of the 
ff interface would then influence the implementation.  Many ff facilities
are inefficient or crippled because the lisp internal data structures
were designed for efficient lisp compilation, not for efficient ff 
access.  On a machine such as the Mac, i would think that the cost
of converting internal representations on each toolbox call might
be enough to weigh in favor of creating more C/pascal compatible
internal representations (of integers, for example), though I am
not speaking from experience.

j.p.lewis/nec research