A few comments on the FAQ

[Bob Kerns <rwk@crl.dec.com>]

First, a meta-comment.  It would be helpful if you
included a summary of what has changed in each edition
of the FAQ.
    
    * 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.

I think this is incorrect.  I think the correct statement is:
  A single i/o system will be seriously limited in functionality,
  and will fit poorly into many UI environments and storage systems.
  Nonetheless, it is important to have one so that fully portable
  code can be written at all.  Unless customized for a particular
  environment, such code's UI will be very limited, but that is a
  universal tradeoff for portable code.

If you're serious about going after C programmers, you have to at
least do as good a job as ANSI C in this area.  That's not hard,
and it's useful.  But in fact, you can do much better, since you
have an object system and multiple dispatch.  You could specialize
on implementation, so that an alert message on a Mac on a window
stream pops up an alert dialog, on Motif pops up a Motif dialog,
on a serial stream does it serially, etc.

You also have a big advantage over ANSI C in that you don't
have to attend to a myriad compatibility issues.

It should certainly be emphasized that this is a library issue,
not a language issue.
    
    * 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.

Regardless of whether you standardize on a single mechanism, I
think you need to establish some ground rules and guarentees.
For example, CHANGE-CLASS while a method is running on that
object, should not result in overwriting random pieces of memory.
It should do something predictable and reasonably safe, even
if it "is an error" to do it.

Another issue is whether order-of-writes is preserved when viewed from
another process.  If I set A and then set B, am I guarenteed that in
another process, I won't see B set, and later still see the old value
of A?  This may seem obvious, but in multi-processor systems, it's not.
You need to either explicitly make the restriction, or alternatively,
provide a standard way to cause the restriction to be true when
you need it.

    * 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.
    
This doesn't really address the first part of the question.
I would suggest adding something about how returning existing
instances allows optimization by sharing non-mutable instances.
It's recommended that for classes whose instances can be modified,
that fresh instances always be allocated by 'make' to avoid
confusion.
    
    * 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.
Would it help if 'setter' were a keyword instead?
    * 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.
    
Pointing out the inconvenience of doing similar stuff in C
might be helpful here.

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

It seems to me this is properly a library.
    
    * 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.

I did some thinking about this issue for CLIM.  I think it's possible
to design an application framework API which allows portable code which
integrates reasonably in any environment, and can be specialized as
needed for particular environments.  (No, don't look to existing CLIM
for hints, it's not very close).

But this has no part in the language.

One thing that would help a lot of portability-enhanced libraries,
would be the ability to do some link-time specialization.  That is,
to write implementation-specific methods, and have any methods
which only apply to a different implementation be removed from the
final application.

I haven't completely thought out how to make this work for
cross-compilation, but the basic idea is to be able to remove
methods specialized on <implementation>'s which aren't subclasses
of the target implementation.  I want to understand macros before
I make any attempt to understand cross-compilation, however.