The successesThe successesand failuresand failures of of

a languagea language aas a s a

language extensionlanguage extension..

Kasper B. Graversen

presented at ECOOP’03 workshop 15

The presentationThe presentation The role concept Our approach What problems did we face What did we find advantageous

about language extensions API is just as important... Conclusions

The role concept 1/2The role concept 1/2 Motivation for roles

Bridging the gab between the problem domain and the implementation domain

In the real world no object can be understood outside its context(s)

Roles models a perspective of an object In the real world nothing is static

The role concept 2/2The role concept 2/2 Technical goals

Roles are subtypes of their intrinsicApplicable run-time and at the instance

level.An object may play several roles

simultaneously—even roles of the same time (comparable to Eiffel's repeated inheritance).

Statically type safe.Has constituents, which augment

existing methods.

The presentationThe presentation The role concept Our approach What problems did we face What did we find advantageous

about language extensions API is just as important... Conclusions

ApproachApproach Host language: Java We made a pre-compiler emitting

Java source code. Our work mainly consisted of

thinking in code-transformations and loopholes to get the desired end-result.

Implementation 1/3Implementation 1/3 Delegation (w. late binding of self.)

Every call is made on an introduced pointer (self), which is passed around with each method call.

Roles became “part-object” which delegated messages (for the methods they inherited but did not overwrite).

Constituent methods forced us to re-define the delegation concept to “latest possible binding of self”.

:B

Implementation 2/3Implementation 2/3

class B { void bar(){}}Role R for B { }r =new R( new B() );r.bar();

:R r

:rolemanager :rolemanager

:Afoo

Implementation 3/3 Implementation 3/3 (re-defining (re-defining delegation)delegation)class A {

void foo}Role R for A { constituent c before foo { baz(); } void baz() {}}A a = new A();new R( a );a.foo();

:Rcbaz

:rolemanager :rolemanager

Message receiver (= self) is a, but a does not have a baz()hence, during constituent execution self must be the constituent

a

(simplified version)

The presentationThe presentation The role concept Our approach What problems did we face What did we find advantageous

about language extensions API is just as important... Conclusions

Main obstacles 1/6Main obstacles 1/6 No access to method dispatching

We had to maintain and pass around a self-pointer (in all methods and method calls)

Problematic when going “outside”, then “inside” chameleon code in the same call, as we then have two self references

Chameleon-Java Java

Main obstacles 2/6Main obstacles 2/6 Typing

Impossible to assign types to classes (using interfaces is non-trivial and fields+ protected methods cannot be part of the type).

Problematic to attach a role to a sub-type of its intrinsicAfoo()

Bfoo()bar()

Rpip()

bar();

:B :Rfoo

1. self = :R2. R: delegates to intrinsic’s foo3. B: calls self.bar() 4. self has no bar!

(but we know one exists!)

Restricted access to properties – we could only get access by using Java’s inheritance.

Inheritted unwanted: fields (memory inefficient)methods, since constituents could be

attached the intrisics’ methods, they had to be executed if they were not overwritten in the role.

We could not express dual inheritance, due to lack of multiple inheritance in Java.

Main obstacles 3/6Main obstacles 3/6

No field access detectionWe had to create accessor-methods and

transform the code to using theseField access became virtual

Shadowing fields would result in faulty programs

Java programs could not use Chameleon-compiled code unless using accessor-methods which were not present in the Chameleon source code.

Main obstacles 4/6Main obstacles 4/6

Hard to debug programs which the Java compiler failed compilingThe programmer had to know the steps

of, and the code transformations.And then in his head, reverse the

transformations in order to find the problem spot in the Chameleon code.

Main obstacles 5/6Main obstacles 5/6

Programming languages not only delimits expressional power, they delimit/direct our thoughts. There were concepts in the first article

we read on the subject (Kristensen and Østerbye

94), we could not comprehend.We invented things, the authors of the

above article had not thought of (but which would be very important for their implementations).

Main obstacles 6/6Main obstacles 6/6

The presentationThe presentation The role concept Our approach What problems did we face What did we find advantageous

about language extensions API is just as important... Conclusions

AdvantagesAdvantages It gave us a rocket start

In 2 days from start, we had rudimentary roles (with faulty delegation it

turned out later :-). It was relatively easy to think in terms

of Java code-transformations rather than assembler instructions.

Enabled us to use/play with small programs to gain an understanding of the concept.

AdvantagesAdvantages Extending the role concept was

rather straight forward Symbiosis between implementation and

conceptual extensions.We believe we would not have come as

far with a lower-level implementation of our role concept.

Existing Java programs could be used in our Chameleon programs, and vice-versa.

The presentationThe presentation The role concept Our approach What problems did we face What did we find advantageous

about language extensions API is just as important... Conclusions

API is just as importantAPI is just as important Ideas for new languages/extensions

must be tried in real world scenarios! This is hard if the language is shielded

from the outside worldWe need

I/O (disc,database,network,keyboard,mouse) Graphical User Interface (elemental data structures)

Language extensions can usually effortless use the host language API.

The presentationThe presentation The role concept Our approach What problems did we face What did we find advantageous

about language extensions API is just as important... Conclusions

ConclusionsConclusions Extending Java was nice since

We got a quick startWe had a huge API availableExisting programs could use Chameleon

classes.We found it a manageable task to

extend the role concept in many directions.

ConclusionsConclusions Extending Java was NOT nice since

Many severe problems arise when really grinding into the issues of the language.

Most things which seemed to be reusable from the host language turns out to be obstacles.

A userfriendly language extension requires a parser, type checker, ‘code mutator’ and a ‘host language emitter’

(almost?) as huge a task as building a compiler from scratch.

The end...The end...