Tekst źródłowy strony Fundamental research

Work on programming language Loglan'82 and its compiler was accompanied by vivid discussions and fundamental research. <br />



On these pages we shall report some of results.<br />

Another [[Axiomatic definition of Loglan'82 |page]] is devoted to the task of giving an axiomatic definition of Loglan'82.
==  Problems  ==
=== Is it possible to deallocate objects in a safe and efficient way? ===
The problem is how to dealocate unused objects in a safe way?<br />
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  
{| class="wikitable" 
|-
| <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 
* The paper by [[Media:Programmed-deallocation-without-Dangling-Reference-I.pdf|G. Cioni & A. Kreczmar, ''Programmed dealocation without dangling reference'', IPL 1984]].
* Report [[Media:ProgramdDeallocatn-II.pdf  |A. Salwicki & A. Zadrożny, ''Programmed deallocation without dangling reference II'', manuscript ]].<br />
:* See [[what happened]] to the report.

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.<br />
class X extends B { ... }       or class X extends A.E.C.D.B {} .<br />
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.

<small> 
 {| class="wikitable" 
|-
|
:'''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
|}
</small>
Questions<br />

* 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 ...
* [[Media:C3149.pdf|H.Langmaack, A. Salwicki, M. Warpechowski, ''On an algorithm determining direct superclasses in Java and similar languages with inner classes - its correctness, completeness and uniqueness of solutions. '']]This paper solves the problem of determination of direct superclass in Java  and other languages. We give a short and complete specification of the problem - to be confronted with somewhat fuzzy and dispersed description of the problem in Java Language Specification. We are presenting a non-deterministic algorithm A and prove that the algorithm correctly solves the problem and moreover that the algorithm is complete, i.e. if it finds that an instance of a problem has no solution then it is really so.  This algorithm after some simplifications applies as well to Loglan programs and even to Simula67 programs.
* [[Media:pracaFI22.10.2007.pdf|H.Langmaack, A. Salwicki, M. Warpechowski, ''On the correctness and completeness of a deterministic algorithm elaborating direct superclasses in Java-like languages.'']] A practical deterministic algorithm for the same problem. 
* [[Media:IPET-09-2Nov.pdf| H. Langmaack, A. Salwicki, ''Some methodological remarks inspired by the paper "On inner classes" by A. Igarashi and B.Pierce. '' ]] A discussion of methodological issues taken in a paper by A. Igarashi and B. Pierce.

===  How to define static binding in the languages with inheritance and nesting of modules? ===
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.<br />

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

A general case is considered in ...

===  How to adapt Dijkstra's Display Vector for the languages with inheritance and nesting of modules ? ===
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?<br />
After some monthsof discusions the creators of Loglan programming language came to a solution see<br />
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.

=== How to define semantics of coroutines? ===
First of all, what is a coroutine? Only a few programming languages offer coroutines and operations on them. But where is a definition of coroutines? Most sources quote Donald Knuth: ''Subroutines are special case of coroutines.'' With all esteem we have to Don Knuth this is not a definition. 

Our approximate answer is: there are modules of coroutines. These modules are syntactically similar to modules of classes. One may create several objects of coroutine module. An object of coroutine behaves somewhat like a thread. It means the instructions of this object can be interrupted and resumed. The difference lies in the following axiom of coroutine systems: Of many object of coroutines exactly one is executing its instructions. All the remaining coroutine objects are suspended - passive. 

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

Main - a predefined name of the coroutine containing the main block of a program

Instructions operating on coroutines: attach(x) and detach

Each coroutine object must have a name!

Instructions attach and detach may appear not only in the coroutine module but also in the methods of coroutine.

Notion of dynamic chain of dynamic instances - cooperation of coroutines and of subroutines(functions and procedures)

===  Alien call - how to communicate active objects of process modules in the object paradigm? ===
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. 
* [[Media:Bolek1988.pdf| - an original presentation of alien call protocol]]
* [[Media:AlienCall.pdf | - a scratch report ]]

=== 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.<br />
Now, the creation of an active object of a process module Prc requires a node of virtual computer.<br />

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

Some screenshots may be helpful.

=== Are the mathematical models of concurrent and parallel computations equivalent? ===
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 ==
# [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 = A.I.| nazwisko4 = Oktaba|imię4 =  H.| tytuł = Semantics and Implementation of Prefixing on many Levels | czasopismo = Springer LNCS vol.148 | rok= 1980 |tom = 148 | strony = 45 - 80 |url=http://lem12.uksw.edu.pl/wiki/Plik:4autorow.pdf}}]]
# [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 |url=http://lem12.uksw.edu.pl/wiki/Plik:Bericht8410.pdf }}]]
# [Kreczmar, Cioni 1984] [[Media:Programmed-deallocation-without-Dangling-Reference-I.pdf |{{Cytuj pismo| odn=tak | imię=Antoni | nazwisko=Kreczmar| imię2=Gianna | nazwisko2=Cioni |tytuł=Programmed deallocation without dangling reference |czasopismo=Information Processing Letters |strony=179-187 |rok=1984|url=http://lem12.uksw.edu.pl/images/5/54/Programmed-deallocation-without-Dangling-Reference-I.pdf}}]]
# [Cioni,Kreczmar, Vitale 1989] {{Cytuj książkę|odn=tak | nazwisko = Cioni | imię = Gianna | tytuł = Storage Management | wydawca = Academic Press | miejsce = London | data = 1989 | strony = 341-366 | isbn = 0121746909 | nazwisko2 = Kreczmar | imię2 = Antoni | nazwisko3 = Vitale | imię3 = Ricardo | tytuł tomu = Advanced Programming Methodologies|url=}}
# [Mirkowska,Salwicki,1980] {{Cytuj pismo | odn=tak | nazwisko=Mirkowska |imię=Grażyna | nazwisko2=Salwicki |imię2=Andrzej |tytuł= On axiomatic definition of MAX model of concurrency  | url=http://lem12.uksw.edu.pl/images/f/f0/AxMAX.pdf  }}
# [Warpechowski,2018] {{Cytuj pismo | odn=tak | nazwisko=Warpechowski |imię=Marek |  |tytuł= On the determination of extended classes and some other problems in Java programming language  | url=http://http://lem12.uksw.edu.pl/images/1/18/WarpechowskiTezaDokt.pdf }}
# [Salwicki, Muldner 1981] [{{Cytuj pismo | odn=tak | nazwisko=Salwicki | imię= Andrzej | imię2=Tomasz | nazwisko2=Muldner | tytuł=Algorithmic Properties of Concurrent Programs| czasopismo=Logics of Programs | data=1981 | strony=169-197 | wydawca=Springer LNCS 125 |miejsce=Berlin }}]