1

Towards a Unified Programming Language

Ole Lehrmann Madsen

ECOOP 2000

Presented by:Ratsaby Gil038369021

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 ParadigmsA Programming ParadigmProgramming Paradigm is a perspective on, style of, approach towards programming:

ImperativeFunctionalLogicOOP …

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 Integration of the best concepts from the different paradigms into one the different paradigms into one language.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 inputsA program is a function, mapping inputs to outputs.to outputs.–There are no assignable variables.There are no assignable variables.–There is no “state”.There is no “state”.–There are functions, values and types.There are functions, values and types.–There are higher-order functions 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 A program is a set of equations describing relation between inputs and outputs.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 OOP program is a physicalphysical model, model,

simulating a part of the world.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 Integration of useful concepts and constructs from different programming constructs from different programming paradigms/languagesparadigms/languages.

• To prevent explosion of features, it was necessary to unify and generalizeunify and generalize existing constructs.

13

Abstraction MechanismsObservation: most programming languages provide abstraction mechanisms:Description of general entities that may be Description of general entities that may be instantiatedinstantiated:

Procedure Instances: procedure-activation-records.

Class Instances: objects.

Function Instances: function activations.

Types Instances: values.

Task types Instances: tasks.

14

BETA: PatternPattern

In BETA, these abstraction mechanisms are unified into one construct – the patternpattern.

classclass procedureprocedure

patternpattern

typetype processprocess

generic-classgeneric-class functionfunction exceptionexceptioninterfaceinterface

15

Implementing a “class” PointPoint with the “operations” displaydisplay, movemove and addadd:

Point:

(# display: (# … do … #);

move: (# … do … #);

add: (# … do … #);

#);

S: ^Point;

&Point[] S[];

S.display;

Pattern ExamplePattern Example

16

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;

Pattern AttributesPattern Attributes

17

• A pattern may contain a dodo-part, i.e., a sequence of statements to be executed.

The procedure patterns display, move and add have a dodo-part, but Point does not.

Pattern’s do-partPattern’s do-part

Point:

(# display: (# … do … #);

move: (# … do … #);

add: (# … do … #);

#);

S: ^Point;

&Point[] S[];

S.display;

18

• S: ^Point declares 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.

BETA ImperativesBETA Imperatives

Point:

(# display: (# … do … #);

move: (# … do … #);

add: (# … do … #);

#);

S: ^Point;

&Point[] S[];

S.display;

19

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

Pattern InstantiationsPattern Instantiations

Point:

(# display: (# … do … #);

move: (# … do … #);

add: (# … do … #);

#);

S: ^Point;

&Point[] S[];

S.display;

20

There’s no difference between the declarations of Point and display:

It is just as easy to execute It is just as easy to execute PointPoint and to create and to create references to references to displaydisplay..

However, invoking Point as a procedure does nothing: it lacks a dodo-part.

Uniformity of PatternsUniformity of Patterns

Point:

(# display: (# … do … #);

move: (# … do … #);

add: (# … do … #);

#);

S: ^Point;

&Point[] S[];

S.display;

21

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

Benefits of the UnificationBenefits of the Unification

• The final language may still have special The final language may still have special constructs (for class, procedure, etc.).constructs (for class, procedure, etc.).

• However, practical experience shows no However, practical experience shows no demand for it.demand for it.

22

BETA: SubpatternSubpattern

• 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 SubpatternProcedure Subpattern

Combination of

patterns’ do-parts using the inner-mechanism.

monitor: (# entry: (# do mutex.P; inner; mutex.V #); mutex: @semaphore #);buffer : monitor (# put: entry (# do … #); get: entry (# do … #) #);

24

Procedure SubpatternProcedure Subpattern• The attribute pattern entry of monitor, is an abstract procedure pattern.

• When buffer’s put or get are executed, the do-part of entry is executed.

• The inner call executes the do-part of put/get.

monitor: (# entry: (# do mutex.P; inner; mutex.V #); mutex: @semaphore #);buffer : monitor (# put: entry (# do … #); get: entry (# do … #) #);

25

BETA: Virtual Procedure PatternsVirtual 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 PatternsVirtual Variable Patterns

Class patterns may also be virtual.

StudentSet’s current is of type Student instead of type object.

Set:

(# element:< object;

display:< (# ... do ... #);

current: ^element

#);

StudentSet: Set

(# element ::< Student;

display::< (# do current.print #)

#);

27

BETA: Nested PatternsNested Patterns

We have already seen how to define a pattern inside a pattern.

(Similar to inner-classes in Java)

Grammar:

(# Symbol: (# ... #);

...

#);

Java: @Grammar;

Self: @Grammar;

S1,s2: ^Java.Symbol;

R1,R2: ^Self.Symbol;

28

BETA: Pattern VariablesPattern 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 ObjectsPart 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: ConcurrencyConcurrency

• 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 conceptsUnification of the various concepts..

The programmer does not alternate between different paradigms.

33

Imperative Prog. IntegrationImperative Prog. Integration

• Some algorithms are best expressed by imperative programs.

• Most OO languages are imperative:

methods are written in an imperative style.

A unified paradigmA unified paradigm should enable should enable imperative programming, including imperative programming, including

support for block structure.support for block structure.

34

Functional ProgrammingFunctional Programming

Benefits of functional programmingBenefits 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. IntegrationFunctional Prog. Integration

• These positive aspects of functional programming are useful.

• How to avoid the negative aspects?

In a unified paradigmIn a unified paradigm, functional , functional programming is useful for expressing programming is useful for expressing

state transitions state transitions insideinside an object. an object.

36

Functional Prog. IntegrationFunctional Prog. Integration

• High-order functions & types should also be included.

• From uniformity, all abstraction mechanisms should be “higher-order”.

Any abstraction should be a Any abstraction should be a

first- class-value.first- class-value.

37

Functional prog. in BETAFunctional prog. in BETA

• BETA supports some of these features.– Sub-, nested, variable, and virtual patterns.

• Syntax: E1 E1 E2 E2 … … En En– Assignment: E V W– Function: (e1,e2,e3) foo V– Nesting: ((a,b) G, c H) F x

38

Constraint Prog. IntegrationConstraint Prog. Integration

• No concrete proposal for BETA.

Person: class { …

spouse: ref Person;

constraint spouse.spouse = self

}

39

Concurrent Prog. IntegrationConcurrent 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. IntegrationPrototype-based Prog. Integration

• Copy objects and modify their functionality without defining new classes.

• Useful in the exploratory phases of Useful in the exploratory phases of programming.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 Future PL should unify the best concepts from current paradigms.concepts from current paradigms.