Xref: utzoo comp.lang.scheme:2135 comp.lang.lisp:4605 comp.lang.smalltalk:2736 Path: utzoo!news-server.csri.toronto.edu!cs.utexas.edu!samsung!crackers!m2c!umvlsi!dime!dime.cs.umass.edu!moss From: moss@cs.umass.edu (Eliot Moss) Newsgroups: comp.lang.scheme,comp.lang.lisp,comp.lang.smalltalk Subject: Re: implementing an interpreter Message-ID: Date: 14 Mar 91 17:02:53 GMT References: <1991Mar8.153120.19836@tripos.com> <50211@apple.Apple.COM> Sender: news@dime.cs.umass.edu Reply-To: moss@cs.umass.edu Followup-To: comp.lang.scheme Distribution: comp Organization: Dept of Comp and Info Sci, Univ of Mass (Amherst) Lines: 17 In-reply-to: mikel@Apple.COM's message of 13 Mar 91 19:08:50 GMT I don't think BiBoP would be all that good for Smalltalk, because (unlike LISP), Smalltalk has a very open ended collection of types of objects (users add new classes). If you're just interested in segregating based on low level properties (e.g., bytes objects versus pointers objects versus methods (which mix the two)), it might work, but there are many flavors of each of these. Perhaps the only aspect I would consider is classes treated specially by the interpreter, such as Float. It's not at all clear that the gain in complexity is worth the space savings, or that there is any time performance advantage (and perhaps a disadvantage). -- J. Eliot B. Moss, Assistant Professor Department of Computer and Information Science Lederle Graduate Research Center University of Massachusetts Amherst, MA 01003 (413) 545-4206, 545-1249 (fax); Moss@cs.umass.edu