Concepts And Semantics Of Programming Languages

2 Modular And Objectoriented Constructs With

Ocaml Python C Ada And Java 1st Edition Therese
Hardin download
https://ebookbell.com/product/concepts-and-semantics-of-
programming-languages-2-modular-and-objectoriented-constructs-
with-ocaml-python-c-ada-and-java-1st-edition-therese-
hardin-34071910

Explore and download more ebooks at ebookbell.com

Here are some recommended products that we believe you will be
interested in. You can click the link to download.

Concepts And Semantics Of Programming Languages 1 A Semantical

Approach With Ocaml And Python Therese Hardin Mathieu Jaume Francois
Pessaux Veronique Viguie Donzeaugouge

https://ebookbell.com/product/concepts-and-semantics-of-programming-
languages-1-a-semantical-approach-with-ocaml-and-python-therese-
hardin-mathieu-jaume-francois-pessaux-veronique-viguie-
donzeaugouge-30221364

Semantics And Morphosyntactic Variation Qualities And The Grammar Of

Property Concepts 1st Edition Francez

https://ebookbell.com/product/semantics-and-morphosyntactic-variation-
qualities-and-the-grammar-of-property-concepts-1st-edition-
francez-5846038

Formal Theories Of Information From Shannon To Semantic Information

Theory And General Concepts Of Information Lecture Notes In Computer
Science 5363 2009th Edition Giovanni Sommaruga

https://ebookbell.com/product/formal-theories-of-information-from-
shannon-to-semantic-information-theory-and-general-concepts-of-
information-lecture-notes-in-computer-science-5363-2009th-edition-
giovanni-sommaruga-55201864

Thoughtcontents On The Ontology Of Belief And The Semantics Of Belief

Attribution 1st Edition Steven E Bor Auth

https://ebookbell.com/product/thoughtcontents-on-the-ontology-of-
belief-and-the-semantics-of-belief-attribution-1st-edition-steven-e-
bor-auth-4388536
The Semantics Of Word Division In Northwest Semitic Writing Systems
Ugaritic Phoenician Hebrew Moabite And Greek Contexts Of And Relations
Between Early Writing Systems Crews Robert Sd Crellin

https://ebookbell.com/product/the-semantics-of-word-division-in-
northwest-semitic-writing-systems-ugaritic-phoenician-hebrew-moabite-
and-greek-contexts-of-and-relations-between-early-writing-systems-
crews-robert-sd-crellin-46462522

Semiotics As A Tool For Learning Mathematics How To Describe The

Construction Visualisation And Communication Of Mathematical Concepts
Adalira Senzludlow

https://ebookbell.com/product/semiotics-as-a-tool-for-learning-
mathematics-how-to-describe-the-construction-visualisation-and-
communication-of-mathematical-concepts-adalira-senzludlow-5359070

Asymmetrical Concepts After Reinhart Koselleck Historical Semantics

And Beyond 1 Aufl Kay Junge Editor Kirill Postoutenko Editor

https://ebookbell.com/product/asymmetrical-concepts-after-reinhart-
koselleck-historical-semantics-and-beyond-1-aufl-kay-junge-editor-
kirill-postoutenko-editor-51799306

Instruments And Related Concepts At The Syntaxsemantics Interface Koen

Van Hooste

https://ebookbell.com/product/instruments-and-related-concepts-at-the-
syntaxsemantics-interface-koen-van-hooste-51024446

Concepts Frames And Cascades In Semantics Cognition And Ontology 7

Language Cognition And Mind 7 1st Ed 2021 Sebastian Lbner Editor

https://ebookbell.com/product/concepts-frames-and-cascades-in-
semantics-cognition-and-ontology-7-language-cognition-and-mind-7-1st-
ed-2021-sebastian-lbner-editor-35356904
Concepts and Semantics of Programming Languages 2
 Series Editor
Jean-Charles Pomerol

Concepts and Semantics of

Programming Languages 2

Modular and Object-oriented Constructs

with OCaml, Python, C++, Ada and Java

Thérèse Hardin
Mathieu Jaume
François Pessaux
Véronique Viguié Donzeau-Gouge
First published 2021 in Great Britain and the United States by ISTE Ltd and John Wiley & Sons, Inc.

Apart from any fair dealing for the purposes of research or private study, or criticism or review, as
permitted under the Copyright, Designs and Patents Act 1988, this publication may only be reproduced,
stored or transmitted, in any form or by any means, with the prior permission in writing of the publishers,
or in the case of reprographic reproduction in accordance with the terms and licenses issued by the
CLA. Enquiries concerning reproduction outside these terms should be sent to the publishers at the
undermentioned address:

ISTE Ltd John Wiley & Sons, Inc.

27-37 St George’s Road 111 River Street
London SW19 4EU Hoboken, NJ 07030
UK USA

www.iste.co.uk www.wiley.com

© ISTE Ltd 2021

The rights of Thérèse Hardin, Mathieu Jaume, François Pessaux and Véronique Viguié Donzeau-Gouge
to be identified as the authors of this work have been asserted by them in accordance with the Copyright,
Designs and Patents Act 1988.

Library of Congress Control Number: 2021935827

British Library Cataloguing-in-Publication Data

A CIP record for this book is available from the British Library
ISBN 978-1-78630-602-9
 Contents

Foreword . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ix

Preface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xi

Chapter 1. Namespaces: Model and Operations . . . . . . . . . . . . . 1

1.1. Reusing, dividing, confining . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1.1. Analysis of some developer needs . . . . . . . . . . . . . . . . . . . 2
1.1.2. Meeting developer needs . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2. Namespaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.2.1. Namespaces definition . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.2.2. Extending notions of environment and binding . . . . . . . . . . . . 8
1.3. kit development . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
1.3.1. Namespace of a kit . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
1.3.2. Order of fields introduction . . . . . . . . . . . . . . . . . . . . . . . 15
1.3.3. Typing kits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
1.3.4. kit values . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
1.3.5. kit export, confining fields . . . . . . . . . . . . . . . . . . . . . . . 22
1.3.6. kits import . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
1.3.7. Stages of kit development . . . . . . . . . . . . . . . . . . . . . . . . 32
1.4. Incomplete kits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
1.4.1. Type and value of an incomplete kit . . . . . . . . . . . . . . . . . . 34
1.4.2. Completion of an incomplete kit . . . . . . . . . . . . . . . . . . . . 34
1.4.3. Confining an incomplete kit . . . . . . . . . . . . . . . . . . . . . . 36
1.5. Parameterized kits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
1.5.1. kits parameterized by a type . . . . . . . . . . . . . . . . . . . . . . 36
1.5.2. kits parameterized by types and values . . . . . . . . . . . . . . . . 41
1.5.3. Confinement, parametrization, incomplete kits and export . . . . . 45
1.6. Functors of kits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
1.7. kit extension . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
vi Concepts and Semantics of Programming Languages 2

1.7.1. Presentation of extension . . . . . . . . . . . . . . . . . . . . . . . . 49

1.7.2. Confinement and extension . . . . . . . . . . . . . . . . . . . . . . . 55
1.8. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59

Chapter 2. Modules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
2.1. Modules in Ada . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
2.1.1. Developing modules . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
2.1.2. Export and confinement . . . . . . . . . . . . . . . . . . . . . . . . . 65
2.1.3. Nesting modules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
2.1.4. Importing a module . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
2.1.5. Flattening an import . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
2.1.6. Generic modules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
2.1.7. Modules and separate compilation . . . . . . . . . . . . . . . . . . . 71
2.2. Modules in OCaml . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
2.2.1. Module definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
2.2.2. Export and confinement . . . . . . . . . . . . . . . . . . . . . . . . . 73
2.2.3. Confinement of type definitions . . . . . . . . . . . . . . . . . . . . 78
2.2.4. Functors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
2.3. Modularity, namespaces and W-kit . . . . . . . . . . . . . . . . . . . . . 85
2.3.1. Declaration interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . 85
2.3.2. W-kits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
2.3.3. Modularity and header files in C . . . . . . . . . . . . . . . . . . . . 86

Chapter 3. Class and Object Features . . . . . . . . . . . . . . . . . . . . 93

3.1. Object-oriented features . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
3.1.1. Objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94
3.1.2. Classes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
3.2. kits and object features . . . . . . . . . . . . . . . . . . . . . . . . . . . 104
3.2.1. Modeling classes . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104
3.2.2. Modeling objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107
3.2.3. Inheritance, redefinition and late binding . . . . . . . . . . . . . . . 109
3.2.4. Incomplete C-kits, parameterized C-kits . . . . . . . . . . . . . . . 113
3.2.5. Subclassing, subtyping . . . . . . . . . . . . . . . . . . . . . . . . . 115
3.2.6. Type languages, classes and objects . . . . . . . . . . . . . . . . . . 119

Chapter 4. Classes in Selected Languages . . . . . . . . . . . . . . . . 123

4.1. Classes in Java . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123
4.1.1. General presentation . . . . . . . . . . . . . . . . . . . . . . . . . . 123
4.1.2. Modules and packages . . . . . . . . . . . . . . . . . . . . . . . . . 124
4.1.3. Classes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125
4.1.4. Marks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131
4.1.5. Developing classes . . . . . . . . . . . . . . . . . . . . . . . . . . . 134
 Contents vii

4.2. Classes in C++ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144

4.2.1. Header files, namespaces, confinement . . . . . . . . . . . . . . . . 145
4.2.2. Classes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 148
4.2.3. Inheritance and confinement . . . . . . . . . . . . . . . . . . . . . . 155
4.2.4. Overloading in C++ . . . . . . . . . . . . . . . . . . . . . . . . . . . 165
4.2.5. Parameterized classes . . . . . . . . . . . . . . . . . . . . . . . . . . 168
4.3. Classes in OCaml . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174
4.3.1. Presentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174
4.3.2. An overview of classes . . . . . . . . . . . . . . . . . . . . . . . . . 174
4.3.3. Marks, incomplete classes, parametrization . . . . . . . . . . . . . . 181
4.3.4. Objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 186
4.3.5. Class signatures: confinement and inheritance . . . . . . . . . . . . 192
4.3.6. Multiple inheritance . . . . . . . . . . . . . . . . . . . . . . . . . . . 195
4.3.7. Other features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 197
4.4. Presentation of Python . . . . . . . . . . . . . . . . . . . . . . . . . . . 197
4.4.1. Getting started . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 198
4.4.2. An overview of classes, modules and types . . . . . . . . . . . . . . 199
4.4.3. Names and assignment . . . . . . . . . . . . . . . . . . . . . . . . . 208
4.4.4. Assignment and typechecking . . . . . . . . . . . . . . . . . . . . . 211
4.4.5. Overloading . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 213
4.4.6. Modules and packages . . . . . . . . . . . . . . . . . . . . . . . . . 217
4.4.7. Confinement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 218
4.4.8. Inheritance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 219
4.4.9. Incomplete C-kits and abstract classes . . . . . . . . . . . . . . . . . 221
4.4.10. Other features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 222

Appendix: Questions to Guide Learning . . . . . . . . . . . . . . . . . . 225

List of Notations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 229

References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 231

Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 233
 Foreword

Computer programs have played an increasingly central role in our lives since the
1940s, and the quality of these programs has thus become a crucial question. Writing
a high-quality program – a program that performs the required task and is efficient,
robust, easy to modify, easy to extend, etc. – is an intellectually challenging task,
requiring the use of rigorous development methods. First and foremost, however, the
creation of such a program is dependent on an in-depth knowledge of the
programming language used, its syntax and, crucially, its semantics, i.e. what
happens when a program is executed.

The description of this semantics puts the most fundamental concepts into light,
including those of value, reference, exception or object. These concepts are the
foundations of programming language theory. Mastering these concepts is what sets
experienced programmers apart from beginners. Certain concepts – like that of value
– are common to all programming languages; others – such as the notion of functions
– operate differently in different languages; finally, other concepts – such as that of
objects – only exist in certain languages. Computer scientists often refer to
“programming paradigms” to consider sets of concepts shared by a family of
languages, which imply a certain programming style: imperative, functional,
object-oriented, logical, concurrent, etc. Nevertheless, an understanding of the
concepts themselves is essential, as several paradigms may be interwoven within the
same language.

Introductory texts on programming in any given language are not difficult to find,
and a number of published books address the fundamental concepts of language
semantics. Much rarer are those, like the present volume, which establish and
examine the links between concepts and their implementation in languages used by
programmers on a daily basis, such as C, C++, Ada, Java, OCaml and Python. The
authors provide a wealth of examples in these languages, illustrating and giving life
to the notions that they present. They propose general models, such as the kit
x Concepts and Semantics of Programming Languages 2

presented in Volume 2, permitting a unified view of different notions; this makes it

easier for readers to understand the constructs used in popular programming
languages and facilitates comparison. This thorough and detailed work provides
readers with an understanding of these notions and, above all, an understanding of
the ways of using the latter to create high-quality programs, building a safer and
more reliable future in computing.

Gilles D OWEK
Research Director, Inria
Professor at the École normale supérieure, Paris-Saclay

Catherine D UBOIS
Professor at the École nationale supérieure
d’informatique pour l’industrie et l’entreprise
January 2021
 Preface

This two-volume work relates to the field of programming. First and foremost, it
is intended to give readers a solid grounding in the bases of functional or imperative
programming, along with a thorough knowledge of the module and class mechanisms
involved. In our view, the semantics approach is most appropriate when studying
programming, as the impact of interlanguage syntax differences is limited. Practical
considerations, determined by the material characteristics of computers and/or
“smart” devices, will also be addressed. The same approach will be taken in both
volumes, using both mathematical formulas and memory state diagrams. With this
book, we hope to help readers understand the meaning of the constructs described in
the reference manuals of programming languages and to establish solid foundations
for reasoning and assessing the correctness of their own programs through critical
review. In short, our aim is to facilitate the development of safe and reliable software
programs.

Volume 1 presented a broad overview of the functional and imperative features of

programming, from notions that can be modeled mathematically to notions that are
linked to the hardware configuration of computers themselves.

Volume 2 is dedicated to the study of language features (modules, classes,

objects) that are known to ease the development of software systems. It builds on the
foundations laid down in Volume 1 since modules, classes and objects are, in
essence, the means of organizing functional or imperative constructs.

Chapter 1 first analyzes some of the needs of developers in terms of tools for
building large software. Based on these requirements, an original semantic model is
drawn up, jointly presenting all of the features of modules and classes that can meet
these needs. We introduce our own structure, a kit, to describe this model, a word
chosen to avoid any confusion with the usual denominations (structure, module,
package, class, etc.) used by languages. These kits serve to explain naming
xii Concepts and Semantics of Programming Languages 2

management, export and import mechanisms, access restrictions, extension and

parametrization (genericity, functors), subtyping and subclassing. In contrast to the
mathematical study of semantics of functional and imperative features, the semantics
of these kits remains rather informal, as research has not yet led to a relatively simple
mathematical model. In this chapter, we have therefore prioritized intuition and
simplicity, which inevitably leads to approximations and a lack of rigor, to some
degree. Chapter 1 also proposes a set of questions to guide the acquisition of a
language, with some answers given in the subsequent chapters. Chapter 2 first
presents an implementation of kits with the modules of Ada and then a richer
implementation of kits with the modules of OCaml. It ends with a much more
succinct implementation of kits, referred to as weak kits, using the header files and
the mechanisms of import–export of C. Chapter 3 takes up the kit model to handle
classes and objects and their tools, for example inheritance, late binding and
subclassing. This model is exemplified in Chapter 4, which presents the classes of
Java, C++, OCaml and Python from a unified perspective.

This work is aimed at a relatively wide audience, from experienced developers –

who will find valuable additional information on language semantics – to beginners
who have only written short programs. For beginners, we recommend working on the
semantic concepts described in Volume 1 using the implementations in OCaml or
Python to ease assimilation. All readers may benefit from studying the reference
manual of a programming language, while comparing the presentations of constructs
given in the manual with those given here, guided by the questions mentioned in
Volume 2.

Note that we do not discuss the algorithmic aspect of data processing here.
However, choosing the algorithm and the data representation that fit the requirements
of the specification is an essential step in program development. Many excellent
works have been published on this subject, and we encourage readers to explore the
subject further. We also recommend using the standard libraries provided by the
chosen programming language. These libraries include tried and tested
implementations for many different algorithms, which may generally be assumed to
be correct.
 1

Namespaces: Model and Operations

Most programming languages currently in use offer tools to facilitate the

