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

agenda for the June 25 R5RS meeting: Proposed Objection

[This is an OO proposal--sorry about the pun 8^]

This is an 11th hour attempt to try to push "object-oriented
programming extensions" from category 3 to category 2.  My concern is
the "language losering problem"--loser languages winning because they
have what is selling now, while a winning language loses because it
does not.

I am hopeful that the following proposal is simple enough to gain
concensus for R^5 (well, probably R^6 but I would like it in R^5!!!).
In any case I think we may have a lively discussion!

-Ken

;------------------------------------------------------------
FILE:		"OOSchemeProposal"
IMPLEMENTS:	Proposed Object Oriented extension to Scheme
AUTHOR:		Ken Dickey
DATE:		1992 June 14
LAST UPDATED:	1992 June 14
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 instances and operations.

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...

{WARNING: I am a better reader than writer of Denotational Semantics}.


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 -> (I E* x F) -> K -> C


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 drop 2) e* k,
                            e in O -> dispatch( e e* 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 drop 2 in F) -> (o drop 2) i 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...]


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

I have not yet had a chance to model the semantics.  Will, have you
updated your executable semantics from R^3 to R^4?  Would someone with
a better DS background like to help me fill this out?

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