| Disclaimer: This page gives only very few and small, in no way representative glimpses of the structure of programming languages. More such glimpses may be added any time (although currently, this is not very likely). If you have such glimpses or know some references, please don't hesitate to tell me (Ulf Schünemann), likewise if you have any suggestions. |
[COInh] Patrick Steyaert, Wolfgang DeMeuter: A Marriage of Class- and Object-based Inheritance Without Unwanted Children; ECOOP'95.
| Cf. linguistics: syntactic categories (lexical and phrasal). |
syntactic domain : semantic domain
:
binding
NAME -------------------> DENOTABLE
A : refers to A
| : represents |
IDENTIFIER -+ : symbolizes +- MEMORY OBJECT
OPERATOR -+ : denotes +- CONCEPTUAL RELATUM
certain keywords -+ : means `- DYNAMIC RELATA
LITERAL -+ :
NUMERAL -' : |
|
DENOTABLE is defined as the semantic domain of all those things to which NAMEs can refer. --> Names
Binding. "A binding is an association between two things, such as a name and the thing it names" [ScottP 106]. Bindings can be predefined, explicitly specified by declarations in the program, or implicitly by the (first) use of a name.
syntactic domain : semantic domain
:
1. first block's env.
abc --------------------> int variable with value 3
`- --------------------> string variable with value "3"
second block's env.
:
:
2. packageA's env.
abc --------------------> some function
`- --------------------> another function
packageB's env.
:
:
3. x's env.
abc --------------------> field abc in x
`- --------------------> field abc in y
y's env.
:
:
4. struct-env.
abc --------------------> a record type
`- --------------------> an integer variable
untagged env.
:
: |
Ambiguity 1: Vocabulary-Ambiguity. The same word may mean different things in different referencing environments (binding relations). For example, there are two different abcs
{ const int abc = 3; ... print(abc); } and{ const string abc = "3"; ... print(abc); }.
packageX::abc() and
in packageY::abc().
x.abc and
in y.abc,
where x and y are two different records/objects
(of two same or different types).
f(struct abc) and
in f(abc)
in the language C, because the former designates the word abs in the "tagged namespace" of structure types,
whereas the latter designates the word abs in the "untagged namespace".
| -> | meaning |
print("Do you know the abc?").
var abc; or
type abc = int;
abc := 3;
abc := 3,
in the position of a function's by-reference parameter,
swap(abc,a[2]),
or as argument to C's address-of operator,
&abc.
usage xyz::abc.
var x : abc;,
or in a type definition,
type x = abc;
or class x extends abc { ... }
sizeof a[2] (a constant expression),
or Eiffel's like abc (a dynamic type).
abc + 3, and
abc < 3, etc.
abc(3),
or if used as without parentheses in a value position,
f = abc, and
f(abc).
f(abc()),
or right to new,
f(new abc).
| -> | referential transparency |
Overloading«A name that can refer to more than one object in a given scope [referencing environment?] is said to be overloaded. (Contrast this notion to that of aliases, in which two or more names refer to a single object in a given scope.) Semantic rules for overloading require that the specific context of each individual use of the name contain sufficient clues to deduce which meaning (binding) is intended» [Scott 144].
|
| ||
Genericity.«Where a polymorphic subroutine is a single object capable of accepting arguments of multiple types, a generic subroutine allows the programmer to create multiple objects that accept arguments of different types. If desired, Ada allows the resulting objects to share a single, overloaded name. C++ requires them to do so. Clu does not define new names at all, but rather includes the "generic parameters" in every instance of the name (e.g., min[date](my_date))» [Scott 148]. |
| ||
Fortran-like languages:
| Lisp-like languages:
| ||
|
|
(a) The memory-object model:
| OBJECT = VARIABLE |
binding
NAME -----------------. syntactic
···········································v·····································
DENOTABLE semantic
A
.==================+========+========"===+=============================+======.
| | | | points-to | |
| .------> VALUEABLE ARRAY POINTABLE <----------------. | NAMESPACE
| | A <> A | |
| | .===="====. | .========"========. | |
| | | | | | | | |
| | | | | | operations | | |
| | "REFERENCE" +-----------+ ---------> FUNCTION | |
| | `------>| OBJECT/ | (incl. =,+,++,[]) | |
| | refers | VARIABLE | | |
TYPE <--|-------------- +-----------+ -----------> VALUE | |
A A | instance-of A A value STORABLE | |
| | | / \ A A | |
... ==' | | / BASIC / \ | |
| | fields / VARIABLE / BASIC-VALUE | |
CLASS, `-------<> STRUCT / A | |
STRUCT, VARIABLE STRUCT |`== POINTER |
UNION <--------- /INSTANCE ----------------> VALUE `=========== NAMEABLE VALUE
instance-of value (numbers, enumerators, ...)
|
(b) The implicit reference semantics model:
| OBJECT not DENOTABLE |
binding
NAME --------------------. syntactic
··········································v·····································
DENOTABLE semantic
A
.=========================+==========="==========+=================+======.
| | | | |
TYPE .--------> VALUEABLE .==="===. | PACKAGE
A A | A | | |
| | |.-------------|-------------> FUNCTION | |
| | || | | |
| | || | operations | |
| BASIC || inst +----------+ ----------> OPERATOR-ON-VAR |
| TYPE <----||--------| (BASIC) | (=, ++, ...) |
| || of | VARIABLE | |
CLASS || +----------+ ----------> (BASIC)-VALUE |
^ || value STORABLE |
| fields <> operations A |
| +-----------+ | |
| | OBJECT/ |<-------------------- POINTER =='| |
| | POINTABLE | points-to | |
| +-----------+ `========== NAMEABLE
| inst. A A VALUE
| of / \ (numbers, ...)
`--- INSTANCE ARRAY
|
SUBCLASS- ROOTCLASS-
DECLARATION DECLARATION
| | syntactic
·····|··················|······························
| defines | defines semantic
| |
v inherit v instantiate
DELTA -------+--> GENERATOR --------------> OBJECT
| |
`-------'
|
| Object = | Name -+-> Attribute | the external view of a (properly encapsulated) object is an interface allowing to identify some attributes (operations and instance variables) (a partial map) | |||||||||||||||||||||||||||||||||
|
class-based:
Generator = | OID --> Object
| (a class as) a generator, aka cookie-cutter: takes an OID (Object) and produces an object with that OID as self |
instantiate: | Generator --> Obj.
| instantiation produces an object from (a class as) a generator | instantiate(g) = fix(g) where OID = Object
Delta = | Obj. --> Generator | a subclass delta for subclasses with supercalls: becomes a closed generator if given an object as receiver of supercalls |
inherit: | Gen. × Delta --> Gen.
| single inheritance with supercalls means to combine
baseclass generator B and delta D into one: | inherit(B,D) =  self. B(self) + D( B(self) )(self)
| Gen. × Gen. --> Gen.
| inheritance without supercalls would mean to combine
baseclass generator B and delta generators D into one: | inherit(B,D) = self. B(self) + D(self)
| object-based:
Prototype = | Prototype --> Obj.
| a prototype produces an object o after taking a prototype to be used where o uses self as a prototype |
instantiate: | Prototype --> Obj.
| instantiation produces an object from (an object as) a prototype, aka generator | instantiate(g) = g(g)
Child = | Obj. --> Prototype | child objects take a full object as parent to yield a full prototype |
inherit: | Proto. × Child --> Proto.
| object inheritance means to combine
parent prototype B and child D into one: | inherit(B,D) = self. B(self) + D( B(self) )(self)
| | ||||||
| Analysis | Requirements & Principles | Paradigms | Abstractions | Domains | Features | foundational | safety | flexible typing | Syntactics | Defining PLs | Language List |