construction and maintenance of large software. Two approaches coexist, that of
languages with modules and that of object-oriented languages; approaches that are
different or even historically opposed but which in fact share many characteristics.
This is why this chapter elaborates on a unique model of these two approaches by
introducing a structure, referred to here as kit, as well as operations on these kits. We
have chosen to introduce our own vocabulary for this study as programming
languages sometimes use the same words to designate tools whose meanings differ
significantly. The notion of a kit will be progressively enriched during its
presentation. It will serve as a common framework to reflect the division of software
into sub-systems, to explain management of names, export and import mechanisms,
different possibilities of restricting access to elements of these kits, and extension
mechanisms. Modules, classes and objects will be presented using this framework in
the following chapters.

This chapter introduces a large number of notions which may seem difficult. It can
be read in two passes. The first pass will give the reader an overview of the contents
and may be followed by reading at least one of Chapters 2 or 3. This can be seen as a
real exercise if, at the same time, the reader illustrates the notions with a few examples
in the language they use. The second pass will then be an opportunity for the reader to
deepen their understanding of these concepts.

At the end of each section, we pose a few questions that the reader can ask
themselves when reading the reference manual of their favorite programming
language. We call this language M Y L in the statement of the questions. Chapters 2
and 3 will provide some examples of answers to these questions.

Concepts and Semantics of Programming Languages 2: Modular and Object-oriented Constructs

with OCaml, Python, C++, Ada and Java,
First Edition. Thérèse Hardin, Mathieu Jaume, François Pessaux and Véronique Viguié Donzeau-Gouge.
© ISTE Ltd 2021. Published by ISTE Ltd and John Wiley & Sons, Inc.
2 Concepts and Semantics of Programming Languages 2

1.1. Reusing, dividing, confining

1.1.1. Analysis of some developer needs

We hope the contents of Volume 1 – at least in part – met the developer’s need
to produce programs that conformed to their specifications and that did not contain
programming errors. The study of typing, execution semantics and the presentation of
tools, such as constructed types and pattern matching, exceptions, etc., provided them
with some responses. Developing a software system at a certain scale additionally
requires that the programming languages used be able to satisfy some other developer
needs; globally, these can be described by the words “reuse”, “divide”, “confine”.

1.1.1.1. Reusing
Reusing parts of a software system is perhaps the developer’s primary need. This
reduces the cost and time for development, debugging and software maintenance (bug
correction, performance improvement, etc.). Functions and procedures provide a first
response to this need; but they are not suitable for reusing whole sections of code, if
possible in a compiler-controlled manner.

1.1.1.2. Dividing
If a software specification is large enough, it is best to divide it into relatively
independent parts, the communications between them being precisely stated and, if
possible, automatically controlled. Today’s programming languages provide tools to
reflect this division of the specification into components, which can be separately
developed then assembled to achieve a consistent software satisfying the
specification. Very schematically, it is possible to split a specification by being
guided by the nature of the data to be manipulated or by the actions to be performed.
The first choice is that which is said to have led to the notions of class and object.
The second would have rather led to the notion of module and then to the notion of
functor. In the object-oriented framework, a data is usually strongly linked to the set
of tools dedicated to its manipulation. In the modular framework, a data has an
independent existence, without direct links to the tools that handle it, other than the
typing ones. These two approaches are reminiscent of the notion of abstract type,
introduced early on in both semantics and programming. In programming, an abstract
type is a syntactic structure grouping together a data type and its manipulation tools.
The theory of Abstract Data Types (ADT) gives a formal model of these structures; it
is briefly presented in Chapter 2.

1.1.1.3. Confining
Maintaining program properties is not always easy, for example if several
developers interact on the same software or, in the case of maintenance, if the
software documentation is imprecise about these properties. We saw in section 6.5.2
of Volume 1 that typing allows us to define data structures respecting some
 Namespaces: Model and Operations 3

invariants: for instance, a binary tree cannot have three branches starting from the
same node. But these structures remain free in the sense that one cannot introduce
restrictions on the values of a type. Some languages do allow such restrictions but
their validity can only be checked at runtime which can lead to unscheduled, and
therefore dangerous, execution aborting. Let us take the following example: how to
encode binary trees in OCaml whose leaves can only be even natural integers. The
following type is naturally defined.

E XAMPLE 1.1.–
OCaml
type even_tree = Node of (even_tree * even_tree) | F of int

The values of type even_tree are binary trees whose leaves are integers: there are
no means of restricting the possible values of leaves to even natural integers in this
type declaration. The developer of this data representation can certainly offer tools
for manipulating these trees which guarantee this invariant. But the user of type
even_tree can build values of this type directly with leaves being odd integers, so
without using the developer’s offered tools. A mechanism is needed to make this type
definition inaccessible – to confine it – and give only the information needed to use
the developer’s tools. The user of this type will be obliged to use only these tools to
manipulate the even_tree values. Therefore the invariant will be respected. The
control, in particular by static typing, done by the compiler can guarantee that this
confinement will not be abused.

1.1.2. Meeting developer needs

Let us analyze some possible answers to divide, confine or reuse program

fragments to identify rigorous and systematic construction methods for the
development of software applications.

1) To help preservation of invariants, a programming language can have a syntactic

structure devoted to grouping together definitions of types, functions, exceptions, etc.,
and to confine some of them by only providing the information necessary for their
use outside this structure. This syntactic structure can even completely prevent the
external use of certain names, making them invisible from the outside. Most languages
offer such structures, named abstract types, modules, classes, packages, objects, etc.
In order to study their common characteristics, maintaining a fairly general point of
view, in this chapter we introduce our own syntactic construct called a kit. It will
appear in the examples with the keyword Kit. In return, readers interested in modules,
classes, etc., of a given language will be able to appropriate their semantics with the
help of this notion of kit. Chapters 2 and 3 will present, respectively, modules, classes
and objects from the kit approach.
4 Concepts and Semantics of Programming Languages 2

The study of reuse leads to two distinct visions of the same functionality: that of its
developer and that of its users. The developer creates a kit with a group of definitions
(of types, expressions, procedures, exceptions, etc.). Thanks to the export mechanism
(presented later), they can confine some of these definitions within the kit or decide to
export them. Thanks to an import mechanism, a user of a definition exported by the kit
can use its name and, according to the functionality of this definition, its parameters,
its type, etc. In their code, the importer denotes an imported definition using a notation
often called dot-notation, constructed with the name of the kit and the name of the
definition.

Distinguishing between the roles of the importing user and the exporting developer
allows us to better state certain questions. What specification needs does the developer
have to satisfy? What are the reusable components for a new development? Is it
possible to modify them? What are the consequences of these modifications for other
uses? In other words, to borrow software engineering terminology, the developer sees
a kit as a “white box” and the user sees it (rather) as a “black box”.

It is essential that the compiler guarantees the consistency between the definitions
in the kit and their export, the non-export of confined entities, the proper use of
the exported definitions by their importers, and, in particular, the absence of any
confinement bypassing. This can be done by the compilation process, making different
so-called static analyses, and at least by typing analyses that extend those seen in
Volume 1.

2) The introduction of such kits may only be allowed within the same program,
which will be compiled into a single block. However, it is possible to go a little further
by rendering these kits more autonomous:
a) The system architecture can be reflected in the software structure by
representing each sub-system by a kit. This will provide the other sub-systems with the
functionalities they need, but only those they need in order to respect the partitioning
between sub-systems. The support for the maintenance of invariants will be facilitated.
b) Depending on languages’ choices, confinement of parts of a kit can be
directly integrated into its definition, or can be introduced after this definition to be
well-tuned to every importer’s needs.
c) The programming language can propose to compile each of these kits
separately, making the object codes of these kits totally autonomous. This makes it
possible to create libraries of object codes, thus facilitating reuse.
d) Confinement facilitates software maintenance. The effects of changing a
definition are circumscribed to the kit introducing it if, however, the guidelines for
using it remain unchanged. If the export is not modified, if the modifications have not
changed the semantics of the definitions, the importer has nothing to modify in their
own code.
 Namespaces: Model and Operations 5

e) The compiler can perform consistency checks at each step of

creation/export/import of these kits, as parts of a complete development.

We begin our list of questions to help and guide learning of a language and the
reading of its reference manual. The first question concerns some characteristics of
the language and those that follow will address points discussed in this chapter. In
the following chapters, during the presentation of a particular language, the simple
mention of (Ans. n) will indicate that elements of the answer have just been given for
question n.

Q UESTION 1.1.– How is the source language under consideration – referred to here
as M Y L – translated into binary code: is it compiled, interpreted or compiled to
bytecode and then interpreted on a virtual machine? Does it offer both a compiler
and an interpreter of the source code? Is M Y L a typed language? Is it strongly typed
(i.e. does every expression have one unique type)? Is it statically typed (typing done
only by the compiler)? If not, does the language offer a notion of a type that prohibits
certain operations or that determines the size of memory allocation?

Q UESTION 1.2.– Does M Y L offer at least one syntactic construct for the notion of
kit? If not, how can this notion emerge from the functionalities of the language, using
for example its file management, as we would do in C? (see the introduction of the
concept of a weak kit in section 2.3.2)

1.2. Namespaces

In the Chapters 3, 4 and 5 of Volume 1, a unique notion of identifier was used to

introduce variables, new data types, exceptions, etc. Each of the analyses presented
was implicitly aware of the role of the identifiers under consideration. The binding of
an identifier present in an environment could only be masked during the evaluation of
a local declaration. The identifier scopes were easy to determine by proofreading the
program source.

The division of software into kits requires better explanation of the role of
identifiers. What happens if a kit exports an identifier already used in the program
being written by the importer? Can two occurrences of an identifier in the same
expression have different bindings? Is it possible that several bindings are potentially
usable for the same occurrence of an identifier? Answering these questions requires
more complex modeling of the environment and the memory than the one given in
Volume 1. We will describe this modeling in a more or less formal way, relying on
the notions already studied in the first volume. The model allows us to determine
precisely the bindings of each of the occurrences of an identifier of an expression
during its typing and its execution. It will then be enough to apply the rules already
seen in Volume 1 to complete typing and evaluation of this expression.
6 Concepts and Semantics of Programming Languages 2

Examples will often be given with a syntax à la OCaml, using sum types and
definitions by pattern matching introduced in Volume 1, simply to reduce the length
of the codes presented.

1.2.1. Namespaces definition

In the compilation framework, the term namespace denotes the set of identifiers
occurring in a program. The names occurring in the bindings of typing or execution
environments, the record labels, etc., are elements of this namespace. In fact, most
programming languages have a structured namespace, which is divided into several
(sub) namespaces. Syntactic constructs provided to the user to declare their
identifiers are also used to determine the namespace to which a given identifier
should belong. These constructs can use keywords type, exception, var or syntactic
conventions, such as putting the name of modules in uppercase. So the compilation
process is simplified and code proofreading is made easier because the role of the
identifiers is more easily recognizable. Programming languages can thus allow the
use of the same identifier to name a type, an exception, a variable, a function, a
procedure, etc. In other words, the same identifier can appear several times in the
same expression, each of its occurrences being related to a type or value that may
differ from those of the other occurrences. Note immediately that these possibilities
sometimes make it easier to write source code but help proofreading only if they are
used judiciously. We can see this in example 1.2, written in OCaml and quite
exaggerated. The comments in the source code allow us to clarify the different uses
of t.

E XAMPLE 1.2.–
OCaml
# type t = { t : int } ;; (* type t1 = { t2 : int } *)
type t = { t : int; }
# let t t = (* let t3 t4 = *)
let t = t + 1 in (* let t5 = t4 + 1 in *)
{ t = t } ;; (* t2 = t5 *)
val t : int -> t = <fun> (* val t3 : int -> t1 = <fun> *)
# t 3 ;; (* t3 3 *)
- : t = {t = 4} (* -: t1 = {t2 = 4} *)

This example uses the same identifier t for the name of a type, the name of a
record field, the function name and the variable name. It even exploits name hiding by
local definitions, and the fact that, it is possible to use the same name for the function
and its argument, without conflict, as function t is not declared recursive. This kind of
code writing is of course to be proscribed. However, the compiler of OCaml is able to
process this example because each occurrence of t can only be accepted by a single
rule of syntax analysis (presented in section 1.2.3 of Volume 1).
 Namespaces: Model and Operations 7

In the remainder of this chapter, the model that includes kits uses three
namespaces:
– N T the namespace of types;
– N V the namespace grouping names denoting values, thus, constant identifiers,
variables, functions, exception identifiers, etc;
– N K the namespace of kits.

Example 1.3 is written assuming the language accepts that the same identifier can
appear in several namespaces. To express this example, we use a hypothetical
language, remaining just at the intuition level.

E XAMPLE 1.3.–
1 type person = (string * int)
2 Kit person = { ... }
3 exception person
4 person person = ("a", 20)
5 bool person = false
6 person := 25

Compiling example 1.3 in this way extends the namespaces as follows:

– adding person from line 1 to N T since it is the name of a type;

– adding person from line 2 to N K since it is the name of a kit;
– adding person from line 3 to N V since it is the name of an exception value;
– adding person from line 4 to N V since this line declares a variable by giving
first its type, then its name and finally its definition. Will the name of the exception
be hidden by the name of the variable or not? It depends on the language, the
compiler can recognize that person declared in line 3 is an exception thanks to
the keyword introducing it and can remove the ambiguity. It can also consider an
exception just as a value of a known type (exn by example), which will be hidden by
the declaration/definition of line 4;
– adding person from line 5 to N V since it is the name of a variable. Is the
name of the variable entered on line 4 being hidden or not? Again, it depends on
the language. If this one accepts variable overloading, then the definitions of lines 4
and 5 are accepted because their types are different;
– will the compiler accept line 6? No, if the type declaration is mandatory, line
6 would then be interpreted as an assignment to one of the declared variables and
would be considered ill-typed, unless the language accepts that 25 denotes a boolean
value. Yes, if, on the one hand, the language accepts the introduction of a variable
8 Concepts and Semantics of Programming Languages 2

without type declaration and, on the other hand, if it accepts overloading because it
can determine the type of 25. Line 6 (by replacing := by =) will then be understood as
the introduction of a new variable person of type int and added to N V .

The developer is thus led to refine the scope rules seen in Volume 1 in order to
take into account the existence, or not, of different namespaces. If the same identifier
is introduced by several declarations/definitions, there is not always masking of its
previous bindings by the last declaration made. Techniques for removing ambiguities
can be used. However, readers are advised to be careful when relying on them: it is
necessary to make sure that they will clarify what the binding is of each occurrence of
the multi-declared identifier throughout the source code. Remember that the presence
of multi-declared identifiers does not ease proofreading.

Note that the expression “namespace” is used by some authors to actually denote
the execution environment and to describe the scope of the identifiers. This can create
confusion. The determination of the membership of an identifier to a namespace is
made during the syntactic analysis by the compiler. The execution environment (also
called the evaluation environment) evolves during execution, in accordance with the
study in the Chapters 3 and 4 of Volume 1, which also explain the notions of scope of
an identifier and masking (also called hiding).

1.2.2. Extending notions of environment and binding

Partitioning the global namespace into three (sub) namespaces induces the
partition of any environment into three sub-environments (which are also called
environments) described below.

Within this model, an environment Env ∈ E is partitioned into EnvT , EnvV and
E nvK :

– EnvT contains the binding of type names belonging to N T to their definition;

– EnvV contains the bindings of names of N V to their value (resp. their type)
during execution (resp. during typing) in Env;
– EnvK contains the bindings of names (of kit) belonging to N K to their values
(or their types) introduced below.

Values and types were studied in Volume 1 using the notion of environment
and memory. The notion of memory is left unchanged while that of environment is
extended. With this extension, a typing analysis done in Env uses:
– bindings of EnvT ;
– bindings to their type of names in N V appearing in EnvV ;
 Namespaces: Model and Operations 9

– typing information bound to the names of the kits appearing in EnvK .

If the language is statically typed, an execution (also called an evaluation) made in

E nvdoes not use the bindings of EnvT . It uses:
– bindings in EnvV of names (belonging to N V ) to their values;
– bindings in EnvK of names of kits to their values (defined further).

If type checking is (at least partly) done at runtime, the runtime typing-evaluation
uses:
– bindings of EnvT ;
– bindings in EnvV of names (belonging to N V ) to their types and to their values;
– bindings in EnvK of names of kits to their types and their values.

Programming languages differ not only in their typing verification methods but
also by their notion of scope (lexical or dynamic or adapted according to the
syntactic constructs). The distinction between the typing environment and the
evaluation/execution environment is fading as typing can be started at compile-time
and completed at runtime. To simplify the description of the semantics of these
languages, we extend the notion of binding.

A binding will now be a tuple (identifier, information1 , information2 , etc.), the

