HO

PL –

III 2007

The When, Why and Why not

of the BETA Programming Language

History of Programming Languages Conference (HOPL-III)

HO

PL –

III 2007

Where

HO

PL –

III 2007

HO

PL –

III 2007

Norwegian Computing

Center,Oslo

University of Aalborg

University of Aarhus

HO

PL –

III 2007

Why and When did it happen

1967 - : Simula used as a system description language (today we would have said modeling language)1973 - : DELTA - a system description language based upon the ideas of Simula (Nygaard with Håndlykken & Holbæk-Hanssen)1973: Nygaard guest lecturer at the Computer Science Department, University of Aarhus – in 1974/75 full time visiting professor1975: Svejgaard proposes to make a new language based upon the ideas of Simula and Pascal1976: Decided to do it rather based upon Simula and DELTA – the BETA project started– Kristen Nygaard, Bent Bruun Kristensen, Ole Lehrmann Madsen, Birger

Møller-Pedersen

HO

PL –

III 2007

How was it (not) organized

HO

PL –

III 2007

Research approach I

From SIMULA I language report (1965): “The two main objectives of the SIMULA language are:– To provide a language for a

precise and standardiseddescription of a wide class of phenomena, belonging to what we may call “discrete event systems”.

– To provide a programming language for an easy generation of simulation programs for “discrete event systems”.”

HO

PL –

III 2007

Research approach II

BETA should be a modeling language. BETA should be a programming language. The most important initial idea was to design a language based on one abstraction mechanism. In addition BETA should support concurrentprogramming based on the coroutine mechanism of SIMULA.BETA should have an efficient implementation.

HO

PL –

III 2007

One abstraction mechanism

Simula implementations had revealed similarities between activation records, objects, inner blocks, prefixed blocks, etc– virtual procedures, procedure parameters, name parameters

There had been ideas for a data type concept in Simula, but it did not make it.

And a pure research idea: What would the implications be?

HO

PL –

III 2007

The main ideas, and how they came about

One pattern – Unified parameter passing, function evaluation and assignment

Virtual patterns (classes, methods, types, ...)– Virtuals with constraints in terms of patterns instead of signatures

Specialization of behaviour– Generalized inner, control structures

Simplified coroutines and concurrency – concurrency based upon semaphores and concurrency abstractions

made by means of inner

HO

PL –

III 2007

One pattern

Record types – records with fieldsValue types – often only predefined, assignmentProcedures / functions – parameters/resultClasses -Modules – alternatives to classes or collections of classesProcess types - concurrency

HO

PL –

III 2007

One form

but

P: // pattern name

superP // super pattern

