January 93 - Dylan(tm) FAQ
Dylan(tm) FAQ
This memo answers questions which are frequently asked about the Dylan
programming language. The latest version of this memo is available by anonymous ftp
from cambridge.apple.com in the file /pub/dylan/dylan-faq.txt. We expect to make
other Dylan documents available for ftp from the same directory.
The Dylan manual is not available in electronic form, but a bound copy may be
requested by sending your name and address to
dylan-manual-request@cambridge.apple.com. (Applelink users should send to
dylan-request@ cambridge.apple.com@internet#.). As of this writing, there is no
charge for the manual.
If you want to keep up with Dylan news, consider joining the info-dylan mailing list,
described below.
General Questions About Dylan
What is Dylan?
Dylan is a new Object Oriented Dynamic Language (OODL), developed by the Eastern
Research and Technology Lab of Apple Computer. Dylan was designed to make the
advantages of OODLs available for commercial programming on a variety of computing
devices. Dylan most closely resembles CLOS and Scheme. Other languages which
influenced the design of Dylan include Smalltalk, Self, and OakLisp.
Dylan is consistently object-oriented. It is not a procedural language with an
object-oriented extension. To this end, Dylan does not attempt to be compatible with
any previously existing programming language.
What is the target audience for Dylan?
The target audience for Dylan is software application programmers, most of whom are
currently using static languages such as C and C++. We realize that the current
manual is more appropriate for people already familiar with OODLs. We have plans for
additional documents directed at static language programmers.
How does Dylan differ from previous OODLs?
Dylan is designed to allow the powerful and flexible programming techniques and
development environments associated with OODLs, while also allowing the small, fast
delivered applications currently associated with static languages.
Unlike many dynamic languages, Dylan's design consciously enables the runtime
environment to execute without the development environment present. In addition,
Dylan will let you selectively 'turn-off' dynamic capabilities when they are no longer
needed, allowing more efficient compilation.
Are there any public mailing lists for discussing Dylan?
Yes. There are four mailing lists of interest to the public. Three of these addresses
have a corresponding administrative address. If you want to be added to or removed
from a mailing list, send mail to the administrative address, not the mailing list
address.
info-dylan@cambridge.apple.com
info-dylan-request@cambridge.apple.com
(administration)
info-dylan-req@cambridge.apple.com@internet#
(administration from Applelink)
This is a two-way mailing list for discussing any and all issues related to Dylan.
announce-dylan@cambridge.apple.com
announce-dylan-request@cambridge.apple.com
(administration)
announce-d-req@cambridge.apple.com@internet#
(admin from Applelink)
This is a mailing list for major announcements about Dylan (new implementation
availability, new manual availability, etc). This mailing list is for people who want to
keep up on Dylan news, but don't want the quantity of mail that comes through
info-dylan.
dylan-builders@cambridge.apple.com
dylan-builders-request@cambridge.apple.com
(administration)
d-builders-req@cambridge.apple.com@internet#
(admin from Applelink)
This is a two-way mailing list for people who are working on Dylan implementations
or who are considering working on an implementation. If you want to join this list,
please send mail describing your plans to dylan-builders-request.
dylan-comments@cambridge.apple.com
This is a one way mailing list for sending comments to the people working on Dylan at
Apple. Most Dylan discussions can take place on info-dylan.
Does Apple have an implementation of Dylan?
Apple hasn't announced plans to release an implementation of Dylan. However, we are
working on implementations, and our implementation efforts have been an important
proving ground for the Dylan design.
Will there be Apple products based on Dylan?
Apple has not announced any use of Dylan in products.
Is Dylan related to the Apple PDA project called Newton?
No. Dylan is being created by Apple's Advanced Technology Group, and no
product-specific implementations of Dylan have been announced yet. If you are looking
for more information on Newton development, you need to contact the Newton
Developer Relations at NEWTON.DEVS @applelink.apple.com.
Are there third-party implementations of Dylan available?
Several third-parties have expressed interest in implementing Dylan. A group at DEC
has succeeded in implementing a language based on the Dylan manual. They describe it
as follows:
Thomas, a compiler written at Digital Equipment Corporation's Cambridge Research
Laboratory, is now available to the public. Thomas compiles a language compatible
with the language described in the book "Dylan(TM) an object-oriented dynamic
language" by Apple Computer Eastern Research and Technology, April 1992.
The Thomas system is written in Scheme and is available to run under any one of three
public implementations of Scheme: MIT's CScheme, DEC's Scheme->C, and Marc
Feeley's Gambit. It can run on a wide range of machines including the Macintosh, PC
compatibles, Vax, MIPS, Alpha, and 680x0. Thomas generates IEEE compatible Scheme
code. The entire system (including sources) is available by anonymous ftp from:
crl.dec.com:pub/DEC/Thomas
gatekeeper.pa.dec.com:pub/DEC/Thomas
altdorf.ai.mit.edu:archive/Thomas
We've also made Thomas available in the Dylan ftp directory at cambridge.apple.com.
Thanks to Marc Feeley, Thomas embedded in Gambit is now available as a stand-alone
Macintosh application. We've placed this in the ftp directory on cambridge.apple.com.
[MADA hopes to make Thomas available on a CD-ROM in the near future.]
Is Dylan a proprietary language? Why is the Dylan name trademarked?
We want Dylan to be available on as many computers as possible. To this end, we are
encouraging groups outside Apple to implement Dylan.
It is our intention to license the Dylan trademark to any implementation which passes
a standard test suite. The purpose of the trademark is to ensure quality and consistency
among implementations.
What should I do if I want to implement Dylan?
Send mail to dylan-builders-request@cambridge. apple.com. We are putting together a
program to support implementors, and we want to hear from you. (Applelink users
should send mail to d-builders-req@applelink.apple.com @internet#.)
If you've written an implementation of Dylan and want to release it, please contact us
for a trademark license.
Is the Dylan language design frozen?
We don't plan changes to the general structure of the language, but we expect to
continue working on the details. We also expect to specify some extensions and
libraries.
We welcome your comments on the Dylan design. Your feedback is very important to
the further evolution of the language. We haven't specified a limited review period.
Please understand that because of the amount of mail we are receiving, we may not be
able to respond to your message in detail.
Are design clarifications available?
We are working on design clarifications. They will be made available via anonymous
ftp from cambridge.apple.com.
Is there a group which promotes the use of object-oriented dynamic
languages?
Yes. There is an OODL special interest group of MADA. MADA is a group which
champions object-oriented programming on the Macintosh. The OODL sig is currently
focusing on Macintosh Common Lisp, but it intends to expand to other languages and
environments.
To subscribe to the OODL sig mailing list from Applelink send mail to OODL.SIG.
Internet subscriptions should be requested from
oodl-sig-request@cambridge.apple.com.
Questions about the Dylan Language Design
Is Apple planning to specify an alternate syntax for Dylan?
Yes. We recognize that many people prefer an algebraic syntax, and we plan to create
and document such a syntax for Dylan.
Are there plans to specify a standard i/o package for Dylan?
Simple i/o will probably be specified in an optional library, rather than in the core
language. A single i/o system wouldn't make sense on all computing devices because of
the variation in user interfaces and storage systems.
Will Dylan specify a standard threading mechanism?
We recognize that threads are important and that most implementations of Dylan will
support them. We haven't yet decided whether a standard thread mechanism would be
appropriate for all platforms.
Why is 'make' allowed to return a previously allocated instance, or an
object which is an indirect instance of the class passed to 'make'?
We feel that this is a very important abstraction mechanism. A class should have
flexibility in how it implements 'make', as long as the object returned fulfills the
protocol of the class.
For example, this allows a library to document a single abstract class which is
supported by several undocumented implementation classes. The abstract class can
choose which implementation class to instantiate based on the additional arguments to
'make'. This allows optimizations which are transparent to the clients of the library.
The default method for 'make' of a user-defined class returns a fresh direct instance of
the requested class.
The Dylan manual doesn't require implementations to optimize tail
recursion. Was this an intentional omission, or an editorial oversight?
It was an editorial oversight. Dylan implementations will be required to be properly
tail recursive.
The Dylan manual doesn't say much about modules. Will this be specified
in the future?
Dylan modules will be further specified in an upcoming design note. At this time we
expect modules to exist only at compile-time, not at runtime. Non-portable extensions
may support runtime module operations.
Can the 'method' special form be used to create closures?
Yes.
I don't understand how setter variables work. Is 'setter' a special form?
'setter' just provides an alternate way to spell variable names. For example, the
following are all legal spellings of variable names:
foo
bar
(setter foo)
(setter quux)
'setter' is pure syntax, and nothing more. It's probably unnecessarily confusing to
make setter variables look like function calls. For this reason, we are considering
changing the syntax of setter variables.
Why not just have 'setter' be a function which takes a getter functio as
an argument and returns the corresponding setter function?
If we did this, the action of exporting a getter function would automatically export the
setter as well. We believe that it's important to allow the getter and setter to be
exported and imported independently. The design of setter variables allows this.
What kind of object is used to return multiple values?
When a function returns multiple values, the return values are not stored in a
wrapper object; they are returned directly. For example, if a function returns "the
values 4 and 5", it returns two integers. It does not return a data structure which
contains two integers.
Returning multiple values is similar to calling a function with more than one
argument. When passing multiple objects as arguments to a function, the objects do not
have to be stored in a single data structure before they are passed.
Is the specification of sealing complete?
No. We expect the specification of sealing to evolve as we gain implementation
experience.
At this point, we believe that sealing operations should be expressed declaratively, as
compile-time operations, rather than as run-time operations. In the Dylan manual
they are described as run-time operations.
Will Dylan include 'eval'?
Some implementations may choose to support 'eval', but we do not have plans to add it
to the language standard. We feel that the delivery of applications which are space
efficient requires the separation of development time activity from runtime activity.
Will Dylan include an application framework?
We recognize the value of application frameworks, especially cross-platform
application frameworks. Unfortunately, because of the great variation in computing
platforms, a single application framework will not be part of the Dylan language. On
each platform, there should either be a Dylan-specific application framework, or
Dylan should be able to use application frameworks written in other languages.
Will Dylan interface to other languages?
We recognize that seamless integration with other languages, especially C and C++, is
essential. We are working on addressing this issue. The solutions may not be part of
the Dylan language proper.