information simply being separated by commas, the first information being, by
convention, the type of the identifier. If the type is not a given information (because
the type is confined, for example), it will be noted by ⊥t . If a value is unknown (not
yet initialized by example), it will be denoted by ⊥v . For example, in an untyped
language, the binding of the identifier x can be (x, ⊥t , ⊥v ) if x is only declared, then
will become (x, ⊥t , v) after the evaluation of its definition having returned the value
v. In a typed language, the type t of x will replace ⊥t in both bindings.

The definition let x = 1 introduces the binding (x, int, 1) in OCaml. The
definition type t = K of int introduces two bindings (t , K of int) in EnvT and
(K , int → t, Constructor) in EnvV . Here, mention of Constructor means that the
compiler is aware of the particular status of K, as shown by example 1.4 reminding
use of the distinction made by the OCaml compiler between a function f and a value
constructor K.
10 Concepts and Semantics of Programming Languages 2

E XAMPLE 1.4.–
OCaml
# type t = K of int ;;
type t = K of int
# K ;;
Error: The constructor K expects 1 argument(s),
but is applied here to 0 argument(s)
# K 1 ;;
- : t = K 1
# let f x = 1 ;;
val f : ’a -> int = <fun>
# f ;;
- : ’a -> int = <fun>

With our extended definition of binding, we have only one kind of binding in our
model, therefore one kind of environment. Depending on the nature of the analysis
performed and the namespace to which an identifier belongs, the subset of information
used for an analysis may be empty, may contain only type information, or only the
(execution) value, or confinement modifiers, etc. If we use only typing information
then we retrieve the typing environment used for static typing. If we use only the value,
we retrieve the execution (or evaluation) environment. Ultimately, the important thing
is that the developer or the user can model, within the bindings, all the information
available on a given identifier at any moment of compilation or execution they are
considering. This extension of bindings can help in grasping the meaning of the source
code, along writing and proofreading.

Let us look at example 1.5, which uses the dot-notation for the identifiers of the
kit P supposed to be imported. The types are not explicitly listed in the definitions to
lighten the example.

E XAMPLE 1.5.–
1 Kit P
2 type person = A of (string * int)
3 fun age = function A (s, a) -> a
4 ...
5 end P

6 type client = C of P.person

7 var a_client = C (P.A ("Pierre", 14))
9 exception too_young
9 fun accept = function C (P.A (s, a)) ->
10 if (P.age (P.A (s, a)) < 12) then raise too_young
11 else s

After typing and evaluation of this fragment of program, using the previous
notations for the three components of the environment, we have:
 Namespaces: Model and Operations 11

– after line 5, the binding (P, type_P, val_P) is added to EnvK , type_P and
val_P being the type and the execution value of P described below;
– from line 6, the identifiers of P are visible with the dot-notation P.person and
P.age. We will see later that the binding of P in EnvK also provides access to
the bindings (person, A of (string * int)) and (age, person -> int, FP), FP
being the closure (value) of the function P.age;
– after line 7, the environment EnvT has been extended with the binding
(client, C of P.person);
– after line 11, EnvV has been extended with the three bindings below. F is
the value of accept, so a closure, containing the definition environment of F if the
language is lexically scoped.

(a_client, client, C (P.A ("Pierre", 14)))

(too_young, exception, val_too_young)
(accept, client -> string, F)

We suppose that in example 1.6 the developer decides to confine the definition of
the type person by marking confine as its definition.

E XAMPLE 1.6.–
1 Kit P
2 confine type person = A of (string * int)
3 fun age = function A (s, a) -> a
4 fun name = function A (s, a) -> s
5 fun build = function (s, a) -> A (s, a)
6 end P
7 type client = C of P.person
8 var a_client = C (P.build ("Pierre", 14))
9 exception too_young
10 fun accept = function C (x) ->
11 if P.age (x) < 12 then raise too_young else P.name (x)

The developer of P continues to see the binding (person, A of (string * int))

until the end of the definition of P. This is necessary so that, for example, they can
correctly define the function age of type person -> int. At the end of the execution
of line 6, the export mechanism applied to P is in place and provides importers (in
other words, the users) of P, on the one hand, the binding (person, ⊥t ), ⊥t meaning
this type is confined and, on the other hand, the functions of P with their types.

From line 7, the developer becomes the importer of P. The current environment
E nvK of line 7 gives access to the binding (P.person, ⊥t ), the identifier person
being visible only as P.person. It also gives access to the binding of the functions of P
since they are not confined. The definition of the variable a_client uses the function
12 Concepts and Semantics of Programming Languages 2

P.build, provided by P, to define values of the confined type. The definition of the
function accept is modified as – the definition of the type person being confined – it
is no longer possible to decompose the actual parameter of the call to P.age by pattern
matching (see line 10 of example 1.5). Therefore, the formal parameter of accept can
no longer be completely decomposed, the constructor A of the type person being no
longer visible.

In example 1.6, it was necessary to add to the kit P the function name to give access
to the first argument of the constructor A and also the function age and the function
build. If the name of this type person was also confined, then no binding of person
would be offered to the user: the name of this type would be kept secret outside of P.
The importer could no longer use the name person and therefore could not define the
type client.

To conclude this section, we formulate two questions.

Q UESTION 1.3.– Does M Y L have multiple namespaces? How is the membership of

an identifier of a given namespace determined (syntactic construct, naming
convention, etc.)?

Q UESTION 1.4.– What is the general mechanism of scoping adopted by M Y L? What

forms of masking are accepted by M Y L? Write – if needed – a program such as
(exaggerated) example 1.2 to show prohibited/allowed masking.

1.3. kit development

In this section, we define the notions of types and the values of kits. Here, we
borrow a lot from different type theories, introduced to give a formal account of
modular and object features, however these theories go far beyond the scope of this
book. Although precise, our presentation remains informal in the sense that it does
not allow for the proof of partial correction of typing. The limits and possible
extensions of this model will be commented upon at the end of the chapter.

Let LangK be a language offering declarations/definitions of types and variables,

functions, procedures, exceptions, etc., that is, all the features studied in Volume 1.
This language also offers a syntactic construct introduced by the keyword Kit which
defines a named entity, referred to here as kit. A kit name begins with an uppercase
letter. The concrete syntax is defined as follows:

Kit K_ident = { component_1 ... component_n }

A kit component is introduced as follows:

1) a type declaration: type ident, for example, type person;

 Namespaces: Model and Operations 13

2) a type definition: type ident = deftype, for example, type person =

A of (string * int);
3) a variable declaration: var ident: type, for example, var un_client:
client;
4) a variable definition: var ident: type = def, for example, var un_client:
client = ("Alan", 25);
5) a function (or procedure) declaration: fun ident: type, for example,
fun age: person -> int;
6) a function (or procedure) definition: fun ident : type = def, for example,
fun age: person -> int = function A (n, a) -> a;
7) an exception declaration: exception ident;
8) a definition of kit, called “internal kit”, for example,
Kit Kit_ident = { component_a ... component_n }.

In our concrete syntax, the introduction of a component begins with a keyword

which specifies its nature, simply to facilitate reading and writing of the book. This is
not always the case in programming languages. Example 1.7 illustrates this syntax. It
is an implementation of a stack of integers that only memorize positive integers and
ignore push requests of negative or null integers. It contains only definitions of types,
variables and functions.

E XAMPLE 1.7.–
Kit Stack = {
type t_stack = H of int list
var floor : int = 0
exception empty_stack : exn
fun top : t_stack -> int =
function p ->
match p with
| H [] -> raise empty_stack
| H (h :: _) -> h
fun push : (int * t_stack) -> t_stack =
function (elt, (H l)) ->
if elt > floor then H (elt :: l) else H l
fun create_stack : unit -> t_stack = function () -> H []
}

The abstract syntax adopted for kits is as follows:

P = { l 1 : t1 = e 1 ; · · · ; l n : tn = e n }

The components of a kit are of the form l : t = e where l is the identifier of the
component, referred to as the field of the component. All of the fields are supposed to
14 Concepts and Semantics of Programming Languages 2

be distinct and we suppose that this syntactic condition is always fulfilled, for
example it can be verified by the compiler. t is the name of a type of LangK and e
denotes an expression of LangK or a definition of type in LangK . In example 1.7,
the component expressed in the concrete syntax var floor : int = 0 is translated
into the abstract syntax in floor : int = 0 where floor is the field of the
component; the indication var is not integrated in the abstract syntax.

The text fragment “the component of field l” will often be abbreviated to “the
field l” and the word component will be replaced with field when there is no need to
distinguish between the component and its name.

Some definitions (represented by ei in the abstract syntax) of components may be

absent in the definition of a kit. In this case, the field is said to only be not-defined
(or just declared). A kit is said to be complete if all of its components have received
a definition. Otherwise, it is said to be incomplete. For example, the kit Stack of
example 1.7 is complete.

WARNING .– The abstract syntax could lead to the conclusion that the notion of kit
is just a kind of generalization of records, the components of the kit being the fields
of these records. However, record fields, even if they can be of any type – including
a functional type (as in OCaml, for example) – cannot be definitions of types, nor
can they contain local declarations of variables or be defined by expressions using the
names of the other fields. Records are only designed to encode structured data. The
above example illustrates the difference between a kit and a record: the definition of
the component whose field is push uses the field floor.

The syntax used to name imported components in a development is the

dot-notation P.l, P being the name of the kit and l one of its fields. For example,
importers of the kit Stack in example 1.7 can use the type t_stack denoting it by
Stack.t_stack, call the function Stack.top, etc.

1.3.1. Namespace of a kit

In our model, we assume that every kit, say P , has its own namespace that we call
N (P ), itself divided into sub-spaces of names, denoted N (P )T , N (P )V and N (P )K .
Allowing a kit to have fields which are themselves kits leads to a kind of recursivity in
the definition of N (P ) since N (P )K is the namespace of the “internal kits” defined
in P , each of these kits having its own namespace, which is also divided into three
namespaces, and so on.

In example 1.7, the kit Stack has 6 fields. The first field t_stack introduces the
definition of the type t_stack. The second field, floor, defines a variable and so on.
The namespace associated with Stack is divided into:
 Namespaces: Model and Operations 15

– N(Stack)T = { t_stack };
– N(Stack)V = { floor, empty_stack, top, push, create_stack };
– N(Stack)K = ∅.

1.3.2. Order of fields introduction

Programming languages differ in their strategies for analyzing dependencies

between declarations and definitions of kit components. The choice is twofold: either
components can only use the fields of the components previously introduced in the
kit, or any component can use any field of any component. Therefore, the chosen
strategy defines what the allowed dependencies are between fields of the same kit.

The first possibility can be imposed on the developer of a kit, who must choose an
order in which to introduce fields in the kit, according to the dependencies between
them. This choice may also be left to the compiler, which will try to reorder fields
to satisfy the strategy. The second possibility leads all definitions being considered
mutually recursive definitions, this simplifies source coding but can complicate the
static analyses performed by the compiler. In this section, for the sake of simplicity,
we opt for the first choice. More precisely we make the hypothesis that the order
of components in abstract syntax is such that a component depends only on those
introduced previously. This allows us to give very simple definitions of the type and
the value of a kit, without the need to introduce fixpoints for these definitions (see
Chapter 4 of Volume 1 where fixpoints are studied). These simple notions of type and
value will be developed later in the chapter, when some operations will be added to the
kits. For example, in the case of confinement, it is also necessary to associate to a kit
the information on the types and values it exports, i.e. the information made available
to users.

1.3.3. Typing kits

In this section, we only consider complete kits, thus with all components defined.
Incomplete kits will be studied in section 1.4.

Let Env be the current environment partitioned into EnvT , EnvV and EnvK . Any
binding present in one of these environments associates an identifier with a set of
information. Supposing that the language is statically typed and that types are declared
by the user, the typing analysis will use the typing information enclosed in the different
bindings. We just retrieve the typing environments of Chapter 5 of Volume 1. Our
hypothesis on the order of fields in the source code of a kit induces the typing strategy.
Typing of a kit is done by applying the typing rules given in Chapter 5 of Volume 1
to each field, following their order in the source code. As soon as a component of the
16 Concepts and Semantics of Programming Languages 2

kit has been typed, the binding of its field to its type is added to the (corresponding
component of the) current environment and typing of the next component is done in
this extended environment. So this strategy assumes that the types figuring in the kit
are introduced before the components using them (such as those introduced by var,
fun etc.).

Let P be a kit defined as follows: P = { l1 : t1 = e1 ; . . . ; ln : tn = en }. The

type of P , denoted PT ype , is defined by the collection of associations of its fields
belonging to N (P )T with their type definitions and the associations of its other fields
with the types of their definitions. It is described as follows:

PT ype = { l1 : t1 ; . . . ; ln : tn }

If li ∈ N (P )T , then ti = ei (we take the type definitions figuring in P ), otherwise

ti is the type of ei which is obtained by the typing algorithm used by the language
LangK . The typing rule of a kit is stated as follows:

∀i ∈ [1, n] (l1 , t1 )  · · ·  (li−1 , ti−1 )  Env  ei : ti

(RT )
E nv  P : PT ype

where  is an operation which adds the binding of the field l to the right component
of Env, according to the contents of l.

As soon as the type of P is determined, the binding associating P to PT ype is added

to EnvK . It allows us to find the types of components of P thanks to the dot-notation
P.l, which gives access to the binding of P in EnvK so to PT ype and then to the type
of the field l.

Again, let us take example 1.7 which defines the kit Stack. The type of this kit
contains, among others, the association of t_stack with the definition H of int list
and the association of top with the type t_stack -> int. With a concrete syntax
similar to the one adopted for kits, this type is written:

type Stack = {
type t_stack = H of int list
var floor : int
exception empty_stack : exn
fun top : t_stack -> int
fun push : int -> t_stack -> t_stack
fun create_stack : unit -> t_stack
}

The strategy of typing presented above will be reused for the evaluation of a kit
and will be detailed there.
 Namespaces: Model and Operations 17

In our model, fields are an integral part of the type of a kit. Two kits having
components of the same type but differing in their fields do not have the same type.
We also make the hypothesis that two kits having different names are not equal. So
the chosen typing system is nominal (also called named-based). Type equality was
discussed in section 6.6 of Volume 1.

WARNING .– In fact, this presentation of kit types and typing, reminiscent of record
typing, is far too simple to completely handle all the features and operations on kits
(functors, inheritance, etc.). It has the advantage only of providing an intuitive
approach to kit typing and more or less corresponding to the typing discipline of
most typed object-oriented languages. But it may also seem too complicated to be
applied to some languages such as Python, which do not require declarations of fields
to be typed and which do not make type inference but perform certain type checks at
runtime. See example 1.8, using the interactive mode of Python.

E XAMPLE 1.8.–
Python
$ python3
>>> class C:
... x = 5
...
>>> print ("value of the field C.x:", C.x, "; type of C.x:", type (C.x))
value of the field C.x: 5;type of C.x: <class ’int’>

>>> C.x = ’aa’

>>> print ("After assignment, the value of C.x is:", C.x, "; its type is:", \
type (C.x))
After assignment, the value of C.x is: aa ; its type is: <class ’str’>

>>> 3 + C.x
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
TypeError: unsupported operand type(s) for +: ’int’ and ’str’

The assignment C.x = ’aa’ apparently changes the type of the field x. Python is
dynamically typed and the type of a field may change at runtime. On the other hand,
the operator + cannot be applied to an integer and a string (which is the value of
C.x after the assignment) because + is not bound in the current environment to any
functional value able to do this addition.

Of course, no one writes such code right away. But these modifications of kit fields
can be made in any code which has access to the class C. This example, conforming
to the semantics of Python, will be reviewed in section 4.4 to detail the meaning of
this assignment operation, which explains and justifies the answers of Python. In any
case, maintaining a typing discipline, even if the language does not require it, is a
good practice in writing kits because it ensures some logical consistency of the written
source code. This leads to some questions.
18 Concepts and Semantics of Programming Languages 2

Q UESTION 1.5.– Does M Y L possess a notion of type of a kit? If so, what is the link
between the name of a kit and the name of its type?

Q UESTION 1.6.– Are the fields of kits typed? Are their types declared by the
developer or synthesized by the compiler?

Q UESTION 1.7.– Let P 1 and P 2 be two kits having the same fields associated with the
same types. Do P 1 and P 2 have the same type? Or, is M Y L typing strictly nominal?

Q UESTION 1.8.– This question covers all types (if any) in M Y L. Is it possible to make
explicit a conversion of a type t1 to a type t2 ? Does M Y L perform implicit conversion
of types, at least in some cases? Identify these cases.

