Dylan FAQ, Monthly Posting

[alms@cambridge.apple.com]

Dylan(tm) FAQ September 21, 1992

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.  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)
  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)
  This is a mailing list for major announcements about Dylan (new implement-
  ation 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)
  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 products based on Dylan.

* 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.

* 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.

* 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 a C or Algol-like 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 function
  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.