Transcript Towards a Unified Programming Language 236801

Towards a Unified
Programming Language
Ole Lehrmann Madsen
ECOOP 2000
Presented by:
Ratsaby Gil
038369021
1
Contents
•
•
•
•
•
2
Introduction
Programming Paradigms
BETA
Towards a unified paradigm
Conclusion
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.
3
Programming Paradigms
A Programming Paradigm is a
perspective on, style of, approach towards
programming:
Imperative
Functional
Logic
OOP
…
4
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.
5
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.
6
Imperative Programming
Paradigm
•
Program = a (partially ordered)
sequence of actions (procedure calls)
manipulating a set of variables.
•
Traditional programming
– (computers = programmable calculators)
•
7
Large programs are hard to understand.
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.
8
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.
9
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?
10
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.
11
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.
12
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.
13
BETA: Pattern
In BETA, these abstraction mechanisms
are unified into one construct – the pattern.
pattern
class
procedure
generic-class
14
function
type
process
interface
exception
Pattern Example
Implementing a “class” Point with the
“operations” display, move and add:
15
Point:
(# display: (# …
do … #);
move: (# … do
… #);
add: (# … do
… #);
#);
S: ^Point;
&Point[]  S[];
S.display;
Pattern Attributes
A pattern may contain
declarations of
attributes, in the form
of patterns.
Point has 3 pattern
attributes: display,
move and add.
16
Point:
(# display: (# … do
… #);
move: (# … do
… #);
add: (# … do
… #);
#);
S: ^Point;
&Point[]  S[];
S.display;
Pattern’s do-part
• A pattern may contain a
do-part, i.e., a sequence
of statements to be
executed.
Point:
(# display: (# … do
… #);
move: (# … do
… #);
add: (# … do
The procedure patterns
… #);
display, move and add
#);
have a do-part, but
S: ^Point;
Point does not.
&Point[]  S[];
S.display;
17
BETA Imperatives
• S: ^Point declares a dataitem that can reference
Point:
Point instances or its
(# display: (# … do
subpatterns.
… #);
• &Point[] generates a new … #);
instance of Point, and it’s
reference is assigned to S. … #);
move: (# … do
add: (# … do
#);
• S.display invokes the
S: ^Point;
operation display on the &Point[]  S[];
Point-instance referred by S.S.display;
18
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.
19
Point:
(# display: (# … do
… #);
move: (# … do
… #);
add: (# … do
… #);
#);
S: ^Point;
&Point[]  S[];
S.display;
Uniformity of Patterns
There’s no difference
between the declarations of Point:
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.
20
(# display: (# … do
… #);
move: (# … do
… #);
add: (# … do
… #);
#);
S: ^Point;
&Point[]  S[];
S.display;
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.
21
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?
22
Procedure Subpattern
Combination of
patterns’ do-parts
using the innermechanism.
23
monitor:
(# entry:
(#
do mutex.P;
inner;
mutex.V
#);
mutex:
@semaphore
#);
buffer : monitor
(# put: entry (# do
… #);
get: entry (#
do … #)
#);
Procedure 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.
24
monitor:
(# entry:
(#
do mutex.P;
inner;
mutex.V
#);
mutex:
@semaphore
#);
buffer : monitor
(# put: entry (# do
… #);
get: entry (#
do … #)
#);
BETA: Virtual Procedure Patterns
Virtual procedure patterns are similar to virtual
functions in C++. Set:
However, virtual
procedures may
be extended
(using inner), not
just redefined.
25
(# element:< object;
display:< (# ... do ... #);
current: ^element
#);
StudentSet: Set
(# element ::< Student;
display::< (# do
current.print #)
#);
BETA: Virtual Variable Patterns
Class patterns
may also be
virtual.
StudentSet’s
current is of
type Student
instead of type
object.
26
Set:
(# element:< object;
display:< (# ... do ... #);
current: ^element
#);
StudentSet: Set
(# element ::< Student;
display::< (# do
current.print #)
#);
BETA: Nested Patterns
We have already
seen how to
define a pattern
inside a pattern.
(Similar to innerclasses in Java)
27
Grammar:
(# Symbol: (# ... #);
...
#);
Java: @Grammar;
Self: @Grammar;
S1,s2: ^Java.Symbol;
R1,R2: ^Self.Symbol;
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.
28
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 (# … #)
29
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: …;
#)
30
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
31
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.
32
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.
33
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
34
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.
35
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.
36
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
37
Constraint Prog. Integration
• No concrete proposal for BETA.
Person: class { …
spouse: ref Person;
constraint spouse.spouse =
self
}
38
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.
39
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.
40
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.
41