Q UESTION 1.9.– May two components of a kit having different types be named by the
same field? In other words, if M Y L accepts some form of overloading of fields, is it
allowed?

1.3.4. kit values

We continue to consider only complete kits. So far, in our model, the evaluation
of a syntactic construct produces either a side effect or a value, sometimes called the
execution value (or runtime value). This value is not always a first class value, that
is, a value that can, for example, be returned as a result (see Volume 1 for a precise
definition of all these kinds of values). We extend this model with the notion of kit
value. In some languages, kit values are not first-class, they are only runtime values.
This is quite often the case with modules and classes. But these kit values can also be
first class values and it is quite often the case with objects. The intuitive presentation
which follows can be applied to both kinds of values; the issues specific to first class
kit values will be discussed in Chapters 2 and 3.

Let us first consider a kit P whose fields are not type definitions nor kit definitions.
The value of this kit is then built as the collection of the values of its components
denoted by:

PV alue = { l1 = v1 ; . . . ; ln = vn }

where vi is the value of the component whose field is li .

Let us detail the evaluation of P , assuming the field definitions are evaluated in the
order of its abstract syntax. Let us also assume that the language is statically typed.
The typing has therefore already been done. The evaluation does not perform any
type checking and therefore uses only the accessible values in the bindings of the
current environment. To evaluate a kit, we follow the strategy used for typing, each
 Namespaces: Model and Operations 19

step of evaluation being done with the evaluation/execution rules of Chapters 3 and 4
of Volume 1.

Let E = (Env0 , Mem0 ) be the current state at the beginning of the evaluation of
the kit P where Env0 = (EnvT , EnvV , EnvK ).

The evaluation of the first field, say l1 ∈ P V , in (Env0 , Mem0 ) with our
convention, returns a value v1 and modifies the state E which becomes the new state:

((EnvT , (l1 , v1 ) ⊕ EnvV , EnvK ), Mem1 )

M em1 will differ from M em0 if the evaluation of e1 produces side effects. The value
vi of each field li is then obtained in the same manner, by following the order of
the fields in the source code. Every evaluation extends the current environment and
possibly modifies the memory.

At the end of the evaluation of P , bindings added to EnvV disappear and the
binding (P, PV alue ) is added to EnvK . The resulting environment is therefore (EnvT ,
E nvV , (P, PV alue ) ⊕ E nvK ). The memory remains in the state reached at the end of
the complete evaluation, as the execution of some components may cause side effects.

However, the components of a kit can also be type definitions, for which no
(runtime) value has been defined. We then have the small difficulty of writing values
bypassed as follows. Strictly speaking, fields belonging to N T should not figure in a
kit value. But this requires the renumbering of the li fields. To avoid this and thus
maintain a uniform presentation of kits in abstract syntax, we assign a fictive value ∅t
to any field introducing a type.

Moreover, some fields of a kit P can be kits themselves. Their evaluation is done in
the current state reached by evaluation of the fields written before them in the source
code of P and follows the strategy we have just described.

Note that, if the language has lexical scope, if the definition of a field P.li is a
function whose body contains an occurrence of the field P.lj , then the value of P.li is
a closure that contains the binding of P.lj to its value.

Under lexical scope, the evaluation rule of a kit is as follows:

∀i ∈ [1, n] (l1 , v1 )  · · ·  (li−1 , vi−1 )  Env  ei  vi

(RE )
E nv  P  PV alue

In the case of dynamic typing, the evaluation of a field li starts by the typing
verification of its definition, followed by the evaluation itself, and it uses the type
20 Concepts and Semantics of Programming Languages 2

information present in the bindings of the current environment. The description of

the evaluation made for statically typed languages can be taken over but the result is
twofold: the type ti and the value vi are returned and the name li is bound to the two
sets of information ti and vi .

We have not yet detailed the evolution of the environment alongside the
evaluation of kits. We do so now, considering only the evaluation of kit Stack from
example 1.7. We assume that the language uses lexical scope and that the current
state is (Env0 , Mem0 ). Let Env0T , Env0V , and Env0K be the components of Env0 :
1) evaluation of field type t_stack = H of ... extends the environment Env0T
to Env1T = (t_stack, ;t ) Env0T . The other components of the environment Env1
so obtained are those of Env0 : Env0V =Env1V and Env1K = Env0K ;
2) evaluating exception empty_stack extends the environment Env1V to
E nv2V = (empty_stack, exception) Env1V ;
3) evaluating var floor = 0 extends Env2V to Env3V = (floor, 0) E nv2V ;

4) in the same way, evaluation of the definition fun top p = match p with ...
returns the closure F1 = hp, match p, ..., Env3 i and extends Env3V to Env4V =
(top, F1 ) Env3V ;
5) and evaluating fun push elt H l = if ... in Env4 returns the closure F2 =
helt, H (l), if, ..., Env4 i and extends Env4V to Env5V = (push, F2 ) Env4V ;
6) The evaluation of the last field fun create_stack () = H [] in Env5
returns the closure F3 = h_, H ([]), Env5 i and extends Env5V to Env6V =
(create_stack, F3 ) Env5V .

The evaluation of the kit Stack is finished. The value of Stack is:

StackV alue = { t_stack = ;t ; empty_stack = exception; floor = 0;

top = F1 ; push = F2 ; create_stack = F3 }

During this evaluation, the source code of Stack was de facto considered as a
sequence of local definitions in the kit, thus placing this execution analysis within
the framework defined in Volume 1, Chapters 3 and 4. The environments built during
the evaluation of Stack disappear but remain stored in the closures, which are values
of functional fields of Stack, to conform to lexical scoping. The evaluation of the
definition of Stack extends the current environment into:

E nvT , E nvV , (Stack, StackT ype , StackV alue ) E nvK

In this example with no side effects, the memory remains the same throughout the
evaluation of the kit.
 Namespaces: Model and Operations 21

We recall that this evaluation was carried out under the assumption that fields are
evaluated in the order of their presentation in the source code. This is the case in
OCaml: the first line of example 1.9 has been rejected because the field y is used
before being introduced.

E XAMPLE 1.9.–
OCaml
# module M = struct let x = y + 1 let y = 3 end ;;
Error: Unbound value y
# module M = struct let y = 3 let x = y + 1 end ;;
module M : sig val y : int val x : int end

Example 1.10 shows that Java makes the same choice.

E XAMPLE 1.10.–
Java
class MC {
int x = y + 1 ;
int y ;
MC (int a , int b) {
this.x = a ; this.y = b ;
}
public static void main (String args[]) { ... }
}

$ javac MC.java
MC.java:4: error: illegal forward reference
int x = y + 1 ;
^1 error

Here follow some questions about the definition and evaluation of a kit.

Q UESTION 1.10.– In M Y L, is the order of the fields of a kit important? Can a field
use a field that is defined after it in the source code?

Q UESTION 1.11.– May a field have a recursive definition without mentioning it using
a keyword like rec? Is there a possibility of mutual recursivity between several fields?

Q UESTION 1.12.– Apart from its fields, can a kit contain a block of instructions
declaring, for example, local variables to the kit and performing any side effects?
When is this block executed?

Q UESTION 1.13.– Are the functions of M Y L first class values?

Q UESTION 1.14.– Are the kits of M Y L first class values? (see Chapters 2 and 3 to
for further explanation).
22 Concepts and Semantics of Programming Languages 2

1.3.5. kit export, confining fields

The frontier between development and usage of a kit was discussed in section 1.1.
Remember that any operation on a kit is the responsibility of the developer. The
importer can only use the fields of the imported kit (even if the developer and the
importer are the same person). In this section, we study the confinement operation
and the resulting mechanism of exports. We will see in section 1.7 that this
confinement operation does not only serve to restrict exports. It is also used to control
certain operations on kits, such as the addition of fields. It is important to make a
clear distinction between these two different roles, as explained in the following.

We have seen in Volume 1 that the evaluation of a local declaration can hide a
binding already present in the current environment. This masking concerns the whole
code written by the developer in the scope of this declaration and ceases at the end of
this scope. When the local binding disappears, the hidden binding is again visible. In
general, no syntactical mark points out this hiding. The confinement of a type
definition, of a value, etc., is a very different kind of operation, its objective is to
restrict access to some kit fields to importers. It is denoted in the source code by a
syntactic construct. The confinement operation of a kit P acts on the visibility of P
fields after the export operation. Depending on the language, it can be carried out in
two different ways.
– Restricting export possibilities of a field can be done by adding a mark on it,
which can be a keyword or a modifier like protected, private, etc. The confinement
achieved by marking some fields of a kit depends on the language: the marks private
of Ada, Java or OCaml do not have the same meaning.

A field type ident = deftype can be marked so as to authorize the export of

ident and to prohibit the export of deftype. The name ident can also remain confined
by using another mark.

A mark on a field that defines a value can prohibit the export of the field name
which is therefore not usable outside of the kit (see the mark private of Ada in
Chapter 2).

Confining by marking fields in this way is typical of object-oriented languages

(see Chapter 3). The exporter sets the conditions of field exports directly into the
source code of the kit, according to categories of importers defined by the language.
For example, in Java, a field of a class C marked protected can only be used to
define classes belonging to the same group of files (called a package) as C. So the
mark protected has some consequences on later stages of Java software developments
importing C.
– Confinement can be conceived in a more flexible way in order to meet the needs
of different importers. This implies that the confinement is defined outside the source
 Namespaces: Model and Operations 23

code of the kit. One can either indicate which fields are to be confined or which
fields are to be exported to comply with importer requirements. The confinement
can be expressed by a type or a dedicated syntactic construct, sometimes called the
interface. This is the case, for example, for the OCaml modules (see section 2.2),
which can adapt field visibility to each importer’s needs, as will be seen in Chapter 2.
Incidentally, note that the word “interface” is used by many programming languages,
but with quite different meanings.

We now consider the confinement mechanism(s) that can be used to export a kit.
Let M be the confinement information which we are making explicit. For example,
for the kit P of example 1.6, M = confine type person. In OCaml, we study the
confinement obtained by the restriction put on the type t1 of a kit P defined by a
“more constraining” type t2 and M will then be M = {P : t2 } (see Chapter 2).

We note RP = From(P,M) the export operation of P , according to the

confinement indication M , RP is the name given to the result of this export. For the
moment, denoting the confinement information by M is sufficient, there is no need to
know its contents explicitly. We will distinguish between the two possibilities of
confinement when necessary.

With or without confinement, the export of a kit P should allow importers to use
exported fields without needing to access the source code of P . In return, importers
must not make any assumptions about the implementation of exported fields from P .
This is the very principle of the “off the shelf” component software libraries.

Export does not build a new kit but provides the importer with access to the P
exported “part”, named RP , consisting of a set of component names, associated with
their types (if the language requires type declaration). An importer can use a field l
exported by P by naming it RP.l. In some languages (often in object languages) the
P and RP identifiers are identical. In other languages, RP is considered to be a new
kit, which is not totally correct because there is always some sharing at object-code
level between P and RP components.

The definition of any component of a kit P can, without restriction, use the name
(field), the type and the value of another component totally or partially confined in
P : the export operation does not constrain the developer of the kit themselves. As
soon as the kit P has been completely defined, its fields can be used immediately
with the dot-notation in the source code, provided it is done in accordance with the
confinement: once the kit P is built, the developer becomes an importer of P for the
continuation of source writing.

The operation RP = From(P,M) produces, from the field P.ident, a set of

information in accordance with the mention M of confinement. We describe below
the information that is provided by the confinement of a field, according to its nature
24 Concepts and Semantics of Programming Languages 2

and M requirements. We denote by From(l) the result of the confinement operation

applied to a field l and we use the concrete syntax to informally describe it. Of
course From(l) returns l if this field is not confined:
1) if ident ∈ N (P )T , we can only confine the definition of the type. Only the
name of the type ident is then exported:
From(type ident = typedef) = type ident
In this case, importers cannot directly define values of this type ident nor can they
define functions by pattern matching on the values of ident. Only the fields exported
by the kit P can be used to manipulate values of type ident;
2) the restriction on ident ∈ N (P )T may be stronger: the name ident of the type
can be confined:
From(type ident = typedef) produces nothing.
The importer will have no way of knowing this type. In addition, if the type of
a field l contains occurrences of ident, then l must also be confined because an
expression of the importer using l could not be typed;
3) an exception ident can be confined. The importer will not be able to raise it or
catch it with the name ident. Be careful, this exception can, however, be caught up
by an exception handler with a case by default intercepting all exceptions raised (see
section 8.2 of Volume 1):
From(exception ident) produces nothing;
4) If the name ident of a component which is a variable (var in our concrete
syntax) or a function (fun) is confined, then the field ident is not exported:
From(var ident : type = def) produces nothing;
5) Otherwise, the name ident and the type of a not-confined component, which is
a variable or a function var (or fun), are provided to importers who can use all of the
information:
From(var ident : type = def) = var ident : type
6) If ident ∈ N (P )K , ident is the name of a kit, which can be confined: this
internal kit ident is not exported:
From(kit ident : type = def) produces nothing;
7) Alternatively the developer may confine some fields of the internal kit ident by
applying the operation From on the fields of ident.

The importer is not aware of the existence of a totally confined field. In other
words, this field is not visible to the importer. This does not necessarily mean that the
 Namespaces: Model and Operations 25

value of this field is inaccessible because any other field of P can use the confined
field and reveal its value.

If the field l is not exported, if instead there is an occurrence of the name P.l in
the importer’s source code, we make the hypothesis that the compiler will reject this
source through a preliminary analysis (syntactic analysis, scope analysis) or ultimately
by a typing analysis, and we do not handle this case in the following.

The export operation computes the type RPT ype and the value RPV alue of RP
taking into account confinement indications. Let P be a kit, whose type is PT ype =
{ l1 : t1 ; . . . ; ln : tn } and value is PV alue = { l1 = v1 ; ln = vn }. Let us consider
the question of expressing the type and value of RP . The only way is to refer to types
and values of P fields. Mentioning in the RP type and value all the P fields cannot
be correct. Simply removing those fields of P which are not exported would create
some “holes” in the numbering of the RP fields if we keep the numbering of P fields.
For example, if P = {l1 ; l2 ; l3 }, if l2 is not exported, then writing RP = {l1 ; l3 }
requires mention of the absence of l2 and this solution is not easily generalized to n
fields. Our solution is as follows.

If m fields among the n fields of P are exported, we define a set of indices

{a1 , a2 , . . . , aj , . . . , am } and we note RP = { la1 . . . ; . . . ; lam } making the
hypothesis that for any j ∈ [1, m], there is a unique k ∈ [1, . . . , n] such that the field
RP.laj is obtained by exporting the field P.lk . Therefore the export operation builds
the collection of exported fields { laj | j = 1, · · · , m} named RP , which are defined
as follows:

– Let us suppose that the indication of confinement M is given independently of

the definition of P :

- if the field lk introduces the definition of a type tk and if this definition is

confined, then the type associated with RP.laj is ⊥t otherwise it is tk ;
- if lk introduces the definition of a value of type tk , if this definition is not
confined then the type associated to RP.laj is tk and its value is vk ;
Therefore, the type and value exported by P can be written:

RPT ype = { la1 : ta1 ; . . . ; lam : tam } where taj = tk if laj = lk

RPV alue = { la1 = va1 ; . . . ; lam = vam } where vaj = vk if laj = lk

– if the confinement marks are carried by the fields, then they must be stored
in the type and/or value of P to be used when verifying import operations
(and extension operations, studied later) either at compile-time or runtime. We
note this marks ci and include them in the type of P , by placing them before
the fields. Therefore, in our model, a field of P is now bound to a set of
26 Concepts and Semantics of Programming Languages 2

information build up with its type, its value and its confinement mark. The
type of a kit P is now written: PT ype = { c1 l1 : t1 ; . . . ; cn ln : tn }. The export
operation keeps the marks on fields of RP . The type of RP is therefore written:
RPT ype = { ca1 la1 : ta1 ; . . . ; cam lam : tam }. The value of RP is identical to the
one given in the previous point.

Note that, unless the definition of the type of a field is confined, the type of an
exported field is the same in P and in RP .

An expression e in the source code of the importer can use an exported field
RP.l2 , even though the definition of l2 in P uses a confined field l1 (which is not in
RP ). Indeed, the value of RP.l2 is that of P.l2 and was obtained by the evaluation of
P . Refusing such an indirect use of l1 would in fact amount to prohibiting the use of
l2 . More fundamentally, this refusal would force us to modify the notions of type and
execution value of a field, which would depend not only on the current typing and
evaluation environments of P , but also on any decision taken later on other fields.
Therefore, during typing and evaluation of the importer’s code, any expression
containing the field RP.l2 can be typed and evaluated, even if the definition of the
field P.l2 uses the confined field P.l1 .

