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

OO Scheme Proposal w corrections


I have not seen this yet and we have a flakey net connection, so this is a
repost (except that I have fixed the denotational semantics bugs I found
upon rereading it--sorry about the bugs).  I should have a full semantics
for the meeting.

-Ken

;------------------------------------------------------------
FILE:		"OOSchemeProposal"
IMPLEMENTS:	Proposed Object Oriented extension to Scheme
AUTHOR:		Ken Dickey
DATE:		1992 June 14
LAST UPDATED:	1992 June 15
STATUS:		Draft
;------------------------------------------------------------

Both first-class environments and first-class extents can be used to
provide object oriented extensions to Scheme.  I feel that these
facilities give too much expressive power to the programmer while
making implementation more difficult and reducing overall runtime
efficency.  This proposal supports reasonable use of environments to
provide object oriented extensions to Scheme, allows typical compiler
lexical analysis and code generation, and does not inhibit future
inclusion of first-class extents or environments at a later date. 

;------------------------------------------------------------

The particular OO style supported is that of T, AMOS, and YASOS:
lexical, applicative operations and instances.

FORMS:
  (OPERATION (<instance> <arg> ...) <default-body>)
  (OBJECT <method>+ )
  <method> = ((<operation> <instance> <arg> ...) <body>)

The crux of this proposal is that methods, unlike lambdas, do not
retain their environment but instead use the closed environment of
their instance argument.  This allows methods to be "pure code", so
all instances created from the same object form ("class") can share
the same "method environment"--i.e. no closure needs to be generated
for methods.  Instances returned from the object form retain in
addition to the standard environment an additional "method
environment".  As the only (normal) environment passed to a method is
the environment of an instance created via the object form defining
the method, the "shape" of the environment is constant and the lookup
analysis, code, and runtime performance is virtually identical to that
for a lambda used in place of the object form.

A useful extension would be to allow instances to be applicable,
i.e. the object form is  (OBJECT <lambda> <method>+ ) and 
(procedure? <instance>) -> #t. 

Extensions for multiple inheritance are straightforward.

;------------------------------------------------------------

Let me attempt to be a bit more formal about this...


ABSTRACT SYNTAX additions
  Exp -> ... | (object Me0 Me*) | (operation (I0 I*) Gamma* E)

  Me in Methods -> ((I0 I1 I*) Gamma* E)
  Op in Operations
  In in Instances


DOMAIN EQUATION additions

Instances
  iota    in I = L -> (U x P)		

Method Environments
  pi      in P = O -> D			

MethoDs
  delta   in D = (I E*) -> K -> C

Operations
  omicron in O = L x (E+ -> K -> C) x (I E* -> K -> C)
                   ;  default fun   ; dispatch to method


SEMANTIC FUNCTION additions

Eval[ (object Me0 Me*) ]  ; -> I
Eval[ (operation (I0 I*) Gamma* E) ]  ; -> O

applicate = lambda e e* k . e in F -> (e | F take 2) e* k,
                            e in O -> dispatch( e (e* drop 1) (e* take 1) k ),
                            wrong "bad procedure or operation"

dispatch = lambda o i e* k .
		i in I -> (pi-lookup i o)
			    (lambda d . d in undefined ->
					default-operation( o i e* k ),
					apply-method( d i e* k )),
                          default-operation( o i e* k )

default-operation = lambda o i e* k . 
			(o take 2 in F) -> (o take 2) (i concat <e*>) k,
					   wrong "bad operation for object"

pi-lookup looks up the operation in the method-environment of the
instance.

apply-method uses the instance's (normal) environment to "make the
method into a lambda" and then does the application.  [This appears
straightforward, but is tedious to type without a greek keyboard...]

;--------------------------E-O-F-----------------------------