1. The successes and failures of a language as a language extension. Kasper B. Graversen presented at ECOOP’03 workshop 15

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

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

4. The role concept 2/2 Technical goals  Roles are subtypes of their intrinsic  Applicable 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.

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

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

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

8. :B Implementation 2/3 class B { void bar(){} } Role R for B { } r =new R( new B() ); r.bar(); :R r : rolemanager

9. :A foo Implementation 3/3 (re-defining 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(); :R c baz : 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)

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

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

12. Main 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 intrinsic A foo() B foo() bar() R pip() bar(); :B :R foo 1.self = :R 2.R: delegates to intrinsic’s foo 3.B: calls self.bar() 4.self has no bar! (but we know one exists!)

13. 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/6

14. No field access detection  We had to create accessor-methods and transform the code to using these  Field 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/6

15. Hard to debug programs which the Java compiler failed compiling  The 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/6

16. 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/6

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

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

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

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

21. API 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 world  We need I/O (disc,database,network,keyboard,mouse) Graphical User Interface (elemental data structures) Language extensions can usually effortless use the host language API.

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

23. Conclusions Extending Java was nice since  We got a quick start  We had a huge API available  Existing programs could use Chameleon classes.  We found it a manageable task to extend the role concept in many directions.

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

25. The end...