Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!linus!decvax!genrad!mit-eddie!mit-vax!eagle!mhuxt!mhuxi!mhuxa!houxm!hocda!spanky!burl!duke!unc!tim From: tim@unc.UUCP Newsgroups: net.lang.lisp Subject: Re: Franz flavors? Message-ID: <5543@unc.UUCP> Date: Tue, 12-Jul-83 11:27:08 EDT Article-I.D.: unc.5543 Posted: Tue Jul 12 11:27:08 1983 Date-Received: Wed, 13-Jul-83 08:19:36 EDT References: gatech.288 Lines: 36 Someone asked for a review of the "flavor" idea in Lisp and for a source for Franz Flavors. There are two different and (from what I hear) incompatible implementations of flavors for Franz. One was done at MIT, and is not yet publicly available, according to discussion on the FRANZ-FRIENDS mailing list. The other was done at the University of Maryland; you can get information by writing Liz Allen (umcp-cs!liz). Flavors are very useful in large systems design. It is natural to conceive of a large system in terms of objects and messages between them. Flavors allow you to translate such a design into code very simply. Each system component is the sole instance of its own flavor in this sort of design. The benefits of abstract data types are well-known, so I won't go into them here. Flavors provide a flexible and comprehensible abstract data type mechanism, regardless of the system design applications. A bad thing is that flavors in the UoM Franz Flavors implementation do provide a non-negligible overhead. Sending a message to an instance of a flavor is slower than calling a function. Reportedly, people at UoM are working on a 10%-15% speedup of message passing, but even with that the overhead will be significant in Franz. (Please do NOT write me or anyone else asking about this speedup. It will be announced when it is ready, and your questions will not accelerate its progress; rather the opposite, in fact.) ______________________________________ The overworked keyboard of Tim Maroney duke!unc!tim (USENET) tim.unc@udel-relay (ARPA) The University of North Carolina at Chapel Hill