[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Dylan and executables?



> Date: Tue, 7 Jul 92 18:12:35 CDT
> From: letni!nps002!sgriffit@decwrl.dec.com (Sam Griffith)
> To: info-mcl@cambridge.apple.com
> Subject: Dylan and executables?

You've got some good questions, but I'd like to prevent (if I can)
the info-mcl list from becoming a Dylan discussion list. While
we know there's an awfully large overlap in interest, it's better
to keep things in their proper places.

Apple has not set up a two-way Dylan discussion list or newsgroup 
so far, but you are encouraged to send your comments to us at
dylan-comments@cambridge.apple.com.

> I've browsed the dylan spec, and I was wondering, since dylan is geared 
> more towards actually producing, (I can't remember how it was phrased in 
> the manual) a more deliverable based dynamic language, what is the overhead 
> for being dynamic, ie. - every program will have to include a runtime, 
> what is the size of that runtime. 

Overhead is a matter of implementation, not necessarily an intrinsic 
aspect of the language per se. Since a language's programs might be 
expected to run on different configurations of hardware and O/S, 
and with many different kinds of compiler technology, it's impossible 
to compare apples and, uh, seaweed.

> Also, how does the performance of dylan 
> compare to some of the other OOP languages, say Smalltalk, Obj-C, and C++.  
> In that same area, what optimizations, will dylan make on an executable to 
> optimize out unused methods, classes, etc.?

Again, it's impossible to comment on performance in the abstract, but
we have designed Dylan from the start to allow these kinds of optimizations.

> Another thing, the manual mentions wanting other companies to port it to 
> other machines.  Is this happening?  

Yes. If you are interested in writing your own Dylan implementation
(either commercial or non-commercial) please drop us a line.

> Also, exceptions, collections, and the I/O lib are mentioned in the book.  
> What other libraries are going to be standard per say?  

We haven't made any specific announcements yet.

> What about the possiblity of persistence being part of the language definition?

We haven't made any announcements about that yet, either. It is always
possible as a library extension to the language, and if you have comments
or suggestions, we're always glad to hear them.

>Sam Griffith Jr.
>digi.lonestar.org!nps002!sgriffit
>
>