Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!swrinde!sdd.hp.com!decwrl!parc!norman
From: norman@parc.xerox.com (Norman Adams)
Newsgroups: comp.lang.scheme
Subject: Re: Simulating Environments with Continuations ?
Message-ID: <norman.678125326@crevenia>
Date: 28 Jun 91 16:08:46 GMT
References: <1991Jun27.192117.8609@jato.jpl.nasa.gov> <MARKF.91Jun27182528@montreux.ai.mit.edu>
Sender: news@parc.xerox.com
Organization: Xerox PARC
Lines: 50


>>In article <1991Jun27.192117.8609@jato.jpl.nasa.gov>
>>brian@granite.jpl.nasa.gov (Brian of ASTD-CP) writes:
>
>>   (define ( <class-constructor> [args])
>>
>>     (let (( <ivar1> <init-val1> )
>>	   ( <ivar2> <init-val2> ) ...)
>>
>>       (define ( <method-proc1 [args]> )
>>	 ; reference ivars as free vars )
>>
>>       (define ( <method-proc2 [args]> )
>>	 ; reference ivars as free vars )
>>       ...
>>       (define (self msg [args])
>>	 (case msg
>>	   (msg1 <method-proc1> )
>>	   (msg2 <method-proc2> ) ...)) self))

>markf@zurich.ai.mit.edu (Mark Friedman) writes:
>Unless your interpreter is going out of its way to be wasteful and
>silly (and unless it was careful it would be incorrect for the most
>general case) the above approach will not copy the method-proc's in
>each instance. Each instance (a closure) will have a pointer to the
>environment which contains the method-procs.

Unless your interpreter is very smart, the environment of each
instance will include a first class procedure for each method.  Even
if the environment is shared, that is proabably 2 words per method,
for each instance.  I think we all agree that the size of an instance
should independent of the number of methods it implements.

I think the right approach is to have the compiler support this idiom
(or an equivalent one).  It is not very hard, just a small twist in
your closure analysis.   The T compiler does this.  

This topic is discussed in:

%A Norman Adams
%A Jonathan Rees
%T Object-Oriented Programming in Scheme
%J Conference Record of the 1988 ACM Conference on Lisp
and Functional Programming
%P 277-288
%D August 1988
%K oopinscheme

-Norman Adams
norman@parc.xerox.com