Re: A few comments on the FAQ

[moon (David A. Moon)]

> Date: Thu, 01 Oct 92 19:54:19 -0400
> From: Bob Kerns <rwk@crl.dec.com>

Bob, I don't want to get into a long discussion, but a couple of your comments
made me feel like responding.  Plus right now I'm trying to find a way to 
avoid fixing a bunch of bugs I found in a program I am working on.

These are my personal comments, not any kind of response from Apple.

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

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.

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

There is no change-class function in Dylan.

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

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?

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

Yes, but it's not quite that simple.  It is impossible to implement eval 
portably, that is, using only the facilities provided in the Dylan book.  For 
example, there is no equivalent of Common Lisp symbol-value.  This is quite 
intentional; the space savings comes not from leaving out the eval function 
itself, but from leaving out any representation of the information that eval 
would use.

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

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

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.