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 (plain ascii), or in the file /pub/dylan/dylan-faq.rtf (formatted, using RTF, which can be read by Microsoft Word, MacWrite, and many other word processors). Other Dylan documents are available for ftp from the same directory.
Changes made since the last version of the FAQ are marked by the string '+++'.
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 or the comp.lang.dylan newsgroup, described below.
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.
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.
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.
Yes. There are three mailing lists of interest to the public. Two of these lists are public forums, one is a one-way list for sending comments to the Dylan group at Apple. The info-dylan forum is available in digest form and also as an Internet newsgroup dedicated to Dylan.
To subscribe to one of the public mailing lists, send mail to majordomo@cambridge.apple.com. The body of the message should be "subscribe <list-name>", where <list-name> is the name of the mailing list you want to subscribe to. To unsubscribe to one of the mailing lists, send majordomo a message with the body "unsubscribe <list-name>". If you would like to subscribe or unsubcribe an address which is different from the return address of the message, include the address after the <list-name>. For complete majordomo instructions, send a message with the body "help".
Please do not send administrative requests to the mailing lists! If you have trouble with info-dylan, send mail to sysadmin@cambridge.apple.com.
The mailing lists associated with Dylan are:
Each day's messages are gathered into a digest and sent as a single compound message. If you prefer to participate this way, send "subscribe info-dylan-digest" to majordomo. Info-dylan is also available through the newsgroup comp.lang.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.
Apple has not announced any use of Dylan in products.
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.
Several third-parties have expressed interest in implementing Dylan. There are now two implementations freely available: The first is "Thomas", implemented in Scheme by a group at DEC, and the second is "Marlais", implemented in C by Brent Benson.
Marlais 0.3 is available in the Dylan ftp directory at cambridge.apple.com.
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:
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.
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.
Send mail to dylan-comments@cambridge.apple.com. We have together a program to support implementors, and we want to hear from you. (AppleLink users should send mail to dylan-comments@applelink.apple.com@internet#)
If you've written an implementation of Dylan and want to release it, please contact us for a trademark license.
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.
+++
Last spring we published a set of changes to the language in the form of
Dylan design notes. We expect to have a substantial number of additional
design notes out at the end of January 1994, covering such areas as the new
syntax, the module system, and sealing. At that point, we expect to have the
first version of the language essentially settled.
While the design process hasn't been fully public, we have consulted with other Dylan implementors to validate our design choices and ensure that the language can be implemented efficiently using a variety of strategies. We believe very strongly that the new design will be solid and that people will be very happy with the language as implementations come out. Please understand that because of the amount of mail we are receiving, we may not be able to respond to your message in detail.
We are working on design clarifications. They are available via anonymous ftp from cambridge.apple.com:/pub/dylan/design-notes/ in both plain ascii and postscript file format.
Yes. There is an OODL special interest group of the Software Frameworks Association (formerly called MADA). SFA is a group which champions object-oriented programming on the Macintosh as well as other platforms.
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.
Yes. This has been the source of a lot of discussion on the info-dylan mailing list. There will be only one Dylan syntax, and it will not be a parenthesized (lisp-like) syntax. This was not an easy decision. We realize that that there are good arguments both for and against Lisp syntax. In the end we simply could not ignore the market requirement for an algebraic syntax.
We chose not to support multiple syntaxes because we believe it's important to present Dylan to the world as a single, unified language. Text books, magazine articles, papers, and sample code on the net should all look the same. We didn't want to fragment the Dylan community with multiple syntaxes.
Settling on a single syntax also helped us simplify the language and make it more consistent. It also simplified the design of the macro system.
Yes.
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.
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.
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.
It was an editorial oversight. Dylan implementations will be required to be properly tail recursive.
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.
Yes.
I don't understand how setter variables work. Is setter a special form?
We have changed the syntax of setter; this is explained in Design Note #20: "New Syntax for Setter Variables". This is available on the Internet by anonymous ftp from this directory:
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.
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.
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.
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.
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.