“Package 0”: The Basics

1. “Package 0”: The Basics Evergreen World, or its Conceptual Model Objects naming finalVarName spec Values //store= & ; store theirStates Its syntax (what’s on the surface) spec /store = & ; store varName indexed by state indexed by state & (address) memLoc(ation) store store typevar typeloc UVal(ue) typeval Type Its semantics (what’s inside) Run-time State • Legend: • static mappings are black, • dynamic mappings are green, • constraints are red; • derived items are dashed (and of lighter color) • semi-colon _ ; _ denotes mapping composition Computer

2. Structure of FM via packages Pckg 1.1: Making locations values (storing values in values) Pckg 1.2: Pointers and References uses • Comments • Each pckg is a collection of sets and mappings between them • The contents of the two left pckgs is derived, that is, their sets and mappings can be derived from those in the right pckgs by applying some standard set-theoretical operations specialization /specialization Pckg 2.1: Records Structures and Their Storage /Pckg 2.2: Pointers and References to Record Structures uses

3. The pckg to be built now: Pckg 1.1: Making locations values (storing values in values) Pckg 1.2: Pointers and References uses /specialization specialization /Pckg 2.2: Pointers and References to Record Structures Pckg 2.1: Records Structures and Their Storage uses

4. Package 1.1: making location values //store= & ; store finalVarName VarName l-value l-value  • Color and shape legend: • rectangles are sets and arrows are mappings between them; hook-tail arrows are inclusions • static mappings are black, • dynamic mappings are green, • constraints are red; • derived items are dashed (and of lighter color) • Notational conventions: • semi-colon _ ; _ denotes mapping composition, • all diagrams besides those marked with the puncture symbol {} are considered commutative (that is, constrained) by default; • line segment between rectangles denotes a pair of mutually inverse mappings (borrowed from UML) 1 ! /store= & ; store & Relation to BM (TUM Basic Model): For each type T in set Type we have three sets: • typeval-1(T) -- CAR T in BM, • typeloc-1(T) -- CAR Var T in BM, • typevar-1(T) -- ???, maybe, CAR RefT ? This assumption matches remark 2 in sect.2.6 about pointers (see below). Or, maybe (Juergen’s conjecture), CAR Ref T is something from the World? /Store r-value r-value 1 loc val typevar store  1 UVal* UVal loc val {}  typeloc typeval typeval 1 Type* Type add* rem* 1 1 {} 1

5. The pckg to be built now: Pckg 1.1: Making locations values (storing values in values) Pckg 1.2: Pointers and References uses

6. Package 1.2: Pointers and references as constructs over Pckg 1.1 C++ stuff about data store is formalized (note three “swim” lines in the formalities landscape) empty syntax for deref Final Var*Name (references) Var*Name (pointers) VarName typevar l-value  ! /store= & ; store *_= &;store (deref in C++) & & & /Store* /Store r-value 1 refLoc ref loc val store* store UFinalVal** UVal** UVal* UVal refLoc ref loc val {} {} type type*loc typeloc type type Type** Type* Type add* rem* add* rem* {} {}

7. The pckg to be built now: Pckg 1.1: Making locations values (storing values in values) Pckg 1.2: Pointers and References uses specialization Pckg 2.1: Records Structures and Their Storage

8. Package 2.1: How to store tuples (record structures)? (specialization of pckg 1.1 for record values and their storage) hypothetic CAR Ref Reci(T*i) still to be found UVal* UVal store loc val This is BM’s set CAR R(C) = CAR Reci (VarTi) where they map oids Oids reside here (location for record values) deref This is BM’s set CAR V(C) //f CAR Reci(T*i) ///storeRec storeRec CAR Reci(Ti) CAR(ReciTi)* //[a]*=/[a1]*… /[an]* /f= f1…fn by definition of CAR Rec by definition of CAR Rec /[ai]* /[ai*] fi(pointer arithmetic, say, +1+..+1 for i-times) /[ai]   /[ai]*= fi;store(Ti) i CAR(T*i) [ai*] store(Ti) [ai] i CAR(Ti) CARTi CAR(T*i) by definition of by definition of restriction of store by the universal property of  by the universal property of  RecordType (RecordType)* Record(Type*) add* rem* Type

9. The pckg to be built now Pckg 1.1: Making locations values (storing values in values) Pckg 1.2: Pointers and References uses /specialization specialization /Pckg 2.2: Pointers and References to Record Structures Pckg 2.1: Records Structures and Their Storage uses

10. Package 2.2: Pointers and references to record values CAR V*(C) Pls note that Nulls reside here *_ class Cla {T1 a1, …, Tn an} Cla C=new Cla(v1,…,vn) finalVar*Name Var*Name & & *_= &;store (deref in C++) CAR Ref R(C)? CAR V(C) storeRec store*Rec CARReciTi CAR(ReciTi)* CAR (ReciTi)** F** loc val loc ref [ai]* //f /[ai] *_ fi *_ *_(deref) CAR T*i CAR Reci(T*i) CAR Ti • Color Legend: • blue names denote implementation-dependant items; • red names mean dependence on recursive record types isomorphisms (solving equations); • black arrows are static • green arrows are dynamic • derived items are dashed CAR R(C) /[ai*] storei add* add* (RecordType)** (RecordType)* RecordType No a-priori relship – via implementation only formRec Record(Type*) SeqOfTypes seq SeqOf(Types*) addSeqOf* formRec Type

11. Comparative table of terminology !)colors mark terminological conflicts: red for using term “variable” and pink for “reference” !!) if the correspondence in column 1b is true, then the correspondence in column 1a should be also true ?