Re: A few comments on the FAQ

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

    Date: Fri, 02 Oct 92 18:27:26 EDT
    From: moon@cambridge.apple.com (David A. Moon)
    These are my personal comments, not any kind of response from Apple.

I appreciate them, anyway.

    I think there is no disagreement here.  Does the microprocessor in your 
    microwave oven have an ANSI C I/O library in it?  I hope not.  That's why I/O 
    is not part of the language in C nor in Dylan.
    
Indeed.  But note that there *is* a standard library, that was
standardized as part of the standards process.  There needs to
be some parallel development of the language and the ancilliary
things that will make it a success.  At the very least, there
needs to be a scorecard, of what items are needed, and intended.

Such a scorecard will go a long way toward addressing a lot of
concerns, that the FAQ currently just raises as issues, without
settling them in anyone's mind.

By the way, note that there are a lot of things in the Dylan
language, which are not in ANSI C, and which would be in libraries
if they were, and which I would also hope would not be included
in my microwave.  I'm not saying that's wrong.  But libraries
aren't the only potential mechanism for "deletable modules" in
the language, and this isn't precisely the criteria either of
us are using to choose what should be libraries.

I'm not sure what the criteria are, however.  I suspect
we're both more eager to have optional environmentally-side-effecting
code be in libraries than optional datatypes.  Still, perhaps
some of the fancier datatypes should be made into standard
libaries which are documented with the language.  This will
make the language itself smaller, and might help sell it to
the C crowd.  They are more likely to understand "It's an optional
library" than "it doesn't have to be included if you don't use
it."

    There is no change-class function in Dylan.

That's what I get for sending mail at home, when my manual is
at work.  I was thinking of the instance updating when a class
changes.  If you change a class in such a way that a running
method no longer applies, what happens?  The answer perhaps
lies in a more clear separation of compile-time and runtime.

    This seems likely to be highly dependent on the underlying implementation, and 
    is one reason why we've been reluctant to specify anything as part of the 
    language.  We souldn't want to specify something that some important platforms 
    cannot implement efficiently.  Of course, that reluctance militates against 
    portability, but that problem is inherent in the current state of the art of 
    multiprocessing, isn't it?
    
I don't really think so.  I think it's a language issue.
Specifically, how much of the lower-level non-determinism
is reflected in the language?  This leads to a clear-cut
trade-off:  potential efficiency vs determinism.

If you want to reserve the efficiency, you have to say that
the order is indeterminate in some implications.  Then
people can write portable code.  I don't think that's the
best point in the trade-off curve, however.

I don't claim to know the best answer.  But there are a
number of potential ways to either give the user control,
or establish rules about what the user can expect, that
will make synchonization much easier without placing
undue burdens on implementation.

But even if you throw up your hands and say "We can't
decide the policy", that directly reflects into the language,
and the consequences need to be stated.  You can even require
implementations to state their policies, so users can write
non-portable code that takes advantage of determinism where
present.

    >     * Will Dylan include 'eval'?
    > It seems to me this is properly a library.

    So it would be a bad idea to require all implementations to include the 
    infrastructure needed to make an eval library possible.

Hmm.  Is it really too much to expect that info on external module
interfaces would be available?  If you don't want to spend the space,
don't make any externals, and any evaluation won't be able to reference
anything.

I'm a strong advocate of making interfaces manifest; AppleEvents
only go a short way toward what I'd like to see.  Given all the
work that's being done in Home Automation (q.v. Bill Gate's $14M
house), even microwave oven controllers have need of this.
    
    > 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.
    
    Unless you have two implementations that are completely binary-code-compatible 
    (not only processor instruction set, but the whole runtime environment) except 
    for the user interface, or whatever these methods deal with, I don't see any 
    advantage in removing these methods as late as link time.  It seems like you 
    would have to compile your program separately for each implementation, so the 
    customization could occur at compile time.  Macros seem like a likely 
    implementation technique for compile-time customization, so once they are in 
    the language it doesn't seem likely that anything else would have to be added, 
    not even a portable way to determine at compile time what implementation is 
    the target, since one can always have a convention of separate files defining 
    a few macros with different definitions for each implementation.

I'm sorry, I should have been a bit more clear.  I really meant
"as soon as it can be determined that they're not needed.", which
could be compile time, link time, or even sometimes runtime.

Consider, too, dynamic linking, where you may add features
to the mix at runtime.

For example, consider all the code which has to ask the Gestault
managerd what features a particular Mac has.  With dynamic
linking, a lot of code for supporting old hardware can be left
out at link time.  Without dynamic linking, you fall back on
the runtime dispatch.  If you know the target environment at
compile time, the compiler is free to skip irrelevant ones.

I have used the technique of explicitly representing the runtime
environment and supplying it as an argument to methods needing
specialization by environment, quite a bit.  It works quite well,
and is very natural.  It's one of the better arguments for
multimethods, in my opinion.