11. Operacyjna semantyka zapytań i programów

Operacyjna semantyka wszystkich operatorów występujących w zapytaniach będzie zdefiniowana w terminach operacji na dwóch stosach: stosie środowisk i stosie rezultatów zapytań. Równoważny denotacyjny model semantyki pozwoliłby wprawdzie na eliminację stosu rezultatów, ale (jak się okazało) jest znacznie mniej intuicyjny, przez co trudniejszy do objaśnienia, użycia i rozwoju.

Zapytania mogą stanowić bezpośrednio interfejs dla użytkownika końcowego, ale nie będziemy uważać, że jest to ich podstawowa funkcja. Zapytania, jako uogólnione wyrażenia języka programowania, mogą być zastosowane w różnych kontekstach: jako składowe zdań imperatywnych w wariancie makroskopowym (takich jak update, insert, delete języka SQL), jako parametry aktualne procedur i metod, jako środek określenia wyniku procedury lub metody funkcyjnej itd.

Zapytania mogą odwoływać się do dowolnych bytów czasu wykonania, w szczególności do trwałych obiektów, ich atrybutów, danych ulotnych, danych lokalnych procedur i metod, parametrów procedur i metod itd. Przyjmując zasadę ortogonalnej trwałości (orthogonal persistence) będziemy zakładać, że nie będą występować jakiekolwiek różnice w sposobie formułowania zapytań do trwałych i nietrwałych danych, jak również jedno zapytanie może zawierać odwołania do dowolnych bytów czasu wykonania (w szczególności trwałych i nietrwałych danych).

Zapytania (oraz procedury i metody funkcyjne) nie będą zwracać obiektów, lecz referencje do obiektów (czyli ich identyfikatory) lub bardziej złożone struktury składające się z referencji, wartości elementarnych i nazw. To założenie eliminuje problemy z własnością domkniętości (closure property), zmuszającą do rozpatrywania zapytań zachowujących obiekty i generujących obiekty.

Definiowany przez nas język zapytań będzie rozszerzony o możliwość definiowania procedur, perspektyw (views), procedur funkcyjnych oraz metod. Wynik procedur i metod funkcyjnych będzie należał do tej samej kategorii semantycznej, co rezultaty zapytań. Oznacza to, że procedury i metody funkcyjne można będzie wywoływać wewnątrz zapytań. Procedury (perspektywy, metody) mogą być rekurencyjne (z założenia - nie przewidujemy specjalnej składni). Mogą także posiadać parametry. Będziemy zakładać co najmniej dwie metody transmisji parametrów: call-by-value oraz call-by-reference. Ponieważ parametrami będą zapytania (które mogą zwrócić jednocześnie wiele wartości), więc obie metody zostaną uogólnione tak, aby wykorzystać makroskopowy charakter zapytań.

Wynik procedury lub metody funkcyjnej (perspektywy) będzie mógł być dodatkowo wyposażony w "wirtualne nazwy", podobnie jak to ma miejsce w perspektywach języka SQL.

Reguły wiązania i zakresu dla nazw występujących w zapytaniach zostaną ustalone w taki sposób, aby uwzględnić pojęcia obiektowości, takie jak klasy, dziedziczenie, hermetyzacja, metody, atrybuty klasowe, przesłanianie i polimorfizm, i inne. Zapytania będą bazowały na zasadzie relatywizmu obiektów, tj. składnia, semantyka i pragmatyka użycia zapytań będzie identyczna dla dowolnego poziomu hierarchii danych (w szczególności, dla poziomu całej bazy danych, dla poziomu wnętrza pojedynczego obiektu itd.).