Towards a Unified Programming Language

1. Towards a Unified Programming Language Ole Lehrmann Madsen ECOOP 2000 Presented by: Ratsaby Gil 038369021

2. Contents • Introduction • Programming Paradigms • BETA • Towards a unified paradigm • Conclusion

3. Introduction • OOP is great, popular, ... • OOP is not everything. • Some tasks are better suited with other programming methods. • These methods do have something useful to offer.

4. Programming Paradigms A Programming Paradigm is a perspective on, style of,approach towards programming: • Imperative • Functional • Logic • OOP • …

5. Language • The language you speak restricts you: • Inuit has 70 words for snow • Think of words like toes, weeds,.. • Any PL is of limited expressiveness. • Parts of the problem may be inadequately modeled. • The more programming paradigms you know, the richer is your vocabulary for modeling your problem.

6. Prog. Languages Research • Research goal should be: Integration of the best concepts from the different paradigms into one language. • However, multi-paradigm languages force you to alternate between and consider the different paradigms.

7. Imperative Programming Paradigm • Program = a (partially ordered) sequence of actions (procedure calls) manipulating a set of variables. • Traditional programming • (computers = programmable calculators) • Large programs are hard to understand.

8. Functional Programming Paradigm Intended to give a more mathematical formulation to programs. A program is a function, mapping inputs to outputs. • There are no assignable variables. • There is no “state”. • There are functions, values and types. • There are higher-order functions and types.

9. Logic Programming Paradigm • Same goal as functional programming. A program is a set of equations describing relation between inputs and outputs. • Problem: no general solver. • The programmer is burdened with restricting rules on the equations. • Similar paradigms: Constraint prog., Rule-based prog.

10. OOP Paradigm • BETA view on OO: • OOP program is a physical model, simulating a part of the world. • OOP approach is opposite to functional and logic programming. • State and variables are a central concept. • Is it more natural than mathematics?

11. Other Paradigms • Process-based programming • Emphasize on processes. • Block-structured programming • Statements are grouped in blocks. • Prototype-based programming • Objects are “cloned” from existing objects.

12. BETA • The BETA language design goal: Integration of useful concepts and constructs from different programming paradigms/languages. • To prevent explosion of features, it was necessary to unify and generalize existing constructs.

13. Abstraction Mechanisms Observation: most programming languages provide abstraction mechanisms: Description of general entities that may be instantiated: • Types Instances: values. • Procedure Instances: procedure-activation-records. • Function Instances: function activations. • Class Instances: objects. • Task types Instances: tasks.

14. BETA: Pattern In BETA, these abstraction mechanisms are unified into one construct – the pattern. pattern class procedure type process generic-class function interface exception

