Fundamental research: Różnice pomiędzy wersjami

Z Lem
Skocz do: nawigacji, wyszukiwania
(→‎Bibliography)
(→‎Bibliography)
Linia 110: Linia 110:
 
# [AlgoLog] [[Media:Algorithmic_Logic.pdf | {{cytuj książkę |odn=tak| nazwisko = Mirkowska| imię = Grażyna | nazwisko2 = Salwicki | imię2 = Andrzej | tytuł = Algorithmic Logic | wydawca = PWN | miejsce = Warszawa | data = 1987 | strony = 345}}]]  
 
# [AlgoLog] [[Media:Algorithmic_Logic.pdf | {{cytuj książkę |odn=tak| nazwisko = Mirkowska| imię = Grażyna | nazwisko2 = Salwicki | imię2 = Andrzej | tytuł = Algorithmic Logic | wydawca = PWN | miejsce = Warszawa | data = 1987 | strony = 345}}]]  
 
# [BKLO] [[Media:4autorow.pdf | {{cytuj pismo | odn=tak | nazwisko = Bartol | imię = W.M. | nazwisko2= Kreczmar | imię2 = A. | nazwisko3 = Litwiniuk | imię3 = I.| nazwisko4 = Oktaba|imię4 =  H.| tytuł = Semantics and Implementation of Prefixing on many Levels | czasopismo = Springer LNCS | rok= 1980 |tom = 148 | strony = 45 - 80 }}]]
 
# [BKLO] [[Media:4autorow.pdf | {{cytuj pismo | odn=tak | nazwisko = Bartol | imię = W.M. | nazwisko2= Kreczmar | imię2 = A. | nazwisko3 = Litwiniuk | imię3 = I.| nazwisko4 = Oktaba|imię4 =  H.| tytuł = Semantics and Implementation of Prefixing on many Levels | czasopismo = Springer LNCS | rok= 1980 |tom = 148 | strony = 45 - 80 }}]]
 +
# [LKKS] [[Media: Bericht8410.pdf | {{cytuj pismo | odn=tak | nazwisko = Langmaack | imię = Hans | nazwisko2= Kreczmar | imię2 = A. | nazwisko3 = Krause | imię3 = M.| nazwisko4 = Salwicki|imię4 =  A.| tytuł = Specification and Implementation Problems of Programming Languages Proper for Hierarchical Data Types | czasopismo = Technical Reports of Institut fuer Informatik | rok= 1984 |tom = 10 | strony = 1 - 70 }}]]

Wersja z 14:42, 23 paź 2015

Work on programming language Loglan'82 and its compiler was accompanied by vivid discussions and fundamental research. On these pages we shall report some of results and an attempt to define an axiomatic semantics of Loglan'82. Another page is devoted to the task of giving an axiomatic definition of Loglan'82.

Problems and reports

Safe dealocation of objects

The problem is how to dealocate unused objects in a safe way?
Some programming languages (Pascal, C++) allow to use instruction delete(x). Other languages (Java, Python) forbid such instructions and relay on the garbage collection gc(). In this way the Java's object management system gains safety but becomes much less controlled. It may happen that another danger named memory leakage will appear. We are happy to present you the object managing system invented by Antoni Kreczmar. In his system one can use the atomic instruction kill(x) in order to dealocate an object being the value of the variable x.

The axiom of kill is here

[math] \underbrace{((x= y = ... =x_n) \wedge x \neq \textbf{none})}_{precondition}\Rightarrow \underbrace{[kill(y)]}_{\mathrm{statement}}\underbrace{(x= y = ... =x_n = \textbf{none})}_{postcondition} [/math]

It tells that all references to an object x obtain the value none. No dangling reference error appears. The cost of the kill operation is fixed, independent of how many variables share the object x as common value. For more information see


Note, no other programming language enjoys the property of safe dealocation.

How to determine the direct superclass?

The declaration of a class appears in many places of a Java program.
class X extends B { ... } or class X extends A.E.C.D.B {} .
The meaning of identifier X is obvious. But what does it mean B or A.B.C.D.E? The identifier B is the name of a class. Note, one program may contain several classes of name B. Which class of this name is the class? No programmer will understand what program does without prior answering to the question. No compiler will produce the code without solving this problem.