(# A1; A2; ... ; An // attributes

enter (V1, V2, ... ,Vs) // input parameters

do I1; I2; ... ; Im // imperativesexit (R1, R2, ... , Rt) // output parameters

#)

objectdescriptor

HO

PL –

III 2007

Different kinds and construction modes for objects

Kinds– Component (|): alternating/concurrent action seq.– Item ( ): part of an action sequence (stack)

Construction modes– Static (@): part of a containing object i:@Integer

– Dynamic (^): separate objects next: ^Link

– Inserted ( ): ’inline’ executionObject generation, object reference and object execution– Generation (&) – Object as such ([])– Execution of object (;, ->)

How defined– by means of a pattern (pattern-defined) P

– by means of an object descriptor (singular) P(# #)

&C&C[] -> rC[]

x -> rC -> <i,j>

HO

PL –

III 2007

Records

Class

FunctionCustomer:(#name: @Text;addr: @Address

#)

evalInterest:(#sum, result: @Amount;rate: @ Interestenter (sum,rate)do ... -> resultexit result#)

#)

Account:(#owner: ^Customer;balance: @Amountdeposit: (# a: @Amountenter ado a+balance -> balance#)

#)

HO

PL –

III 2007

Components

concurrent components

HO

PL –

III 2007

Tourplanning Invoicing Reservation

alternatingcomponents

partialactionsitems

HO

PL –

III 2007

actionsequences

alternating concurrentpartial

non- synchronized synchronizedExplicitImplicit

items –stack organization

components -each with a stack of items

HO

PL –

III 2007

Virtual patterns

Virtual class patterns with redefinition did not work

But this did

Set:(# ElmType:< (# key: @integer #);

newElement:(# S: ^ ElmType;do &ElmType [] -> S[];

newKey -> S.key;#)

#);PersonSet: Set(# ElmType::< (# name: @Text #) #)

PersonSet: Set(# ElmType::< Set.ElmType(# name: @Text #) #)

HO

PL –

III 2007

Virtual patterns

Virtual method patterns

Person:(# name: @text;

display:< (# do name[] -> out.puttext; inner #)

#)Employee: Person(# salary: @integer;

display::< (# do salary -> out.putint #)#)

HO

PL –

III 2007

Parameterized type patternsSet:(# ElmType:< object;

insert:<(# x: ^objectEnter x[]do x[] -> add#)

#)

PersonSet: Set (# ElmType::< Person # )

StudentSet: PersonSet(# ElmType::< Student #)

HO

PL –

III 2007

Specialization of behaviour I

Control structures

cycle: (# do inner; restart cycle #)

L: cycle(# do (if F.eos then (* end-of-stream *)leave L

if);F.get -> G.put

#);

HO

PL –

III 2007

Specialization of behaviour II

inner for ’methods’File:(#open: (# do ...; inner; ... #);

openRead: open(# do...;inner;...

#);openWrite: open(# do

...;inner;...

#)#)

HO

PL –

III 2007

Specialization of behaviour III

iterators

Set:(# ...

forAll: (# do //for each element in the set

inner#);

#)

mySet: @Set;

mySet.forall(# do // something #)

HO

PL –

III 2007

BETA as a modeling language

Developed into a conceptual framework for object oriented programming and modeling

HO

PL –

III 2007

Paradigmes/perspectives

Procedural/imperative Programming– A program execution is regarded as a sequence of operations

manipulating dataFunctional Programming– A program is regarded as a mathematical function

Constraint-Oriented/Declarative (Logic) Programming– A program is regarded as a set of equations describing relations

Object-Oriented Programming– A program execution is regarded as a physical model simulating a real or

imaginary part of the world

HO

PL –

III 2007

Physical Modeling

Modeling approach – is based upon the conception of the application domain in terms of

phenomena and concepts.A physical model – consists of elements (physical material) that represent

phenomena and concepts from the application domain.

HO

PL –

III 2007

Material

Paper, plastic , wood, Lego bricks, etc. are examples of (physical) material used to construct (physical) modelsObjects are the computerized material used to construct computer based physical models

HO

PL –

III 2007

Aspects of phenomena

SubstanceMeasurable properties of substanceTransformations on substance

HO

PL –

III 2007

Substance

Characterized by identity, volume and a unique location in time and space

HO

PL –

III 2007

Measurable properties of substance

Properties of substance can be measured The results of measurements can be compared and

described by values of types

HO

PL –

III 2007

Transformations on substance

Partial ordered sequence of actions, changing the measurable properties of some substance

HO

PL –

III 2007

... or changing the state of other substance

HO

PL –

III 2007

Aspects of concepts

Designation– The names by which the concept is known

Intension– Properties that characterize the phenomena in the extension of the

conceptExtension

– The phenomena covered by the concept

General and specialized concepts

HO

PL –

III 2007

Object Orientation as Physical Modelling

Phenomena represented by objects.Measurable properties represented by states of objects.Transformations of state represented by action sequences performed by objects.Concepts represented by classesthat define the common properties of categories of objects, and classes are organized in concept hierarchies.

HO

PL –

III 2007

Norwegian Train Example

HO

PL –

III 2007

Carriage no. 16 Carriage no. 17

HO

PL –

III 2007

Some implications

All actions associated with objects– Methods– Object actions

No static methods or variablesNo ’main’ program – just an outermost objectPart-objects (and not only references)Getting the value of a variable (object) involves executionA class represents a concept, and thereby not a set (non-static again)Subpattern to represent a specialized concept– All properties inherited, including behaviour– Extension instead of redefinition

(name, structure, behavior) compatible– Covariance, implying run time type checks

HO

PL –

III 2007

Why not multiple inheritance?

We didn’t make itMany technical solutions around, but none that satisfied the modeling approach– Independendent, multiple classifications (no order between the

superclasses)– Specialization of behaviour

Had a solution to the multiple code inheritance: part objects

HO

PL –

III 2007

Addressable:(# street: @StreetName;

...printLabel:< (#...#);sendMail:< (#...#)

#)

Taxable:(# income: @integer;

...makeTaxReturn:<(#...#);pay:< (# do...#)

#)

Person: (# name: @PersonName;

myAddr: @Addressable;myTaxable: @Taxable;

do...;myAddr.printLabel;...;myTaxable.pay;...

#)

HO

PL –

III 2007

Addressable:(# street: @StreetName;

...printLabel:< (#...#);sendMail:< (#...#)

#)

Taxable:(# income: @integer;

...makeTaxReturn:<(#...#);pay:< (# do...#)

#)

Person: (# name: @ PersonName;

myAddr: @ Addressable(# printLabel::<

(# do ...;name.print;...#);sendMail::< (#...#)

#);myTaxable:@ Taxable(# makeTaxReturn::< (#...#);

pay::< (#...#)#);

do...;myAddr.printLabel;...;myTaxable.pay;...

#)

HO

PL –

III 2007

Why not interfaces

Interfaces were not invented yet – and we did notHowever, references to part objects, combined with location of part objects, were implementedPerson

Addressable

Company Person

Addressable Addressableloc

anAddress.loc.name

HO

PL –

III 2007

Why not modules

Fragment systemFragment: any sentential from from any non-terminal of the grammar

Stack:(# Private: @ <<SLOT private: ObjectDescriptor>>;

Push: (# e: ˆText enter e[] <<SLOT Push: DoPart>> #);Pop: (# e: ˆText <<SLOT Pop: DoPart>> exit e[] #);New: (# <<SLOT New: DoPart>> #);isEmpty:(# Result: @boolean

<<SLOT isEmpty: DoPart>>exit Result#)

#)

HO

PL –

III 2007

private: ObjectDescriptor(# A: [100] ˆText; Top : @integer #)

Push: DoPartdo private.top+1->private.top;e[]->private.A[private.top][]

Pop: DoPartdo private.A[private.top][]->e[];private.top-1->private.top

new: DoPartdo 0->private.top

isEmpty: DoPartdo (0 = private.Top)->result

HO

PL –

III 2007

Implementations

1983: first BETA compiler in SIMULA. Interpreter in Pascal.1985: ported to a SUN workstation, Motorola 680201986: The Mjølner Project– 1987 Knut Barra from the NCC wrote the first garbage collector for BETA,

and a full workable implementation of BETA was available.– SUN compiler ported to Macintosh, Apollo and HP workstations.– Programming Environment for BETA

meta-programming system Yggdrasilintegrated text- and syntax-directed editor called Sif, debugger called Valhalla, a case tool called Freja supporting a graphical syntax for BETA

1995: Train garbage collector algorithm by Seligmann and Grarup2003: Ported to JVM/CLR2006: Ported to a Smalltalk based VM for pervasive computing– VM supports directly coroutines

HO

PL –

III 2007

Impact - research

Object-Oriented Type-Systems– Palsberg and Schwartzbach -John Wiley & Sons, 1994

A Statically Safe Alternative to Virtual Types– Bruce, Odersky, and Wadler - ECOOP'98

How to preserve the benefits of design patterns – Agerbo and Cornils - OOPSLA'98

Unifying Genericity - Combining the Benefits of Virtual Types and Parameterized Classes – Thorup and Torgersen -ECOOP'99

Conquering Aspects with Caesar– Mezini and Ostermann - AOSD'03, 2003

Super and Inner — Together at Last!– Goldberg, Findler, Flatt - OOPSLA 2004

HO

PL –

III 2007

An Executable Semantic Definition of the Beta Language using Rewriting Logic – Mark Hills, T. Baris Aktemur and Grigore Rosu, Technical report

UIUCDCS-R-2005-2650, November 2005 A Virtual Class Calculus– Ernst, E., Ostermann, K., and Cook, W. R., POPL, 2006

HO

PL –

III 2007

Impact - languages

SDL’92 (from OSDL, Mjølner, SPECS og SCORE)– Processes as objects, process types ans subtypes– Virtual transitions– Constraints on virtual types, and default bindings

Java– two first commercial licenses of the Mjølner BETA System were acquired

by James Gosling and Bill Joy– anonymous classes and nested (inner) classes– Wildcards

Adding Wildcards to the Java Programming Language– Torgersen, Hansen, Ernst, von der Ahé, Bracha, and Gafter - SAC 2004

UML2.0– ?

HO

PL –

III 2007Interesting language, opaque writing, November 26, 2004 Reviewer: wiredweird "wiredweird" (Earth, or somewhere nearby)

BETA is an instructive example in the history of OO programming, but never really took off.

The language does contain a few worthwhile ideas. In languages like Java or C++, subclass methods can over-ride superclass methods, and optionally dispatch to the superclass. In BETA, the "inner" form of dispatch means that the superclass always controls the caller's interface, and optionally dispatches to the subclass. That's very attractive when the superclass doesn't necessarily trust subclass over-rides to maintain important invariants. BETA also goes a big step beyond the getX/setX methods that commonly export attributes. In BETA, the same syntax is used for assignment to variables as for methods calls. You can't tell the difference, by looking at the caller, whether you're looking at a reference to an attribute or to an accessormethod. Although odd in other respects, that's one case where the assignment/call unification can solve some problems. Constructs for parallel programming a strength, but exception handling is a weakness and the <<SLOT>> interface definitions go beyond just weak. Scoping for programming in the large is mostly in the writers' imaginations.

The language uses peculiar syntax. The least of the problems is that the "left hand side" of an assignment is on the right, and that many syntactic markers rival C trigraphs for ugliness. The Danish authors generally use very good English, but often choose inexplicable terms (like "pattern") for familiar notions (like C++ "class"). As noted elsewhere, this is the only BETA book around, so there's really nothing to compare it to.

I'm not aware of any current use of BETA, so this book is of historical interest only. It's instructive as a bad example in choosing syntax for a programming language, but also as a good example for some of its creative semantics. I look forward to seeing some of those good ideas enter the main stream.

//wiredweird