15. Pattern Example Implementing a “class” Point with the “operations” display, move and add: Point: (# display: (# … do … #); move: (# … do … #); add: (# … do … #); #); S: ^Point; &Point[] S[]; S.display;

16. Pattern Attributes A pattern may contain declarations of attributes, in the form of patterns. Point has 3 pattern attributes: display, move and add. Point: (# display: (# … do … #); move: (# … do … #); add: (# … do … #); #); S: ^Point; &Point[] S[]; S.display;

17. Pattern’s do-part • A pattern may contain a do-part, i.e., a sequence of statements to be executed. The procedure patterns display, move and add have a do-part, but Point does not. Point: (# display: (# … do … #); move: (# … do … #); add: (# … do … #); #); S: ^Point; &Point[] S[]; S.display;

18. BETA Imperatives Point: (# display: (# … do … #); move: (# … do … #); add: (# … do … #); #); S: ^Point; &Point[] S[]; S.display; • S: ^Pointdeclares a data-item that can reference Point instances or its subpatterns. • &Point[] generates a new instance of Point, and it’s reference is assigned to S. • S.display invokes the operation display on the Point-instance referred by S.

19. Pattern Instantiations • &Point[] and S.display are pattern instantiations. • &Point[] creates a new Point-instance. It corresponds to ‘new’ in C++ or Java. • In S.display, a new display-instance is generated and executed. Point: (# display: (# … do … #); move: (# … do … #); add: (# … do … #); #); S: ^Point; &Point[] S[]; S.display;

20. Uniformity of Patterns There’s no difference between the declarations of Point and display: It is just as easy to execute Point and to create references to display. However, invoking Point as a procedure does nothing: it lacks a do-part. Point: (# display: (# … do … #); move: (# … do … #); add: (# … do … #); #); S: ^Point; &Point[] S[]; S.display;

21. Benefits of the Unification • All the abstraction mechanism are treated in a systematic way: • focus shifts to the abstraction-instance relation. • The language is simpler, syntactically and conceptually. • The unification results in new technical possibilities. • The final language may still have special constructs (for class, procedure, etc.). • However, practical experience shows no demand for it.

22. BETA: Subpattern • It is possible to organize patterns in inheritance hierarchy. • For class-patterns, the inheritance hierarchy is similar to that of other languages. • A question: what does it mean to have a subpattern of a procedure-pattern?

23. Procedure Subpattern monitor: (# entry: (# do mutex.P; inner; mutex.V #); mutex: @semaphore #); buffer : monitor (#put: entry (# do … #); get: entry (# do … #) #); Combination of patterns’ do-parts using the inner-mechanism.

24. Procedure Subpattern monitor: (# entry: (# do mutex.P; inner; mutex.V #); mutex: @semaphore #); buffer : monitor (#put: entry (# do … #); get: entry (# do … #) #); • The attribute pattern entry of monitor, is an abstract procedure pattern. • When buffer’sput or get are executed, the do-part of entry is executed. • The inner call executes the do-part of put/get.

25. BETA: Virtual Procedure Patterns Virtual procedure patterns are similar to virtual functions in C++. Set: (#element:< object; display:< (# ... do ... #); current: ^element #); StudentSet: Set (#element ::< Student; display::< (# do current.print #) #); However, virtual procedures may be extended (using inner), not just redefined.

26. BETA: Virtual Variable Patterns Set: (#element:< object; display:< (# ... do ... #); current: ^element #); StudentSet: Set (#element ::< Student; display::< (# do current.print #) #); Class patterns may also be virtual. StudentSet’s current is of type Student instead of type object.

27. BETA: Nested Patterns Grammar: (#Symbol: (# ... #); ... #); Java: @Grammar; Self: @Grammar; S1,s2: ^Java.Symbol; R1,R2: ^Self.Symbol; We have already seen how to define a pattern inside a pattern. (Similar to inner-classes in Java)

28. BETA: Pattern Variables • In BETA you may also define pattern variables. • Thus patterns are first class values that may be passed as parameters to other patterns. • The behavior of an object can be dynamically changed after its generation.

29. BETA: Part and Singular Objects • Part objects correspond to static references in C++ or Java. • Part of the enclosing object. • R: @Person; • Singular objects correspond to anonymous classes in Java. • headMaster: @Person (# … #)

30. BETA: Concurrency • Patterns may be active objects: have their own thread of execution. Producer: (# do cycle(#do …; E buffer.put; … #) #); Consumer: (# … do … #); P: @ | Producer; C: @ | Consumer; buffer: @ monitor(# put: …; get: …; #)

31. BETA Limitations • Control structures are not evaluations. • Limitation for functional programming • E1 (if C then E2 else E3 if) E4 is not possible • No support for enumerations. • No acceptable syntax was found. • let v = exp1 in exp2 • Another limitation for functional programming

32. Towards a Unified Paradigm • BETA unifies constructs from different programming paradigms. • Several useful concepts are not supported by BETA. • Our main requirement: • Unification of the various concepts. • The programmer does not alternate between different paradigms.

33. Imperative Prog. Integration • Some algorithms are best expressed by imperative programs. • Most OO languages are imperative: methods are written in an imperative style. A unified paradigm should enable imperative programming, including support for block structure.

34. Functional Programming Benefits of functional programming • No side effect on a global state: easier to prove correctness of a given piece of code. • Recursion is powerful. • Higher order functions and types. • Function & types are often first class values

35. Functional Prog. Integration • These positive aspects of functional programming are useful. • How to avoid the negative aspects? In a unified paradigm, functional programming is useful for expressing state transitions inside an object.

36. Functional Prog. Integration • High-order functions & types should also be included. • From uniformity, all abstraction mechanisms should be “higher-order”. Any abstraction should be a first- class-value.

37. Functional prog. in BETA • BETA supports some of these features. • Sub-, nested, variable, and virtual patterns. • Syntax: E1  E2  …  En • Assignment: E  V  W • Function: (e1,e2,e3)  foo  V • Nesting: ((a,b)  G, c  H)  F  x

38. Constraint Prog. Integration • No concrete proposal for BETA. Person: class { … spouse: ref Person; constraint spouse.spouse = self }

39. Concurrent Prog. Integration • No agreement on how OO languages should support concurrency. • Requirements: • Basic concurrency primitives as part of the language. • Writing schedulers • Strong protection on shared data. • More research for modeling concurrent and distributed computing.

40. Prototype-based Prog. Integration • Copy objects and modify their functionality without defining new classes. • Useful in the exploratory phases of programming. • Class-based is still better for the structural phases.

41. Conclusion • Most paradigms have something useful to offer. • Unified paradigm (not multi-paradigm) • BETA is a step in the right direction. Future PL should unify the best concepts from current paradigms.