Example 1.11 continues example 1.7; we confine the definition of the type t_stack
by marking it with confine-def and the field floor by marking it with confine. So,
M =(confine-def t_stack, confine floor).

E XAMPLE 1.11.–
Kit Stack = {
confine-def type t_stack = H of int list
confine var floor = 0
exception empty_stack
fun top p =
match p with
| H [] -> raise empty_stack
| H (h :: _) -> h
fun push elt (H l) =
if elt > floor then H (elt :: l) else H (l)
fun create_stack () = H []
}

The type of Stack is now written:

StackT ype = { confine-def t_stack : H of int list ; confine floor : int ;

empty_stack : exn ; top : t_stack → . . . ;
push : int → . . . ; create_stack : unit → t_stack }
 Namespaces: Model and Operations 27

Let RStack = From(Stack,M). The type of RStack is the following

RStackT ype = { t_stack : ⊥t ;

empty_stack : exn ; top : t_stack → . . . ;
push : int → . . . ; create_stack : unit → t_stack }

We recall the value of Stack:

StackV alue = { t_stack = ∅t ; empty_stack = exception; floor = 0;

top = F1 ; push = F2 ; create_stack = F3 }

The value of RStack is the following:

RStackV alue = { empty_stack = exception;

top = F1 ; push = F2 ; create_stack, F3 }

The types and values of fields of a kit are computed by the compilation/runtime
process and are not modified by confinement. Exported fields that are not types keep
their type and value. Remember that if one of the fields of a kit P is a type t with
a confined definition, the importer can do nothing with the mere knowledge of this
name t. So P must export creation and manipulation tools for the values of type t.
If the name t is also confined, making its values accessible to importers requires the
export of components accessing it indirectly, in such a way that the type t does not
appear explicitly in the exported component types (a point to handle if confining t is
done to keep secret the values of t). Section 2.2.3 will resume all of these points using
OCaml.

WARNING .– Confining a type or a value does not guarantee that this type or value
cannot be indirectly recovered by importers. In addition, some languages provide tools
to get information on confined types or values, a point which can lead to serious
security problems.

We extend the list of questions to be raised when reading a reference manual, as

follows:
Q UESTION 1.15.– The file management made jointly by the language and the
operating system may offer some form of export/import. Does M Y L allow for
confining values or types apart from a kit mechanism? See the definition of weak kits
in Chapter 2.
Q UESTION 1.16.– How is confinement of kits defined in M Y L? Is there some
interaction between confinement and the management of language libraries through
some marks (as protected, for example)?
28 Concepts and Semantics of Programming Languages 2

Q UESTION 1.17.– Is the name of the confined kit different to that of the original kit?
Is it possible that the two names are identical?
Q UESTION 1.18.– Is it possible to define several confinements for the same kit?
Q UESTION 1.19.– Does M Y L consider that the type of the confined kit is the same
as that of the original kit?

1.3.6. kits import

In this section, we adopt the importer’s point of view on the result of the
operation RP = From(P,M). Remember that the importer has no way of performing
an operation on the imported kit: they have no access to the source text of P . This
vision of the importer allows for positioning the frontier between pure reuse and
continuation of kit development, started earlier (for extending it, by example).

1.3.6.1. Import operation

The import of RP is done by an operation referred to here as With(RP ). The name
RP must be known to the importer: either RP has already been defined in the source
program being written or it belongs to an external library and its name is known after
loading.

This import can be made explicit in the source itself, for example using the
keyword with in Ada, from/import in Python, or it may remain implicit, the simple
use of the complete name of the kit indicating the import request. This complete
name may mention, in addition to the name of the kit itself, the path to the kit in the
system libraries. For example, in Java, one can access the class array by naming it
java.util.array, the package (i.e. the library) util being included in the standard
library, named java, which the compiler can access through the Java installation.

Any field l of a kit P can be used in importer programs under two conditions:
on the one hand, the name P must be visible to the importer, on the other hand, the
developer of P must have decided to export this field l. In the expressions of his source
code, the importer denotes the field l by a qualified identifier, formed with the name
of the kit, a separator and the name of the field. The separator is often a dot, hence
the name “dot-notation” for qualified identifiers. In this case, the qualified name of l
is P.l.

We now describe our model of the import operation. Let

E nv = (EnvT , EnvV , EnvK ) be the current typing/evaluation environment. The
import operation With(RP ) extends EnvK with the binding of RP to its type
RPT ype and to its value RPV alue , in accordance with the following rule:

With(RP )
((EnvT , EnvV , EnvK ), Mem0 ) −−−−−−→Def 6
(EnvT , EnvV , (RP, (RPT ype , RPV alue )) ⊕ EnvK , Mem1 )
 Namespaces: Model and Operations 29

This operation makes the fields of RP and their types visible to the importer, they
can use them in their code using the dot-notation. It ensures consistency between
import and export, with or without confinement. A compiler can check this
consistency, for example, by typing.

Let us go back to the type of RP , from the importer’s point of view. We recall this
type seen in the previous section:

RPT ype = { ca1 la1 : ta1 ; . . . ; cam lam : tam }

Let us assume that the field la1 is a type whose definition is confined (and that, to
simplify the description, this field is the only confined type). The types of the other
fields of RPT ype can contain occurrences of la1 (for example, the type of a field l
that prints a value of type la1 is la1 → unit). Let e be an expression of the importer
using la1 . To type e, the compiler cannot make any hypothesis on la1 since the only
information available on la1 is that this type exists because it has a name. To account
for this meaning of the name la1 , we can extend the syntax of the type language by an
existential quantifier ∃, abstracting all occurrences of la1 in the types taj . The type of
RP can then be expressed as follows:

RPT ype = ∃ la1 . { ca1 la1 ; . . . ; cam lam : tam }

We also have to add an introduction rule and an elimination rule of this existential
quantifier to the typing rules studied in Chapter 5 of Volume1 and modify the typing
algorithm to apply these rules. The algorithm will then be able to check the consistency
of import towards export, that is, to ensure that uses of the exported fields of P in the
source code of an importer are compliant with the confinement semantics.

Adding existential types to the family of types makes it possible to precisely model
and verify type confinement. The presentation of this extension is beyond the scope
of this book but it is well studied in type theories for programming languages. To
intuitively analyze typing in the case of confinement, the importer can consider that the
field denoting a confined type is the unique constructor of a constant type, completely
opaque in the sense that no information is available on values of this type.

Let us justify the evolution of memory in the import rule. Some fields in a kit RP
can be mutable. In this case, a memory area is allocated to each mutable field by the
operation With(RP ), so the current memory is modified. The initialization of this
memory area can be done during the With(RP ) operation. Otherwise, it is imperative
to do so before the first reading of these fields (as for any mutable variable). Similarly,
a kit P may have fields whose evaluation performs a side effect. The evaluation of
With(RP ) triggers these side effects, sometimes with very surprising consequences
30 Concepts and Semantics of Programming Languages 2

(see article [JAE 14]). As a general rule, side effects in the kits are not recommended.
The Example 1.12 in OCaml illustrates this point and demonstrates the consequences
of an omission of () in the definition of show. The “involuntary” side effect displaying
loading of S: 25 after loading of the module S is not reproduced by loading the
module Sbis, the addition of a parameter () to show modifying the type of show.

E XAMPLE 1.12.–
OCaml
# module S = struct
let v = 25
let show = Format.printf "chargement de S : %d\n" v
end ;;
chargement de S : 25
module S : sig val v : int val show : unit end
# module Sbis = struct
let v = 25
let show () = Format.printf "chargement de Sbis : %d\n" v
end ;;
module Sbis : sig val v : int val show : unit -> unit end

The following questions concern the names of the kits imported from the same kit.

Q UESTION 1.20.– In M Y L, can a kit P be imported under two different names RP1
and RP2 in the same source code?

Q UESTION 1.21.– If the answer to the previous question is yes, does the typing
consider that the type of the kit RP1 is different from the type of the kit RP2 ?

Q UESTION 1.22.– Does M Y L accept some form of compatibility between types RP1
and RP2 ?

Q UESTION 1.23.– If P exports a type t whose definition is confined, does the typing
consider that the type RP1 .t is different from the type RP2 .t? Apply the same question
to other exported fields.

1.3.6.2. Flattening import

Let P be the name of an imported kit and li be one of its fields. The notation
P.li unambiguously designates this field li , which makes it easier to review programs.
Some developers find it a bit heavy. Some languages thus offer the operation Flat(P )
which places, in the current environment Env, bindings of P fields with their type
and/or value.

Let P T , P V , and P K be the namespaces introduced by P . Let EnvT , EnvV , and

E nvK be the three parts of an environment Env. To execute Flat(P ) in Env, the name
P of the imported kit must be bound in EnvK . The operation Flat(P ) acts as follows:
 Namespaces: Model and Operations 31

– the fields li belonging to P T are bound to their type definitions and these
bindings are added to the environment EnvT ;
– the fields li belonging to P V and P K are bound to their type, their value (and to
any information needed to analyze them) and these bindings are added to EnvV and
E nvK , respectively.

The following rule shows the insertion – in each of the components of the
environment – of the bindings built from the type and value of P , and the structure of
its namespace. We do not distinguish between typing environments and execution
environments, as explained above, and omit the confinement mentions to lighten
writing:

(P, { (l1 , t1 , v1 ); . . . ; (ln , tn , vn ) }) ∈ EnvK

(Flat(P ))
E nvT , E nvV , Flat(P ) P lT ⊕ E nvT , P lV ⊕ E nvV ,
−−−−−−→
E nvK P lK ⊕ EnvK

knowing that:

P lT = { (li , ti ) | li ∈ P T }
P lV = { (li , ti , vi ) | li ∈ P V }
P lK = { (li , ti , vi ) | li ∈ P K }

The bindings of li inserted by the operation Flat(P ) make the bindings of P fields
directly accessible, avoiding to use the dot-notation.

The question now is to decide where this insertion takes place. By continuing to
consider that an environment is a list (in fact, a stack), they can be placed at the head
of the list. But if the program has already introduced a name identical to a field, then
there is a risk of masking. Suppose that EnvV already contains a binding (l, t, v) and
that l is also a field of P . Suppose that l ∈ P V , its type being tl and its value vl .
The operation Flat(P ) adds the binding (l, tl , vl ) to EnvV and, if this insertion is done
in the head of the environment, this binding (l, tl , vl ) hides the binding (l, t, v). The
current value of l becomes vl . This is the case in OCaml, as shown in the following
example. After the definition of a, EnvV is extended with the binding (a, int, 36).
After the definition of S, EnvK is extended with the binding (S, { a : int = 25 }).
The binding of a in EnvV is not modified. Then, the module S is flattened (by open S).
The binding (a, int, 25) is inserted in the head of (a, int, 36)⊕ EnvV , hence masking
of this last binding.
32 Concepts and Semantics of Programming Languages 2

E XAMPLE 1.13.–
OCaml
# let a = 36 ;;
val a : int = 36
# module S = struct
let a = 25
end ;;
module S : sig val a : int end
# a ;;
- : int = 36
# open S ;;
# a ;;
- : int = 25

Other choices can be made. In Ada, for example, the rule is that the operation
Flat() can never lead to hiding an identifier already occurring in the source code. The
field l of P is therefore not directly visible but can be used with the qualified notation
P.l.

Let us note that the very notion of library imposes acceptance of the fact that the
same field l can be exported by several kits. Flattening all of these imports with the
operation Flat() can lead to some maskings. It is necessary to consult the reference
manual of your programming language to determine how these potential maskings
are managed. Involuntary masking by the operation Flat() can lead to a runtime error
which is difficult to find.

Q UESTION 1.24.– Does M Y L have an explicit syntactic construct for exporting a kit?
For importing a kit? Otherwise, how does the language handle these operations?

Q UESTION 1.25.– Is it possible to flatten a kit? Can this operation mask bindings in
the source being written? Is there a way to remedy this masking?

Q UESTION 1.26.– Can flattening a kit overload an identifier?

1.3.7. Stages of kit development

The development of a software usually requires the construction of several kits.

We have studied the construction of a complete kit, therefore entirely defined by its
source code. This kit could be confined and, once its definition has been analyzed
by the language compiler or interpreter, it can be exported and then imported and
flattened.

A developer may wish to split the construction of a complete kit into several steps.
There are several mechanisms for this which are studied in the following sections and
which we briefly introduce here:
 Namespaces: Model and Operations 33

1) defining an incomplete kit only: at least one of the components is only

introduced by its declaration, its definition being deferred to a later stage of
development (see section 1.4);

2) generalizing the notion of kit by accepting that its definition may depend on
type variables or value parameters, the types and actual values being provided later.
We will call such a construction a parameterized kit (see section 1.5);

3) generalizing the notion of kit in a slightly different way to the one previous by
introducing functors of kits, that is, functions taking a kit as a parameter and returning
a kit (see section 1.6);

4) extending a kit by adding components to it (see section 1.7).

Creating an executable file from an incomplete (or parameterized) kit P can lead
to execution errors if the missing definition (or an unsupplied actual parameter) is
required at runtime. Compilers can detect some of these errors but the language can
also deliberately accept some of them, assuming for example that the missing values
will be obtained at runtime, via a URL for example. The possible absence of the
expected data at runtime must of course be treated by the kit P . To avoid such runtime
errors, the choice made by most languages is to restrict import to complete kits only.

1.4. Incomplete kits

In this section, we will disregard some of the assumptions presented in section

1.3.3. Until now, the fields of a kit were all introduced in the source code with a type
definition for the fields of N (P )T , a type and an expression defining their value for
the fields of N (P )V (and N (P )K ).

A kit is said to be incomplete if at least one of its fields, say l of N (P )V has

no definition. This field l, said to be not-defined, is therefore reduced to a declaration.
Most languages accepting this lack of definition require a not-defined field to be tagged
with a keyword such as abstract, virtual, etc., depending on the languages (be
careful, these keywords can have very different meanings in different languages). The
compiler can thus distinguish between an involuntary absence of a definition and an
explicit willingness to delay a definition. Here, we mark a not-defined field with the
keyword decl.

A not-defined field l of a kit P can be used in an expression e, which can be typed

because typing analysis only requires type information. But e cannot be
executed/evaluated since the value of l is unknown. From a runtime point of view,
this field l is therefore useless and P cannot be exported. The creation of incomplete
kits is therefore associated with the operation of field completion: the operation
34 Concepts and Semantics of Programming Languages 2

Def(P, l, exp) introduces the definition exp of the not-defined field l of the kit P . It
builds a new kit, noted here as Def(P, l).

1.4.1. Type and value of an incomplete kit

The not-defined fields being declared, the type of an incomplete kit is defined in
the same way as that of a complete kit:

PT ype = { l1 : t1 ; . . . ; ln : tn }

The value of an incomplete kit differs from that of a complete kit since some of its
fields have no execution value. By convention, we represent the absence of the value
of a field li by the notation ⊥i . With this notation, the value of an incomplete P is:

PV alue = { l1 = v1 ; . . . ; lj = vj ; . . . ; ln = vn }

where vi = ⊥i if li is tagged with decl.

Let lj be a field of P defined by an expression ej using the not-defined field li ,

thus marked by decl. The evaluation of ej in the current environment can be done by
binding li to ⊥i , producing a “value” vj which depends on ⊥i . Therefore vj is not
a runtime value: it is impossible to compute with it. To become a runtime value, vj
must be substituted with the value of the field li when this one is defined. In summary,
the fields lj of an incomplete kit have either the value ⊥j if lj is not-defined or a value
vj which is expressed using the values ⊥i of some not-defined fields li . Of course,
if the definition of lj does not use any not-defined field, its value can be completely
calculated.

1.4.2. Completion of an incomplete kit

Let P be an incomplete kit and li be a not-defined field of P . Let us note

Def(P, li , e) as the operation adding a definition to li with the expression e. This
operation, called completion, builds a new kit, Def(P, li ) as follows. The evaluation
of Def(P, li , e) in the environment Env is done in three steps:
1) the evaluation of the expression e in Env produces the value vi
2) the value ⊥i of the field li in PV alue is substituted by vi , a step which defines
the value of li in Def(P, li );
3) the values of the other fields of Def(P, li ) are updated: if the value vj of a field
lj depends on ⊥i , then ⊥i is substituted by vi in vj .
 Namespaces: Model and Operations 35

The value of Def(P, li ) is:

Def(P, li )value = { l1 = w1 ; . . . ; lj = wj ; . . . ; ln = wn }

