University of Illinois at Urbana-Champaign

foote@cs.uiuc.edu

7 November 1992

Saturday

IMSA '92 Workshop on

Reflection and Metalevel Architectures

Tokyo, Japan

object-oriented programming and design techniques

with reflection promises to dramatically change the way that we

think about, organize, implement, and use

programming languages and systems

Building object-oriented languages out of

object-oriented tools and techniques to be brought to

bear on th language level itself...

A system built of objects can serve as the basis

for an object-oriented framework

An object-oriented language with a reflective

metalevel architecture is easy to extend.

Existing metaobjects may be selectively specialized

and dynamically reintroduced into a running system.

Is callling them pragma's too timid?

However, were these annotations added

to runtime data structures automatically,

would we consider them extenstions?

Static vs. Dynamic translation?

How incremental could this process be?

How much would a uniform object-oriented

substrate have helped here?

Are explicit annotations a realisitic option in general

for converting sequential programs to concurrent programs?

What is the role of program transformation at the

abstract syntax tree level as a means of opening

up languages?

(Things one might reify)

Variables/Slots

Selectors/Generic Functions/Keys/Operators

Messages

Evaluators/Processors/Interpreters

Method Dictionaries/Script/Scripts Sets/Role//Containers/Behaviors

Records/Repetoire/Relation/Table/Index

A-List/Association/Pair/Tuple/Entry

Handles/Pointers/Names/Addresses/Locations/References/OOPs

Environments

Continuations

Contexts (Method, Block)

Mailboxes/Message Queues

State Memory/Stores/Storage

Blocks/Closures

Classes

Types

Prototypes/Traits

Signatures/Protocols

Methods (Primitive and otherwise)

Code/Expressions/Parse Trees/Byte Codes/Forms

(Denotations?)

Processes/Threads/Engines

Objects

Integers/Floats/Reals/Strings

Arrays/Aggregates/Structures/Collections/Lists

(other primitive objects)

all computation shall be conducted via message passing

everything shall be a first class object

(including variables, "code", contexts, oops)

computations shall be represented by first class objects

at a semantically interesting level

behavior only shall determine an object's identity

at least from an extensional standpoint

shall be externally indistinguishable

shall be externally indistinguishable

That is, name binding, particularly for closures, will be handled by explicit runtime objects.

Declarations are executable imperatives that have a temporal scope. A declaration is a dynamic invocation of a mechanism that enforces the declarations intended consequences.

The architecture should be cleanly layered.

The distinction between application dependent and independent

layers will often be one of degree

Significant elements of the system (including the interpreter itself)

will be distribubuted across a constellation of objects

Stratification and Factoring can be thought of

a suggesting a distributed vertical and horizontal organization

feature is necessary is when a lot of people go to

a good deal of trouble to reinvent it in cumbersome ways

in existing languages

Smalltalk programmers have shown

remarkable ingenuity in getting around the VM barrier...

Encapsulators (Pascoe)

Messick and Beck (Active Variables, Advised Methods.)

Borning (ThingLab)

Randy Smith (ARK)

ACTRA (Thomas)

ACTalk (Briot)

That method dictionary hack from '90 or '91... (Boecker)

Object-orientation in the first place...

...let alone dynamic object-orientation (Cox, Burkhardt)

Tiemann (Wrappers)

Various persistent object schemes (BKS's Poet, Borland's OWL)

Various resource management schemes

The MIP

Choices

God knows how many people (re-)invented various

object-oriented and reflective features

Why not?

Store polymorphism could be interesting...

Smalltalk calls this level the Object Memory

The OM is responsible for garbage collection

and is the basis for image snapshots...

An Object Pointer (OOP)

The instance

class pointer

fixed part

indexable part

state

behavior

evaluation

message queue

store

repetoire

ensemble

<queue>

Program generation

Polymorphic interpreters

Polymorphic scripts

Instance

Class

Operator

Other Specializers

Context

Current Evaluator

In Super-Ego, these are part of Ensemble Objects

atom$, return$, block$, method$, primitive$

sequence$, collection$

while$, top$, send$, get$, set$

reflect$

atom, method, primitive, block, send

Primitive operators are thought of as cached

Hence, idempotence is exploited to short circuit the tower

Instance

State

Templates

Sharing

Scripts

Semantics

Dispatching

Variables

Primitives

Closures

Context

Control

Namespace

Animus

Do we embrace it as a white box?

Or pretend its beneath us, Laputan-style?

Or do we subscribe to a layered, translucent architecture?

Frameworks may make it possible to embrace,

rather than ignore, implementation differences...

Consider, for instance, polymorphic code generators...

There is an interesting tension between

object-oriented uniformity and low level visibility

Do you chose one, the other, or both?

A point: Tables beat (even) frameworks.

If you can push all the details into the data

that is good...

The O**2 experience is a drive towards pushing

more complexity (control?) into the data structures...

Lisp: Unemcumbered linguistic licensiousness

The linguistic imperialists

C: The pragmatists

laisse faire ... Languages grow unzoned, like Houston

Pascal: the ministry of computing

Linguistic totalitarians...

3-KRS Metaobjects

Base case differs from other

Some language designs are Laputan,

and don't ground out at all

Some are built on rigid, immovable foundations

Some are like the surface of Jupiter...

...with language and implementation objects coexisting...

Objects make it possible to treat languages themselves

as dynamic, first-class, evolving parts of a system,

that benefit themselvles from the power of object-oriented techniques

like framework construction

Building languages out of dynamic, first-class objects encourages

a highly reflective approach to architecture

Objects can serve as the basis for a more flexible underlying

A well chosen set of objects

can permit a language to encompass a variety

of different programming models and features

Object-oriented metalevel architectures can provide

a structural redoubt as existing system organizations

are rethought...