History of Programming Languages Conference (HOPL-III)

ƒ 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 professor
ƒ 1975: Svejgaard proposes to make a new language based upon the ideas of Simula and Pascal
ƒ 1976: 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

ƒ From SIMULA I language report (1965): “The two main objectives of the SIMULA language are:
– To provide a language for a precise and standardised description 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”.”

ƒ 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 concurrent programming based on the coroutine mechanism of SIMULA.
ƒ BETA should have an efficient implementation.

ƒ 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?

ƒ 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

ƒ Record types – records with fields
ƒ Value types – often only predefined, assignment
ƒ Procedures / functions – parameters/result
ƒ Classes -
ƒ Modules – alternatives to classes or collections of classes
ƒ Process types - concurrency

object descriptor
P: superP
(# A1; A2; ... ; An
// pattern name
// super pattern
// attributes enter (V1, V2, ... ,Vs) // input parameters do I1; I2; ... ; Im // imperatives exit (R1, R2, ... , Rt) // output parameters
#)
ƒ but

ƒ Kinds
– Component ( | ): alternating/concurrent action seq.
– Item ( ):
ƒ Construction modes part of an action sequence (stack)
– Static ( @ ): part of a containing object i:@Integer
– Dynamic ( ^ ): separate objects next: ^Link
– Inserted ( ): ’inline’ execution
ƒ Object generation, object reference and object execution
– Generation ( & ) &C
– Object as such ( [] ) &C[] -> rC[]
– Execution of object ( ; , -> )
ƒ How defined x -> rC -> <i,j>
– by means of a pattern (pattern-defined) P
– by means of an object descriptor (singular) P(# #)

ƒ Records
Customer:
(# name: @Text; addr: @Address
#)
ƒ Class
Account:
(# owner: ^Customer; balance: @Amount deposit:
(# a: @Amount enter a
#) do a+balance -> balance
#)
ƒ Function evalInterest:
(# sum, result: @Amount; rate: @ Interest enter (sum,rate) do ... -> result exit result
#)
#)

alternating components
partial actions items

action sequences partial alternating concurrent
Implicit Explicit non
synchronized synchronized items – stack organization components each with a stack of items

ƒ Virtual class patterns with redefinition did not work
Set:
(# ElmType:< (# key: @integer #); newElement:
(# S: ^ ElmType; do &ElmType [] -> S[]; newKey -> S.key;
#)
#);
PersonSet: Set(# ElmType::< (# name: @Text #) #)
ƒ But this did
PersonSet: Set
(# ElmType::< Set.ElmType(# name: @Text #) #)

ƒ Virtual method patterns
Person:
(# name: @text; display:<
(# do name[] -> out.puttext; inner #)
#)
Employee: Person
(# salary: @integer; display::< (# do salary -> out.putint #)
#)

Set:
(# ElmType:< object; insert:<
(# x: ^object
Enter x[] do x[] -> add
#)
#)
PersonSet: Set (# ElmType::< Person # )
StudentSet: PersonSet(# ElmType::< Student #)

ƒ Control structures cycle: (# do inner; restart cycle #)
L: cycle(# do (if F.eos then (* end-of-stream *) leave L if);
F.get -> G.put
#);

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

ƒ iterators
Set:
(# ...
forAll:
(# do //for each element in the set
#); inner
#) mySet: @Set; mySet.forall(# do // something #)

ƒ Developed into a conceptual framework for object oriented programming and modeling

ƒ Procedural/imperative Programming
– A program execution is regarded as a sequence of operations manipulating data
ƒ Functional 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

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

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

ƒ Substance
ƒ Measurable properties of substance
ƒ Transformations on substance

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

ƒ Properties of substance can be measured
ƒ The results of measurements can be compared and described by values of types

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

ƒ Designation
– The names by which the concept is known
ƒ Intension
– Properties that characterize the phenomena in the extension of the concept
ƒ Extension
– The phenomena covered by the concept
ƒ General and specialized concepts

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

ƒ All actions associated with objects
– Methods
– Object actions
ƒ No static methods or variables
ƒ No ’main’ program – just an outermost object
ƒ Part-objects (and not only references)
ƒ Getting the value of a variable (object) involves execution
ƒ A 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

ƒ We didn’t make it
ƒ Many 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

Addressable:
(# street: @StreetName;
#)
...
printLabel:< (#...#); sendMail:< (#...#)
Taxable:
(# income: @integer;
...
makeTaxReturn:<(#...#); pay:< (# do...#)
#)
Person:
(# name: @PersonName; myAddr: @Addressable; myTaxable: @Taxable; do
...; myAddr.printLabel;
...; myTaxable.pay;
...
#)

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;
...
#)

ƒ Interfaces were not invented yet – and we did not
ƒ However, references to part objects, combined with location of part objects, were implemented
Person Company
Person
Addressable Addressable loc
Addressable anAddress.loc.name

ƒ Fragment system
ƒ Fragment: 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
#)
#)

private: ObjectDescriptor
(# A: [100] ˆText; Top : @integer #)
Push: DoPart do private.top+1->private.top; e[]->private.A[private.top][]
Pop: DoPart do private.A[private.top][]->e[]; private.top-1->private.top
new: DoPart do 0->private.top
isEmpty: DoPart do (0 = private.Top)->result

ƒ 1983: first BETA compiler in SIMULA. Interpreter in Pascal.
ƒ 1985: ported to a SUN workstation, Motorola 68020
ƒ 1986: 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 Yggdrasil
ƒ integrated 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 Grarup
ƒ 2003: Ported to JVM/CLR
ƒ 2006: Ported to a Smalltalk based VM for pervasive computing
– VM supports directly coroutines

ƒ 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

ƒ 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

ƒ 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
– ?

Interesting 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 accessor method. 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