where wi = vi and wj = vj [⊥i ← vi ] if j = i.

Now let us look at the type of Def(P, li ). Suppose the declaration of li assigned
it the type ti in P . Let t be the type of e. What could happen if ti = t? A simple,
general answer is to give only a definition having the same type as the corresponding
declaration. But some languages can lighten this rule, as detailed below.
– If the language is strongly statically typed, without parametric polymorphism,
without subtyping or overloading, without type parametrization, the definition of
li will be rejected by the compiler because it would lead to a typing error in the
definitions of the fields using li . If the system did not reject this ill-typed definition of
li , runtime errors could occur because some expressions of the other fields would then
be ill-typed.

– If the type language accepts parametric polymorphism, then there are two
questions. The first one is: can the compiler accept the definition of li if t is an instance
of ti ? In this case, type ti is of the form ∀ α.s and t = s[α ← ts ], ts being found by
the typing algorithm. For example, if ti = ∀α.α → bool, if t = int → bool, then
ts = int. But, li can already be used by some fields of P , whose typing has required
a different instantiation of α, string for example. So the completion will be rejected.

The other question is: can the compiler accept a definition, such that ti is an
instance of t? For example, ti is int list → int and t is ∀ α.αlist → α. The
definition can be accepted but the type ti will not be generalized, it remains identical
to int list → int. But there is often no benefit in this because, if a true polymorphic
definition is available, it suffices to use it directly. Some examples are given in section
4.3 which studies OCaml classes.

– In the other cases, the considered language can offer some form of compatibility
between types (subtyping, ad hoc polymorphism, which we will discuss later, etc.).
The definition of li could be accepted, provided that t is compatible with ti and that
typing can infer that the types of P and Def(P, li ) are compatible. If the completion is
accepted, the type of Def(P, li ) can be obtained by substituting ti by t in PT ype . And
the types of the other fields in Def(P, li ) may or may not remain the ones they had in
P . For example, if t is a subtype of ti , then the type of another field l from Def(P, li )
can be – or not – a subtype of the corresponding field l in P.l.

So, if ti = t, depending on the languages and even on the contents of P , the

definition may or may not be rejected. A simple general rule is to only give a definition
that has the same type as the corresponding declaration.
36 Concepts and Semantics of Programming Languages 2

We did not introduce a concrete syntax for the completion of an incomplete kit.
The syntax for completion varies a lot depending on the language. The completion is
often done using the syntax of the extension of a kit, a field being declared abstract
or virtual that will receive a definition in an extension (for example by inheritance).

1.4.3. Confining an incomplete kit

An incomplete kit P cannot be exported since this operation has only been
defined for complete kits. However, could we, by confining all the not-defined fields,
still export P by RP = From(P,M)? RP could thus be seen, by the importer, as a
complete kit. It would be a dangerous practice because any execution of a component
of the RP , whose definition in P uses a not-defined field of P , would lead to an
error. Usually, languages reject this export.

Some languages, however, allow us to confine a not-defined field in an incomplete

kit, without allowing it to be exported. The confinement marks are then used to
control the completion of the kit. The not-defined field must remain accessible to the
developer who will introduce its definition. This possibility receives various
treatments according to the confinement modes offered by languages. Examples will
be given in the presentations of some languages made in the following chapters.

We complete the list of questions as follows.

Q UESTION 1.27.– Does M Y L offer the possibility to build incomplete kits? What is
the syntax of such a construct?

Q UESTION 1.28.– What are the uses of incomplete kits provided by M Y L?

Q UESTION 1.29.– Must the type provided in the declaration of a field and the type of
its definition be the same?

Q UESTION 1.30.– Can a not-defined field of an incomplete kit be confined? Can this
confinement be modified or removed when this field is completed?

Q UESTION 1.31.– Can an incomplete kit be completed in several steps? Is it needed

to indicate that there are still fields to be defined?

1.5. Parameterized kits

1.5.1. kits parameterized by a type

Let us introduce the problem by using example 1.14. Let us suppose we have a kit
PInt which defines the type tlist of the lists of integers and tools for manipulating
these lists.
Discovering Diverse Content Through
Random Scribd Documents
 Mr. Steele. Yes.
Mr. Jenner. Point to the one on your left, which is 453-A, which is
Oswald?
(The witness has pointed to the figure of a man over whose
head there is a green cross.)
Mr. Jenner. Now, the second picture, which is 453-B, do you see
him on that one?
(The witness points to a man over whose head there is a green
vertical stripe.)
Mr. Jenner. And do you see him on the third picture, which is the
one identified as Exhibit No. 1? Point to him.
(Let the record show that the witness has indicated by pointing
the figure of the man identified as Lee Harvey Oswald.)
Mr. Jenner. Put an "X" on his body, if you will.
(Let the record show that the witness has put a red "X" mark on
the body of the man known to be Lee Harvey Oswald, and that he is
the same man shown in each picture, and so identified by the
witness.)
Mr. Jenner. Now, taking a look at 453-A, you see there is an
arrow over the head of a man to the left of the man over whose
head you put the green cross?
Mr. Steele. What's that?
Mr. Jenner. You see that arrow over the head of the man to the
left of the man with the green cross over his head?
Mr. Steele. Yes.
Mr. Jenner. Do you recognize this man over the head of whom
there is an arrow?
Mr. Steele. No.
 Mr. Jenner. Was he there the day that you were passing out this
literature?
Mr. Steele. Not that I could see at the time, but from previous
pictures that I have seen, he apparently was though.
Mr. Jenner. Previous pictures that you have seen from whom?
Mr. Steele. The FBI and the Secret Service.
Mr. Jenner. Are you shown on any of these pictures now?
Mr. Steele. Yes.
Mr. Jenner. You are?
Mr. Steele. Oh, am I shown?
Mr. Jenner. Yes.
Mr. Steele. No.
Mr. Jenner. Do you see yourself on any of these pictures?
Mr. Steele. No, I don't; not on these.
Mr. Jenner. Do you see anybody else on those pictures that you
now recognize as having been present on the first occasion, on the
occasion when you were there, other than Lee Harvey Oswald?
Mr. Steele. That I remember; no.
Mr. Jenner. No one else?
Mr. Steele. No.
Mr. Jenner. There was no incident on the day that you passed out
this literature?
Mr. Steele. No.
Mr. Jenner. And the police didn't come?
Mr. Steele. No.
Mr. Jenner. When was that, August 16?
Mr. Steele. I can't give the date on that; I don't know.
 Mr. Jenner. It was in August though, wasn't it?
Mr. Steele. It was in August all right, but I don't remember the
exact date.
Mr. Jenner. Do you remember that some people were taking
pictures?
Mr. Steele. Yes; I do.
Mr. Jenner. And you remember your girl friend calling you that
evening and saying you were on television?
Mr. Steele. Yes; she came over.
Mr. Jenner. She came over to your place?
Mr. Steele. Yes, sir. I remember now; she came over.
Mr. Jenner. Where were you then?
Mr. Steele. I was at work.
Mr. Jenner. Did you call the FBI then?
Mr. Steele. Yes, sir.
Mr. Jenner. And the FBI said what?
Mr. Steele. I had asked them about getting my picture off of
television, and they said they couldn't do anything about it, that
there was nothing wrong with it—that it was news.
Mr. Jenner. They couldn't interfere with the news media?
Mr. Steele. That's right.
Mr. Jenner. That's what they told you?
Mr. Steele. Yes.
Mr. Jenner. Did you call the television stations?
Mr. Steele. Yes, sir.
Mr. Jenner. What did you tell them?
 Mr. Steele. I asked them if they would take my picture off of the
television screen. I told them who I was, and I told them about it,
that I was the gentleman that had passed out the literature, and I
told them that my father was with the sheriff's office, and it wouldn't
be too good with him, and at the time didn't know what I was
passing out, until I had seen the cameras, and then looked at them,
and they said, "Well, all right then," and it never came on television
anymore, until the President's death.
Mr. Jenner. Describe this man who came along with Oswald.
Mr. Steele. Right now I haven't the slightest idea what he looked
like. I think, as I recall, he was about Oswald's height.
Mr. Jenner. Oswald was 5 foot 9. You say he was the same
height, or taller, or what?
Mr. Steele. Well, he wasn't shorter. He was either the same
height or slightly taller.
Mr. Jenner. Would it refresh your recollection if I told you that
when you were interviewed by special agents of the Federal Bureau
of Investigation on the 24th of November, 1963, that you told them
that he was aged 19 or 20 years, that he was about 6 feet tall,
slender built, dark hair, and olive complexion?
Mr. Steele. Yes.
Mr. Jenner. Was that the way you recall him?
Mr. Steele. Yes; he was slender built and about my complexion.
Mr. Jenner. You have dark skin?
Mr. Steele. Caucasian, dark.
Mr. Jenner. What would you say he weighed?
Mr. Steele. About 170, 175, I guess.
Mr. Jenner. How tall are you?
Mr. Steele. Six feet.
 Mr. Jenner. Would this man have been about your height?
Mr. Steele. I guess so, but it didn't seem like he was quite as tall
as I am.
Mr. Jenner. Do you think he was more slender than you?
Mr. Steele. Yes.
Mr. Jenner. How was he dressed?
Mr. Steele. Sport shirt, as far as I can remember.
Mr. Jenner. White or colored, or what?
Mr. Steele. I don't even remember the man right now, to tell you
the truth. I just have a very vague recollection of what he looked
like.
Mr. Jenner. But you are sure he was slender built?
Mr. Steele. Yes, sir.
Mr. Jenner. Now, you have the right, if you wish to exercise it, of
reading over your deposition and signing it, or you may waive that
right and let the court reporter transcribe your testimony, and it will
be forwarded direct to Washington. What do you prefer to do?
Mr. Steele. Well, I will do what you consider best.
Mr. Jenner. Well, you are willing to waive the necessity of reading
your deposition and signing it then?
Mr. Steele. Yes, sir.
Mr. Jenner. All right. Is there anything else that occurred that you
haven't told me about, or that I haven't asked you about, that would
be of assistance to the Commission?
Mr. Steele. No; I can't think of anything else.
Mr. Jenner. All right. Thank you for coming in voluntarily and
testifying.
 TESTIMONY OF CHARLES HALL
STEELE, SR.
The testimony of Charles Hall Steele, Sr., was taken on April 7,
1964, at the Old Civil Courts Building, Royal and Conti Streets, New
Orleans, La., by Mr. Albert E. Jenner, Jr., assistant counsel of the
President's Commission.

Charles Hall Steele, Sr., 1488 Madrid Street, New Orleans, La.,
after first being duly sworn, testified as follows:
Mr. Jenner. You are Mr. Charles Hall Steele, Sr., is that right?
Mr. Steele. Right.
Mr. Jenner. And you have seen the letter received by your son
from Mr. Rankin, general counsel of the President's Commission,
have you not?
Mr. Steele. Yes.
Mr. Jenner. You have read it?
Mr. Steele. Yes.
Mr. Jenner. Did you also read the documents that were enclosed
with that letter?
Mr. Steele. No, sir.
Mr. Jenner. Well, those documents, Mr. Steele, consist of Senate
Joint Resolution 137, authorizing the creation of the Commission to
investigate the assassination of President John Fitzgerald Kennedy;
the Executive Order No. 11130 of President Lyndon B. Johnson,
appointing that Commission and fixing its powers and its duties, and
a copy of the rules and regulations under which we take testimony
before the Commission and also by deposition, as in this case.
The Commission is directed to investigate all the facts and
circumstances surrounding or bearing upon the assassination of our
late President Kennedy. I am Albert E. Jenner, Jr., one of the various
members of the legal staff of the Commission, and we are here
today taking depositions of witnesses who may have in some way
touched the lives of the Oswald family during their residence here in
New Orleans.
You have told us that you have some concern about your boy in
this matter, and you have also told me of your position in this
community both as a family man and a public official. I think it will
be proper, due to the circumstances of your situation, to put a
statement from you into the record of these proceedings before the
Commission, and so, with your permission, I will ask you some
questions at this time.
Mr. Steele. All right.
Mr. Jenner. Now, you are a native-born American here, and your
wife is a native-born American, and all your children were born here,
is that right?
Mr. Steele. Correct.
Mr. Jenner. In and around this area?
Mr. Steele. Yes, sir.
Mr. Jenner. You are how old now, sir?
Mr. Steele. I am 44, but I will be 45 the 15th of August, this year
—1964.
Mr. Jenner. Do you have any children in addition to Charles Hall,
Jr.?
 Mr. Steele. I have a daughter Jacqueline; she's a twin to Charles,
and I have one boy Gerald, who is aged 13.
Mr. Jenner. Jacqueline, what is she doing?
Mr. Steele. She is at Mercy Hospital, a student nurse. She will
graduate in August.
Mr. Jenner. Now, tell me about yourself, Mr. Steele?
Mr. Steele. I am a deputy sheriff, attached to the Civil District
Court, and an officer of the court. I own a small business known as
the Liberty Coffee and Household Co.
Mr. Jenner. You are a service man, are you?
Mr. Steele. 23 years on active National Guard status, subject to
24 hours' notice.
Mr. Jenner. Were you in World War II?
Mr. Steele. I was.
Mr. Jenner. What was the nature of that service?
Mr. Steele. I was inducted right here in 1941, June or July; I
don't remember exactly, and I went on duty with the AFRTC, at Fort
Knox, Ky. That's the Air Force Replacement Training Center, at Fort
Knox, and then I was transferred to the 5th Armored Division, and
that division was sent to England, but I didn't go with them. I was in
the cadre that was sent to the Tank Destroyer Battalion at Camp
Forest, Tenn., and we pulled winter maneuvers, after which they
found that our unit was not ready to go overseas, so we were
disbanded and I was then sent to the 631st Tank Destroyer Battalion
at Camp Shelby, where I was a sergeant, and then I was sent to the
773d Tank Destroyer Battalion, and I finally ended up after 2 years
in Charleston, S.C., in charge of a G.U. ward, so I spent two lovely
years living off of Uncle Sam, and I was discharged as a staff
sergeant, and then I went to Fort Sill, Okla., in 1949, after being
commissioned in the National Guard in 1948, and received my field
commission in artillery, and I have stepped my way up to where I
am now a major, general staff, assistant G-4.
Mr. Jenner. All right; now tell me about your boy. Had he ever
been in trouble before this thing occurred?
Mr. Steele. He never had a police record, or anything like that.
Mr. Jenner. Are you Catholic?
Mr. Steele. My family is; I am not. I am Presbyterian, but the
children are Catholic.
Mr. Jenner. Then I take it your boy has never been in any serious
trouble?
Mr. Steele. He had better not be.
Mr. Jenner. You heard his story, didn't you, Mr. Steele, about what
happened on this occasion?
Mr. Steele. I started that story off with him from the minute he
hit that front door, and I have been right with him on down through
the FBI, the Secret Service, and everybody, right on through, and
this is the only time that he has ever been questioned outside of my
presence.
Mr. Jenner. Well, he is your son, and I know you have his welfare
in mind all the time, and there is a possibility that fathers might
become prejudiced in matters of this kind, but knowing him as you
do and being his father, and knowing his weaknesses and so forth,
do you think now that he is telling the truth about this?
Mr. Steele. Well, let me put it this way. In my experience, being a
battery commander and handling 60 to 70 men at one time, and I
have been in court, and with my experience and all that, I have
honestly tried to trick him, using the same tactics that you might say
the best attorneys would use, and I feel that he is honestly telling
the truth. I feel he has told that story over and over again in exactly
the same way, so that's the only conclusion I can come to. In my
own mind, I am positive he didn't know what he was doing at the
time.
Mr. Jenner. You gave him a good cross examination, in other
words, is that right?
Mr. Steele. Believe me, because I was under a nervous tension
over this, I'll tell you. I was just promoted in August, to my present
position, and actually I am not a State officer; I am a Federal officer,
and at the same time I had been in the middle of a campaign,
running for the democratic nomination for committeeman, and I am
a member of the pledged electors' group, and I advocate that I as a
Democrat am pledged to the choice of the Democratic Party, and I
just couldn't stand by and let something like this come up and take
that all away from me, so I certainly did cross-examine him, and I
got to the bottom of it, and I'm satisfied that he was not at fault. He
had a weak moment in which he saw a chance to make a couple of
bucks, but other than that, he didn't have the slightest idea of what
he was doing. I'm satisfied of that.
Mr. Jenner. Is there anything else that you would like to add to
what you have said, Mr. Steele?
Mr. Steele. No; I think that's about it.
Mr. Jenner. Now, you have the privilege, if you wish, to read and
sign your deposition, or you may waive that, and the reporter will
transcribe the deposition, and it will be forwarded direct to
Washington. What is your preference on that?
Mr. Steele. I will waive it.
Mr. Jenner. All right, Mr. Steele; thank you for coming in and
testifying voluntarily. I wanted your background in the record, in
view of the fact that your boy did have personal contact with Oswald
and particularly because of your position in the community, I wanted
your background in the record. Thank you very much.
Mr. Steele. I think I can promise you that he is not going to get
into any more trouble. We had that out over and over, and I don't
think he will be passing out any more leaflets.
Mr. Jenner. I think we all believe that, Mr. Steele; well, thank you
again for giving your statement. It will be of help to the Commission
in evaluating the testimony of your son, by showing his family
background, and so forth. Thank you.
 TESTIMONY OF PHILIP GERACI III