This question is the fundamental one for the definition of semantics. Consider the following example written in Java.

class A extends B { // this can be class B or A.B i.e. class B contained in class A
class C extends D { // this can be class B.D or E.D
class F extends G {} // this can be class A.E.G or E.G
} // end C
class E {
class G {}
} // end E
class B extends E {} // this can be class E or A.E
} // end A
class B {
class D extends E {} // this can be class E or A.E
} // end B
class E {
class G extends B {} // this can be class B or A.B
class D {}
} // end E

Questions

  • The author of the program may write "extends B" or "extends A.B"(first line). It is to a compiler to guess what the author had in mind when writing the program and assign the correct answer. Which of possible 64 assignments is correct? Note, a real program may contain hundreds of classes.
  • How to diagnose incorrect programs? For there are innocently looking programs that do not posses a correct solution. See [{}] for an example.
  • Is there any efficient algorithm to determine direct superclasses?

There are 4 languages which admit both nesting of modules (i.e. block structure ) and inheritance:

  • Simula67
  • Loglan'82
  • BETA
  • Java

Each language gives another definition of the base class. We shall mention ...

Static binding

Let a be an applicative occurence of an identifier i. (Applicative means in an instruction.) Where to find a proper declaration of the idenfifier i? The problem known for block structured programming languages is far more complicated in the languages that admit not only nesting of modules but also inheritance.

For Loglan'82 a solution was find by Danuta Szczepańska (not published, validated through compiler).

A general case is considered in ...

Is it possible to keep the Dijkstra's mechanism of Display Vector ?

The problem arises when a programming language allows to nest declarations of classes as well as their extensions by inheritance. Now, if one defines a constructor of a class as a concatenation of constructors of inherited classes (it is so called rule of concatenation), then is it possible to define Dijkstra's Display Vector once for all instructions of the consolidated (by concatenation) constructor?
After some monthsof discusions the creators of Loglan programming language came to a solution see
Some time later Hans Langmaack found that the proposed semantic can not be called the correct static semantic.

Two papers appeared that led to a satisfactory solution

The experience gained through this research enabled later to solve the problems of determining drect base class in Java.

Coroutines

How to define the meaning of coroutine operations? in a way free of inconsistency?

Alien call

This is a protocol invented by Bolek Ciesielski in 1988(!) for communication and synchronisation among active objects of process modules. For the first time implemented in Loglan'82 programming language, it remains still little known for programmers.

Connecting virtual machines into a virtual multiprocessor

The virtual Loglan processors VLP can be connected through network thus forming a virtual multiprocessor computer. Each VLP obtains a unique node number.
Now, the creation of an active object of a process module Prc requires a node of virtual computer.

Example
unit Prc: process(nd:integer, <otherParams>); ... end Prc;
var a,b: Prc;
...
a:= new Prc(0,actualParams); (* active object a shares the processor with main *)
b:= new Prc(17, actualPms); (* active object b is placed on node 17 *)
Therefore, one program may organize concurrent and distributed computations.

Some screenshots may be helpful.

Mathematical model of concurrent computations

During the work on Loglan project we conceived and published a model explaining how the execution of concurrent programs look like. The model was named Max model of concurrency. Later it was known under the name of true concurrency model.

Bibliography

  1. [AlgoLog] Grażyna Mirkowska, Andrzej Salwicki: Algorithmic Logic. Warszawa: PWN, 1987, s. 345.
  2. [BKLO] W.M. Bartol, A. Kreczmar, I. Litwiniuk, H. Oktaba. Semantics and Implementation of Prefixing on many Levels. „Springer LNCS”, s. 45 - 80, 1980. 
  3. [LKKS] Hans Langmaack, A. Kreczmar, M. Krause, A. Salwicki. Specification and Implementation Problems of Programming Languages Proper for Hierarchical Data Types. „Technical Reports of Institut fuer Informatik”, s. 1 - 70, 1984. 
Źródło „http://lem12.uksw.edu.pl/index.php?title=Fundamental_research&oldid=1994”