The testimony of Philip Geraci III, accompanied by his mother,
was taken on April 7–8, 1964, at the Old Civil Courts Building, Royal
and Conti Streets, New Orleans, La., by Mr. Wesley J. Liebeler,
assistant counsel of the President's Commission.

(Reporter's Note: The witness, Philip Geraci, was accompanied

into the hearing room by his mother.)
Philip Geraci, having been first duly sworn, was examined and
testified as follows:
Mr. Liebeler. My name is Wesley J. Liebeler. I am a member of
the legal staff of the President's Commission investigating the
assassination of President Kennedy. Staff members have been
authorized to take the testimony of witnesses by the Commission
pursuant to authority granted to the Commission by Executive Order
No. 11130, dated November 29, 1963, and joint resolution of
Congress No. 137.
I understand that Mr. Lee Rankin wrote you a letter last week in
which he told you that I would contact you, did he not?
Mr. Geraci. A letter? No.
Mr. Liebeler. You did not receive a letter from Mr. Rankin?
Mrs. Geraci. Would you please give us one. We would like to
have it to keep.
Mr. Geraci. Somebody said they sent one.
Mr. Liebeler. You didn't receive it?
 Mr. Geraci. No.
Mrs. Geraci. We did not receive it.
Mr. Liebeler. Now I think in point of fact that is right. I think that
the decision to take your testimony was made subsequent to the
time that the letters were sent out to other witnesses. Now you
are——
Mrs. Geraci. May I make a statement before we go any further?
Mr. Liebeler. Let the record indicate that Mrs. Geraci is in the
hearing room at her request to assist her son and give moral
support.
Mrs. Geraci. And we want no publicity at all, please.
Mr. Liebeler. We have already given to the reporters the names of
some of the witnesses who came in, but we have already been
advised that you did not want any publicity at this point, and we did
not give your name to the newspaper reporter or make any
statement about Philip's appearance here.
Mr. Geraci. Does that mean I can't tell anyone about it?
Mr. Liebeler. That is something you can settle among yourselves.
Mr. Geraci. I told everybody I went to a doctor's appointment this
evening.
Mr. Liebeler. [Handing documents to witness] Now I want to give
you a copy of the Joint Resolution of Congress and of the Executive
order that I have just referred to, and also of the Rules of Practice
adopted by the Commission concerning the taking of testimony of
witnesses. Those rules provide that technically you are entitled to 3
days' notice before you appear to have your testimony taken, but
you are entitled to waive that notice, and I assume that, since you
are here, you would be willing to waive it with regard to the
testimony. Is that right, Philip?
Mr. Geraci. I don't know.
 Mrs. Geraci. Yes. Well, they did not notify us 3 days ahead of
time, but that is all right. We are here. They called yesterday.
Mr. Liebeler. You have indicated that you are willing to go ahead
with the testimony instead of waiting for the 3 days' notice?
(Mrs. Geraci nodded assent.)
Mr. Liebeler. Philip, would you state your full name for the record,
please?
Mr. Geraci. Philip Geraci, the Third.
Mr. Liebeler. What is your address?
Mr. Geraci. 2201 Green Acres Road.
Mr. Liebeler. New Orleans?
Mr. Geraci. Metairie.
Mr. Liebeler. When were you born?
Mr. Geraci. February 21, 1948.
Mr. Liebeler. So you are now about 16 years old or 17 years old?
Mr. Geraci. Yes. Well, I am 16.
Mr. Liebeler. Do you go to school?
Mr. Geraci. Yes, sir.
Mr. Liebeler. Where?
Mr. Geraci. East Jefferson High School.
Mr. Liebeler. And you are—what?—a junior there now, or a
senior?
Mr. Geraci. No, sophomore, 10th grade.
Mr. Liebeler. 10th grade. Do you know a man by the name of
Carlos Bringuier?
Mr. Geraci. Yes, sir.
Mr. Liebeler. When did you first meet him?
 Mr. Geraci. Well, this was summer, last summer, some place
around the beginning of it, and—you want me to tell you everything
about it?
Mr. Liebeler. Yes.
Mr. Geraci. Well, I was down there with a friend. [Addressing
mother.] Do you think I should give his name?
(Mrs. Geraci nodded assent.)
Mr. Liebeler. Please do. You were down where?
Mr. Geraci. Down there in New Orleans, I mean on Canal Street.
We had to go to some radio shop. It was Bill Dwyer. That is a friend.
And we were down there and we wanted to go in radio shops and
everything, so I saw—going down there I saw, looking to the side,
that they had a sign saying "Casa Roca," and I took Spanish in
school, so I was interested, and I went in there and—well, he was a
little reluctant, but we went anyway.
Mr. Liebeler. Your friend was a little reluctant?
Mr. Geraci. Yes, a little bit. He didn't get mixed up in this or
anything. And then, well, when we were in there, we looked around
a little at everything, then I asked the man there—I didn't know it
was Carlos Bringuier then—I asked him was he a Cuban. He said
yes, he was an exile, and everything, you know. I asked him a few
things, I guess—I don't know exactly what—you know, just a little
conversation like. Then I ask him was there anything that I as an
American could do. He said, well, he didn't know, to come back later.
You know, he acted as though maybe—like—just like he just didn't
want me to help or something like that, I guess, so we left and went
home, and that was it.
Mr. Liebeler. And when did you see him again, if you did? You did
see him again, didn't you?
Mr. Geraci. Yes.
Mr. Liebeler. When?
 Mr. Geraci. I don't remember when. I remember I saw him a few
times, I couldn't exactly say how many, but I went back another
time when I was in town, I stopped off and saw him, and I saw him
another time. Then I think it was about the fourth time that I was
there that I saw Lee Harvey Oswald.
Mr. Liebeler. Now before we get to that, did you ever raise any
money for Carlos' activities?
Mr. Geraci. Not until the third time.
Mr. Liebeler. What happened?
Mr. Geraci. No; wait. Come to think of it, I think it was about the
fifth time that I saw Oswald; something like that. I remember I went
back—it was about the third time—after asking him—I asked him,
"Do you think it is possible to raise donations?" And he said, "Well,
yes; it is possible." And he showed me these little yellow slips, sort
of like yellow, and they were like receipts if you paid, and he said I
could get them—you know—if I wanted to, I could, you know, go,
and he could give them to me, and go and get donations and give
the people this receipt and bring the money back to him.
Mr. Liebeler. So did you take some of the receipts?
Mr. Geraci. Yes.
Mr. Liebeler. And did you get some money?
Mr. Geraci. Yes.
Mr. Liebeler. And you gave it to Carlos?
Mr. Geraci. Yes; it was about $10.
Mr. Liebeler. And you turned that money over to him?
Mr. Geraci. Yes, sir.
Mr. Liebeler. Now, is it correct that on the day that you came into
the Casa Roca to give this money to Carlos that you met Lee
Oswald?
 Mr. Geraci. I don't know if I turned in the money or not. No; I
don't think I turned in money, but I couldn't be sure. I remember I
went there, and that is the time the last guy, Vance Blalock, came
along with me. It was his first time and everything. And we went in
there—I might have turned it in, I am not too sure. Maybe I did;
maybe I didn't. I can't remember too much, but I was in there
anyway talking to him and that is when I met him.
Mr. Liebeler. That is when you met Oswald?
Mr. Geraci. Yes; you want me to tell all that?
Mr. Liebeler. Yes; tell me all the circumstances of how Oswald——
Mr. Geraci. Everything I know?
Mr. Liebeler. Met you and everything you know about it, what the
conversation was, who was there.
Mr. Geraci. Well, we were—Vance and me went in there, Vance
and I, we went into there, I introduced Vance to Carlos, and Carlos
started talking to him about, you know, freedom and all that,
democracy and everything. Then later on while we were talking, Lee
Oswald came in, you know, while we were talking, and he came in a
little while later. He was by himself and he seemed a little nervous. I
remember he was dressed just like in that picture there shows.
[Indicating photograph.]
Mr. Liebeler. You are referring to a picture here on the table?
Mr. Geraci. Yes, sir; well he was dressed something like that.
Mr. Liebeler. Which has previously been marked as Exhibit 1 to
the affidavit of Jesse J. Garner. I show you that picture. [Exhibiting
photograph to witness.] You say Lee was dressed something like
that when you met him?
Mr. Geraci. Yes; you know, he had on a tie and a shirt, short
sleeved shirt, and sort of like dress pants. I don't know the color of
them, but they were sort of like dress pants, just about as much as
this. [Indicating photograph.]
 Mr. Liebeler. Do you recognize that individual in the picture as
being the man that you saw in the store that day?
Mr. Geraci. Well, tell you the truth, when I first heard about it in
the papers and on the TV, I didn't recognize him. See, I forgot that I
met this guy over there, you know, I forgot about it, and I thought I
didn't meet him. It wasn't until the FBI man came to my house and
he showed me a picture of him when he was first under arrest, and
he got arrested in August, the 4th I think.
Mr. Liebeler. He showed you a picture that had been taken of Lee
when he had been under arrest here in New Orleans?
Mr. Geraci. Yes; it was one of those things with three things,
showing him from the front, the side, and his face.
Mr. Liebeler. Did you then recognize the man in the picture that
they showed you as being the man that you met in the store that
day?
Mr. Geraci. Well, you see, I didn't exactly recognize him maybe,
but anyway I was pretty sure it was him though. He said—he
showed me that and said, "Do you ever remember an ex-marine—
and then I remembered there was a guy who was dressed
something like that who was an ex-marine who came in, and he did
have a funny name, you know, like Lee. It's a little unusual, it's kind
of rare, and I remembered the last name was a little hard, so it just
fits that that was him.
Mr. Liebeler. Now what kind of conversations did you have with
this fellow or what did you talk about?
Mr. Geraci. Well, first——
Mr. Liebeler. As I understand it now, there were this marine, Lee
Oswald, and Carlos, and Vance Blalock and yourself. Is that right?
Mr. Geraci. Yes, sir.
Mr. Liebeler. Was there anybody else there?
 Mr. Geraci. Well, while we were talking, this man came up. He
was in a big truck, some big truck. I never looked at it closely. He
came up and stopped, and the man rushed in, and he was wearing
—well, he was wearing one of these—like a cap like you see them
wearing over in England. I don't know what kind it is, but anyway it
is the kind that truckdrivers wear, I guess, and he looked kind of
Spanish. Maybe he was a Cuban exile. He was kind of fat, and he
came in and showed Carlos this broken radio that he had, so Carlos
left and he started fixing the radio and left us to talk to ourselves,
Lee and me and my friend. Well, he is the only other person I know
that came in. I don't know if he knew what was going on.
Mr. Liebeler. Now tell us the conversation that you and Lee and
Vance and Carlos had, the best you can recall it.
Mr. Geraci. Well, Carlos and me and Vance were kind of talking
among ourselves, and he came in and said, "Excuse me," and, you
know, he acted a little nervous and things like that. He asked, "Is
this the Cuban headquarters, Cuban exile headquarters?" And, "Are
you a Cuban exile?" You know, the way I acted when I first went in
there. Just asked him a few questions, was he a Cuban exile, and
Carlos said yes. He asked him some questions like was he connected
with the Cosa Nostra, La Cosi Nostra.
Mr. Liebeler. Who asked that?
Mr. Geraci. Oswald; he asked that.
Mr. Liebeler. Of Carlos?
Mr. Geraci. Yes; and Carlos said no, he wasn't. Oswald then
asked where was his headquarters—in Miami? And Carlos said yes;
and he said—let's see—and then Oswald asked, said something like,
"It is kind of exciting meeting someone"—I don't know if he said
exciting—but he expressed something like that. He said, you know,
he expressed wonder or something like that at meeting somebody
who was a real Cuban exile, you know, someone who is really trying
to do something to help free Cuba and all that. He didn't really say
much. In the papers they said he tried to join and all that. That must
have been later, because this was——
Mr. Liebeler. He didn't do that when you were there?
Mr. Geraci. No. This was his first visit. As far as I can make out, it
must have been, and he asked a few questions like that. Carlos just
answered real simply and all that, he didn't go into any big
speeches, you know, with them, like he did for me and Vance, just
answered his questions simply. Then when the man came in with the
broken radio, Carlos left, and that left Oswald, me, and Vance by
ourselves.
Then, well, we asked—you know, we were a little interested in
guerrilla warfare ourselves and things like that, and he said, well, he
was an ex-marine, said he was in the Marines once. He said he
learned a little bit about that stuff, and he said a few things about
guerrilla warfare I remember, like he said the way to derail a train
was to wrap chain around the ties of the track and then lock it with
a padlock and the train would derail. He said the thing he liked best
of all was learning how to blow up the Huey P. Long Bridge. He said
you put explosive at each end on the banks and blow it up, and that
leaves the one column standing. And he said how to make a
homemade gun and how to make gunpowder, homemade
gunpowder. He just went into those real simply. He didn't really, you
know, tell us how to do it or anything, just said like if you want to
make a homemade gun, you know, do something like—you know,
the thing you pull back [demonstrating] and it goes forward, like on
one of the pinball machines. He just said something like that. He
didn't really go into detail or anything. We didn't ask him. And by
this time Carlos came back from the other guy, and came back, and
he was listening, and, well, that is about all.
Oh, there was one important thing. Oswald said something like
that he had a military manual from when he was in the Marines, and
he said he would give it to me, and I said, "That is all right. You
don't have to. You can give it to Carlos." He said, "Well, OK, he will
give it to Carlos next time he comes."
 And after that—well, everybody left. That is as far as I can make
out.
Mr. Liebeler. Do you remember——
Mr. Geraci. And he said he was going to come back later and give
Carlos this military manual from when he was in the Marines.
Mr. Liebeler. And was he going to give this to Carlos for Carlos'
benefit, or was he——
Mr. Geraci. For Carlos' benefit, I guess, Carlos' or the Cuban
exiles'.
Mr. Liebeler. Did you hear any conversation about training
guerrillas to oppose Castro?
Mr. Geraci. No. He didn't say anything about being an expert rifle
shooter, never said anything about going to Russia or joining or
training or anything like that.
Mr. Liebeler. Well, was there a conversation concerning the
training of anti-Castro troops or guerrillas to oppose Castro?
Mr. Geraci. No; that must have been later, maybe when he came
back some other time.
Mr. Liebeler. Now were you present at all times while Oswald was
there?
Mr. Geraci. We got there before he did and we left at the same
time he did.
Mr. Liebeler. So, as far as you know, there wouldn't have been
any opportunity for Oswald and Carlos to talk among themselves
where you wouldn't have heard what they said?
Mr. Geraci. That is right; because we were there all the time.
Mr. Liebeler. And you have no recollection that Oswald told Carlos
that he wanted to help train anti-Castro guerrillas to fight against
Castro?
Mr. Geraci. None at all; none that I remember.
 Mr. Liebeler. All right. Now what was Oswald going to bring this
marine book back for?
Mr. Geraci. Well, I guess to give to Carlos to help him out or
something. First he was going to give it to me and Vance. I guess he
wanted us to blow up the bridge or something. I don't know. We
said no; and so he said, "OK, I will give it to Carlos," you know,
because after all Carlos—I guess he could use it better than we
could, you know, blow up bridges in Cuba or something, and I guess
he was just going to give it to him so he could learn some stuff from
it. I wouldn't know.
Mr. Liebeler. Now when you left the store did you try to follow
Oswald at all?
Mr. Geraci. Well, we had some thought about it. When he left, he
was going to go down—he crossed Canal Street and he was—he
kept on going that way, I think on St. Charles or Claiborne—way
down there near the end—which one is closer to the river? St.
Charles?
Mr. Liebeler. I am not familiar with New Orleans, so I get them
mixed up.
Mr. Geraci. It must have been St. Charles he went down, and
Vance said, "Hey, let's follow him, see where he lives." He told us
where he lived, but the way he told us the address——
Mr. Liebeler. You don't know what it was?
Mr. Geraci. When the FBI man came by my house that day, he
asked me, and I could just barely remember it. I remember it was to
the left of Canal Street. It was Magazine Street.
Mr. Liebeler. Magazine Street? What number?
Mr. Geraci. Well, I remembered the number a little. I couldn't
remember it altogether, but I remember——
Mr. Liebeler. Do you remember that he had told you the number?
 Mr. Geraci. Yes; and I could—I had a few—I mean I had a little
recollection about what it was, like it was a big number sort of like
and had two zeros in it or something. I don't even remember. It
seemed that his number did have that. We decided—we thought
maybe we can follow him for fun, but we decided no, we had better
not, you know, because it was not good or anything, so we just
went up Canal Street.
Mr. Liebeler. Do you remember whether Oswald said anything
about having been in Florida?
Mr. Geraci. In Florida?
Mr. Liebeler. Yes.
Mr. Geraci. I am not too sure about that.
Mr. Liebeler. You don't remember one way or the other
whether——
Mr. Geraci. The only thing I remember about Florida is when he
asked was headquarters down there. He could have, but I don't
know.
Mr. Liebeler. Now did you ever see Oswald after that?
Mr. Geraci. No; that was the last time; first and last.
Mr. Liebeler. How about Carlos? Did you see him after that?
Mr. Geraci. Yes. That time when we found out that it was Oswald
who killed him, well, then I went there, you know, to get things
straightened out and talk with Carlos a little about him, you know.
Mr. Liebeler. You went back and talked with Carlos, about this
meeting with Oswald, after the assassination? Is that right?
Mr. Geraci. Yes.
Mr. Liebeler. Do you remember whether you saw Carlos between
the time that you met Oswald and the assassination?
Mr. Geraci. Carlos?
 Mr. Liebeler. Yes.
Mr. Geraci. Not that I remember.
Mr. Liebeler. Can you tell us approximately when it was that you
met Oswald? Was it July or August?
Mr. Geraci. Well, last time the FBI man came, I estimated around
late July. I couldn't remember now, so I will just stick with late July.
That seems to stick pretty good. Vance said the same thing himself
when the FBI man questioned him, so I am pretty sure it was
between late July—middle July to late July.
Mr. Liebeler. Did you form any opinion about Oswald when you
met him?
Mr. Geraci. When I met him?
Mr. Liebeler. Yes. What did you think of him?
Mr. Geraci. Well, when he went in there, I noticed he was a little
nervous.
Mr. Liebeler. How did he show his nervousness? Do you
remember?
Mr. Geraci. Well, the way he talked, you know. Well, you know,
the way he talked I guess, kind of, you know, searching around for
words and all that, and I remember he leaned on the table, and I
remember reading once that, you know, if you exert some physical
exertion, it kind of helps you tend to calm down or something like
that. Anyway, I could tell by the way he was leaning on the table
that maybe he was nervous.
Mr. Liebeler. Other than this nervousness, did you form any other
opinion about it?
Mr. Geraci. Not particularly.
Mr. Liebeler. Did he appear to be an intelligent person?
Mr. Geraci. Intelligent person?
Mr. Liebeler. Yes.
 Mr. Geraci. Sort of. He didn't appear stupid or anything like that.
He seemed OK, you know. He didn't seem like a Communist.
Seemed like he just wanted to, you know, help out too, sort of.
Mr. Liebeler. Did you subsequently learn that Oswald was
arrested by the New Orleans Police Department for distributing Fair
Play for Cuba Committee leaflets?
Mr. Geraci. I didn't know that until after he killed Kennedy and it
was in the papers.
Mr. Liebeler. You didn't hear it?
Mr. Geraci. On the radio?
Mr. Liebeler. On the radio or television.
Mr. Geraci. No.
Mr. Liebeler. Do you think you have now told us everything that
you can remember about this meeting you had with Oswald and
Carlos? Is there anything else that you can think of?
Mr. Geraci. No. There might be one thing. Carlos, when he talked
to me and Vance and my friend, Bill Dwyer, the first time, you know,
he made speeches and all that. When he met him—I don't know—
seemed like maybe he didn't want him or something. I am not too
sure.
Mr. Liebeler. Carlos didn't seem to open up to Oswald?
Mr. Geraci. That is right. He opened up enough, you know, but
he didn't give him any speeches or anything like that.
Mr. Liebeler. If you can think of anything else that occurred, we
would like to have you tell us.
Mr. Geraci. OK.
Mr. Liebeler. If you can't, I don't have any other questions.
Mr. Geraci. He did seem like—I guess he did seem like the type
who was a little antisocial.
 Mr. Liebeler. He didn't seem to be too friendly?
Mr. Geraci. No. He seemed friendly. I mean, he seemed friendly,
you know, but he—maybe like he didn't have enough experience
with people, sort of. He seemed friendly though. That is one thing.
Mr. Liebeler. I don't have any other questions.
Mrs. Geraci. Do you have a record of me reporting Carlos to the
FBI? Do you have that in the record anywhere where I found out—
he told me he was going to collect money for Cuba, but I didn't
know he was giving out these little tickets as he called them, and
then when I found out he had collected $10 and brought it down
and I saw the receipts and he had more tickets, we forbade him to
go down there, and Carlos called the house to try to get him a—
what is it—a license or permit to go from house to house and collect
money.
Mr. Geraci. He never called me.
Mrs. Geraci. He did call me.
Mr. Geraci. He called you? Carlos?
Mrs. Geraci. I spoke with him on the phone.
Mr. Geraci. That is because I told him—when I collected, a man
told me to do something like that, that I needed a license, so I went
and told Carlos, "You have to get a license." He said, "Don't collect
any more until I get one." Then he went to city hall and got some
stuff he had to fill out.
Mr. Liebeler. This wasn't Oswald who told you you couldn't
collect?
Mr. Geraci. No.
Mr. Liebeler. Oswald didn't have anything to do with this?
Mr. Geraci. No; this was before I knew Oswald. This is a man
works some place—who works in a cleaner's, I remember. I went
there and he said I had to get a license to do that, so I called Carlos
on the phone and told him.
Mrs. Geraci. Then when Carlos called the house, I realized he
was still involved in this.
Mr. Geraci. I told you I was.
Mrs. Geraci. I put my foot down and told him he couldn't do it
any more, and I called the FBI.
Mr. Geraci. And the Better Business Bureau.
Mrs. Geraci. They told me to call the Better Business Bureau, but
the man at the FBI told me he couldn't give out any information as
to whether this was a Communist organization or not, and the
headquarters were in Miami, and the best thing to do would be not
to let him get involved in it any more. Then I called the Better
Business Bureau, and they were supposed to check with Miami, but I
never did get a report back from him.
Mr. Liebeler. Was this before or after you met Oswald?
Mr. Geraci. This was before.
Mrs. Geraci. But he has the receipt at home with the date on it.
When he gave Carlos money, Carlos gave him a receipt.
Mr. Geraci. I remember Carlos making out a check to give the
money to Miami too. When I gave him the money, he put the money
in his bank and made out a check to the headquarters.
Mrs. Geraci. We met Carlos just now in the hall, and he told me
the best thing Philip could do would be listen to his parents and be a
good student. Right now that would be the way he could help
combat communism. And I told him I thought he was too young to
get involved in things like this, selling tickets for Cuba and all this
stuff. Last year he was only 15 and too young to be involved in all
that mess. The man at the FBI told me that an organization could be
all right today and next week it would be Communist-controlled and
how was I to know.
 Mr. Liebeler. Do you know who you talked to at the FBI?
Mrs. Geraci. Gee, I may have his name at home with these slips
of paper that I took from him.
Mr. Liebeler. It is not really important. I just wondered if you
remembered.
Mrs. Geraci. Well, I wanted his name cleared for getting mixed
up with Carlos, because I didn't know from beans about Carlos. He
could be a Communist. I don't know who is and who isn't. When I
found out he met Oswald, I nearly died. The week this happened he
was camping with the Boy Scouts and gone Friday, Saturday, and
Sunday when the stuff was on TV.
Mr. Geraci. I was in school when he got shot.
Mrs. Geraci. But you were in camp, but you didn't see a lot of the
funeral and all that stuff showing Oswald's picture.
Mr. Liebeler. How did you first become aware that Oswald was
the fellow you met? Did Vance talk to you about it? Do you
remember?
Mr. Geraci. The first time was when the FBI agent came to my
house and asked did I see an ex-marine and showed a picture and
all that. I didn't even know it before that. It was just then that I
realized.
Mr. Liebeler. Did the FBI man tell you how he——
Mr. Geraci. Got my name?
Mr. Liebeler. What prompted him, why did he come to your
house? Did he tell you?
Mr. Geraci. Well, he said he couldn't tell me that. I asked him,
and he said, well, he couldn't tell me. Of course, I guess it might
have been because we—my mother called, you know, about this
Cuban business—they got my name on their list or something, I
guess, and when they found out that he tried to join that group, that
must have been where it came from. That is what I think.
 Mrs. Geraci. They probably had a list of people who were
collecting money for the organization.
Mr. Liebeler. OK, I don't have any more questions. I do want to
thank you very much for coming in and being as cooperative as you
have, and, on behalf of the Commission, I want to thank you very
much.
Mr. Geraci. OK.
Mrs. Geraci. You are welcome, so long as we don't have any
publicity.
Mr. Liebeler. That is something you never can guarantee.
 TESTIMONY OF VANCE BLALOCK
The testimony of Vance Blalock, accompanied by his parents,
was taken on April 7–8, 1964, at the Old Civil Courts Building, Royal
and Conti Streets, New Orleans, La., by Mr. Wesley J. Liebeler,
assistant counsel of the President's Commission.

Vance Blalock, having been first duly sworn, was examined and
testified as follows:
Mr. Liebeler. My name is Wesley J. Liebeler. I am a member of
the legal staff of the President's Commission investigating the
assassination of President Kennedy. Staff members have been
authorized to take the testimony of witnesses by the Commission,
pursuant to authority granted to the Commission by Executive Order
No. 11130, dated November 29, 1963, and joint resolution of
Congress No. 137. I understand, Vance, that Mr. Lee Rankin, who is
general counsel of the Commission, wrote you a letter last week——
Mr. Blalock. That is right.
Mr. Liebeler. And told you that I would be in touch with you
concerning the taking of your testimony. I understand that Mr.
Rankin enclosed with that letter a copy of the Executive order and of
the resolution of Congress to which I have just referred, as well as a
copy of the rules of procedure adopted by the Commission
governing the taking of the testimony of witnesses. Did you receive
that letter and those documents?
Mr. Blalock. Yes; I did.
 Mr. Liebeler. We want to inquire very briefly of you concerning an
event which occurred some time in the summer of 1963 here in New
Orleans. We understand that you were present at a meeting, a
chance meeting, between Lee Harvey Oswald and Carlos Bringuier.
Before we get into the details of that, however, would you state your
full name for the record.
Mr. Blalock. Vance Douglas Blalock.
Mr. Liebeler. Let the record show that your mother and father are
here in the room with us. How old are you, Vance?
Mr. Blalock. I am 16.
Mr. Liebeler. Where were you born?
Mr. Blalock. Lake Charles, La.
Mr. Liebeler. Where do you live now?
Mr. Blalock. Metairie, La.
Mr. Liebeler. How long have you lived there?
Mr. Blalock. Less than a year.
Mr. Liebeler. Do you go to school?
Mr. Blalock. Yes, sir.
Mr. Liebeler. Where?
Mr. Blalock. East Jefferson High School.
Mr. Liebeler. What grade are you in at East Jefferson High
School?
Mr. Blalock. Tenth.
Mr. Liebeler. Do you know Carlos Bringuier?
Mr. Blalock. I have met him once.
Mr. Liebeler. How did it happen that you met him?
 Mr. Blalock. I went downtown with my friend, Philip Geraci. We
went to a store to return funds that Philip had collected for the
organization this man had had, and while I was there I met Carlos.
That is how I met him.
Mr. Liebeler. Did you have anything to do with these funds that
were collected by your friend Geraci?
Mr. Blalock. No, sir; I didn't.
Mr. Liebeler. That was entirely his operation?
Mr. Blalock. Yes.
Mr. Liebeler. Do you remember where you went that day with
Philip?
Mr. Blalock. Yes, sir; we went to Decatur Street, I believe it is. I
am not sure. The store is the Casa Roca.
Mr. Liebeler. What organization was it that Bringuier was
running? Do you know?
Mr. Blalock. I couldn't say the Spanish name. The American
name of it is the Cuban Student Revolutionary Organization.
Mr. Liebeler. Can you tell me approximately when that was?
Mr. Blalock. Last part of the summer. I couldn't——
Mr. Liebeler. Late July or early August would it be, or some time
in August of 1963?
Mr. Blalock. August would be the closest I could get. I don't
remember the exact date.
Mr. Liebeler. Tell me the conversation that you and Philip had
with Bringuier when you went into the store.
Mr. Blalock. Oh, we entered the store and Philip introduced me
to Carlos, and I told him—I saw the funds Philip had collected for
him, and I told him I was curious about what it was for, and then he
explained for me how the organization worked and told me he
received the funds from people in New Orleans and sent it to Florida,
and that was his total business, and he explained that Communism
was where the kids are supposed to tell everything on their parents,
to obey the State and not their parents.
Mr. Liebeler. Present at this conversation were just you and Philip
and Carlos? Is that right?
Mr. Blalock. No; there was another man—must have worked at
the store. He was present.
Mr. Liebeler. Did you know what his name was?
Mr. Blalock. No, sir.
Mr. Liebeler. Now while you were there in the store, did you
notice anybody else present?
Mr. Blalock. Well, a man from a moving company or some
trucking company came in. He had a radio that needed to be fixed, a
broken radio, and Lee Harvey Oswald came in.
Mr. Liebeler. Tell us, to the best of your recollection, the things
that happened as far as Oswald was concerned.
Mr. Blalock. He walked up to us and leaned against the desk and
listened to the conversation. Then he started asking questions about
the organization, and we were talking about guerrilla warfare, just in
case the country got in war how young students could help,
something in that nature, and then he started—then Oswald, Lee
Harvey Oswald, asked Carlos Bringuier all about the organization
and what part it played in the main movement in Florida.
Mr. Liebeler. Did they say anything else? Was there more to the
conversation?
Mr. Blalock. Let's see.
Mr. Liebeler. Did this man who walked up introduce himself by
name?
Mr. Blalock. I believe so, but I don't remember what name he
gave.
 Mr. Liebeler. Are you now convinced that he was Lee Harvey
Oswald?
Mr. Blalock. Yes, sir. I know his face. I recognized his face.
Mr. Liebeler. But you don't remember that he mentioned the
name Lee Harvey Oswald at that time?
Mr. Blalock. No.
Mr. Liebeler. Did Oswald say anything about having been a
Marine?
Mr. Blalock. Yes, sir; he did, and he explained that he took
training in guerrilla warfare, and he told us how to blow up bridges,
derail trains, make zip guns, make homemade gunpowder.
Mr. Liebeler. He told you about this in detail?
Mr. Blalock. He told us how to blow up the Huey P. Long Bridge.
Mr. Liebeler. Tell us just what he told you about that. I know you
can't remember the exact words, but you can remember the
substance of the conversation. We want you to tell us about it.
Mr. Blalock. He told us to put powder charges at each end of the
bridge from the foundation to where the foundation meets the
suspension part, and to blow that part up and the center part of the
bridge would collapse.
Mr. Liebeler. Did he talk about any other aspect of guerrilla
warfare that you can remember?
Mr. Blalock. He said that if you don't have the materials you need
always available, you had to do without stuff.
Mr. Liebeler. Did he give any specific example of that?
Mr. Blalock. Gunpowder, high explosives.
Mr. Liebeler. Did he tell you how to do without gunpowder in
these activities?
Mr. Blalock. He told us how to derail a train without gunpowder.
Welcome to our website – the perfect destination for book lovers and
knowledge seekers. We believe that every book holds a new world,
offering opportunities for learning, discovery, and personal growth.
That’s why we are dedicated to bringing you a diverse collection of
books, ranging from classic literature and specialized publications to
self-development guides and children's books.

More than just a book-buying platform, we strive to be a bridge

connecting you with timeless cultural and intellectual values. With an
elegant, user-friendly interface and a smart search system, you can
quickly find the books that best suit your interests. Additionally,
our special promotions and home delivery services help you save time
and fully enjoy the joy of reading.

Join us on a journey of knowledge exploration, passion nurturing, and

personal growth every day!

ebookbell.com