Semantyka i weryfikacja programów/Ćwiczenia 6

Z Studia Informatyczne
Wersja z dnia 08:49, 7 sie 2006 autorstwa Sl (dyskusja | edycje)
(różn.) ← poprzednia wersja | przejdź do aktualnej wersji (różn.) | następna wersja → (różn.)
Przejdź do nawigacjiPrzejdź do wyszukiwania


Zawartość

Ostatnie zajęcia poświęcone semantyce naturalnej. Rozszerzymy język Tiny o deklaracje zmiennych i procedur z jednym parametrem. Rozważymy statyczną i dynamiczną widoczność (wiązanie) identyfikatorów oraz różne mechanizmy przekazywania parametrów. Pracujemy ze środowiskami i stanami.


Zadania z rozwiązaniami

Zadanie 1 (procedury)

Rozważmy język Small, będący rozszerzeniem języka Tiny o deklaracje i wywołania procedur:

I::=|𝐛𝐞𝐠𝐢𝐧d;I𝐞𝐧𝐝|𝐜𝐚𝐥𝐥x1(x2)

d::=𝐯𝐚𝐫x=e|𝐩𝐫𝐨𝐜x1(x2);I|d1;d2

Konstrukcja 𝐩𝐫𝐨𝐜x1(x2) deklaraje procedurę o nazwie x1, której parametrem formalnym jest x2. Zakładamy statyczne wiązanie identyfikatorów i przekazywanie parametrów przez zmienną (to znaczy, że w momencie wywołania procedury, powinna zostać przekazana lokacja odpowiadająca parametrowi aktualnemu). Instrukcja 𝐜𝐚𝐥𝐥x1(x2) wywołuje procedurę x1 a parametrem aktualnym x2.


Rozwiązanie

Użyjemu środowisk E𝐄𝐧𝐯 i stanów s𝐒𝐭𝐚𝐭𝐞:

𝐒𝐭𝐚𝐭𝐞=𝐋𝐨𝐜fin𝐍𝐮𝐦𝐄𝐧𝐯=𝐕𝐚𝐫fin(𝐋𝐨𝐜PROC).

Nowym elementem jest zbiór PROC, potrzebny nam do przechowywania informacji o procedurach. Informacja nt procedury, którą musimy przechowywać, to:

  • nazwa parametru formalnego,
  • ciało procedury (instrukcja I𝐒𝐭𝐦𝐭) oraz
  • środowisko, w którym procedura została zadeklarowana.

Zauważmy, że nie musimy (i nie powinniśmy) pamiętać stanu z momentu deklaracji, czyli konkretnych wartości zmiennych wówczas zadeklarowanych. Pamiętamy tylko środowisko, które wyznacza nam wiązanie identyfikatorów (nazw zmiennych i procedur) występujących w ciele procedury z lokacjami (lub opisami procedur z PROC), a więc z konkretnymi zmiennymi (lub procedurami). Widać tutaj jasno, jak elegancki i wygodny jest podział na środowisko i stan.

Zatem niech PROC=𝐕𝐚𝐫×𝐒𝐭𝐦𝐭×𝐄𝐧𝐯. Czyli znów zbiór 𝐄𝐧𝐯 zadany jest przez równanie.

Nasze tranzycje będą następujących postaci:

Ee,snEb,sl

EI,ssEd,s(E,s)

Na uwagę zasłyguje ostatnia postać tranzycji: deklaracja, w odróżnieniu od instrukcji, może zmieniać środowisko. Umówmy się, że środowisko E będzie rozszerzało E o informację o nowych identyfikatorach, tzn. tych zadeklarowanych w d.

Zaczniemy od nowych semantyki dla nowych konstrukcji języka, natomiast semantykę samego języka Tiny opartą na środowiskach i stanach przedyskutujemy krótko na końcu rozwiązania.

Zajmijmy się najpierw deklaracjami zmiennych:

Ee,snE𝐯𝐚𝐫x=e,s(E,s) gdzie E=E[xmapstol],s=s[ln],l=new(s)

i procedur:

E𝐩𝐫𝐨𝐜x1(x2);I,s(E,s) gdzie E=E[x1x2,I,E].

Zauważmy, że deklaracja procedury nie zmienia stanu, tylko środowisko, w odróznieniu od deklaracji zmiennej. W środowisku pamiętamy trójkę x2,I,E zawierającą nazwę parametru formalnego, ciało procedury oraz środowisko deklaracji procedury. To ostatnie determinuje statyczne wiązanie identyfikatorów: wiązanie identyfikatorów występującuch w ciele procedury jest jakby ,,zamrożone (ustalone) w momencie deklaracji procedury. Aby dokończyć semantykę deklaracji potrzebujemy jeszcze jednej reguły:

Ed1,s(E,s)Ed2,s(E,s)Ed1;d2,s(E,s)

która opisuje sekwencyjną ,,kumulację" modyfikacji dokonanych w deklaracjach.

Pytanie: czy kolejność poszczególnych deklaracji ma znaczenie?

Teraz określimy semantykę bloku:

Ed,s(E,s)EI,ssE𝐛𝐞𝐠𝐢𝐧d;I𝐞𝐧𝐝,ss

Czyli instrukcja wewnętrzna wykonywana jest w środowisku (i stanie) wytworzonym (rozszerzonym) przez deklarację d. Stan końcowy po wykonaniu bloku to po prostu stan końcowy s po wykonaniu instrukcji wewnętrznej. Może się to wydawać niepokojące, gdyż oznacza, że nowe lokacje, powołane podczas deklaracji d, zachowują przechowywaną wartość również po wyjściu z bloku. Na szczęście wykonanie bloku nie ma wpływu na środowisko, a to ono decyduje, które identyfikatory są widoczne (zadeklarowane) i ogólniej, które lokacje są przypisane identyfikatorom. A więc deklaracja d nie ma wpływu na środowisko, w którym zostaną wykonane kolejne instrukcje. Widać to jasno w regule dla złożenia sekwencyjnego:

EI1,ssE,I2,ssEI1;I2,ss


Pozostało nam jeszcze określenie semantyki wywołania procedury:

E[xl]I,ssE𝐜𝐚𝐥𝐥x1(x2),ss o ile E(x1)=x,I,EPROC i E(x2)=l𝐋𝐨𝐜

Czyli uruchamiane jest ciało I procedury, w środowisku E z miejsca deklaracji tej procedury zmodyfikowanym o przypisanie xl lokacji l do parametru formalnego x procedury. Stan, w którym uruchomione jest I to po prostu stan bieżący z miejsca wołania procedury; o prawidłowe wiązanie identyfikatorów ,,troszczy" się wyłącznie środowisko E.

Pytanie: czy powyższa reguła dopuszcza rekurencyjne wywołania procedury?

Okazuje się, że niestety nie, gdyż w środowisku E'[x \mapsto l] nie ma informacji o procedurze x1, którą właśnie wołamy. Może się zdarzyć, że E[xl]PROC, ale oznacza to tylko, że w miejscu deklaracji procedury x1 była już wcześniej (statycznie) zadeklarowana inna procedura o tej samej nazwie. Aby umożliwić rekurencję, powinniśmy zadbać sami o to, aby środowisko, w którym wykonujemy I zawierało informację o naszej procedurze:

E[xl][x1x,I,E]I,ssE𝐜𝐚𝐥𝐥x1(x2),ss o ile E(x1)=x,I,EPROC i E(x2)=l𝐋𝐨𝐜

Zauważmy, że przypisanie x1x,I,E dodane do E wystarcza na tylko jedno wywołanie rekurencyjne (licząc w głąb). Ale każde kolejne wywołanie dodaje tę informację, czyli każde wywołanie procedury przygotowuje środowisko dla następnego. I to jest wystarczające.

Pytanie: czy możliwa jest rekurencja wzajemna?

Pozostaje jeszcze jedna kwestia: dodajemy do środowiska E dwa przypisania: xl oraz x1x,I,E, ale dlaczego w takiej kolejności.

Pytanie: co się stanie, gdy zamienimy tę kolejność:

E[x1x,I,E][xl]I,ssE𝐜𝐚𝐥𝐥x1(x2),ss o ile E(x1)=x,I,EPROC i E(x2)=l𝐋𝐨𝐜

Czy obydwie semantyki są sobie równoważne?

Okazuje się, że tak nie jest, oto dwa kontrprzykłady:

Parser nie mógł rozpoznać (błąd składni): {\displaystyle \mathbf{begin}\,\\ \quad \mathbf{Var} y = 7;\\ \quad proc x(x);\, x := x+1;\\ \ \\ \quad x(y);\\ \,\mathbf{end} }

Parser nie mógł rozpoznać (błąd składni): {\displaystyle \mathbf{begin}\,\\ \quad \mathbf{Var} y = 7;\\ \quad proc x(x);\, \mathbf{if}\, \quad \quad \mathbf{if}\, y > 0 \,\mathbf{then}\, y := y-1;\, \mathbf{call}\, x(y) \,\mathbf{else}\, \mathbf{skip};\\ \ \\ \quad x(y);\\ \,\mathbf{end} }

Każdy z tych programów uruchomi się poprawnie w dokładnie jednym z wariantów semantyki.

Pytanie: Który w którym?

Semantyka pozostałych instrukcji i wyrażen języka Tiny pozostaje bez zmian.

Rozważmy na koniec problem dealokacji.


Wariant (dealokacja)

Chcemy, aby ,,posprzątano" po zakończeniu wykonania bloku, tzn. aby zwolniono te lokacje, które były używane tylko w tym bloku i w związku z tym nie będą już potrzebne. Oznacza to, że powinniśmy przywrócić nieokreśloność stanu dla wszystkich tych lokacji, które były użyte podczas deklaracji d.

Jest wiele możliwości wyrażenia tego dodatkowego warunku, np. możemy dodać do powyższej reguły

Ed,s(E,s)EI,ssE𝐛𝐞𝐠𝐢𝐧d;I𝐞𝐧𝐝,ss¯

dodatkowy warunek postaci  gdzie s¯=. Proponujemy tu rozwiązanie ciut bardziej eleganckie. Zacznijmy od tranzycji dokonujących dealokacji, które mogą być np. postaci: s,Ls¯. Zakładamy tutaj, że znamy zbiór nowo zaalokowanych lokacji L𝐋𝐨𝐜.

s,ss{(l,s(l))},L{l}ss,Ls o ile lL i s(l) jest określone

Teraz albo napiszemy w dodatkowym warunku, że Parser nie mógł rozpoznać (nieznana funkcja „\dom”): {\displaystyle L = \dom(s'') \setminus \dom(s) } :

Parser nie mógł rozpoznać (nieznana funkcja „\dom”): {\displaystyle \frac{E \,\vdash\, d, s \,\longrightarrow\, (E', s') \quad \quad E' \,\vdash\, I, s' \,\longrightarrow\, s'' s'', L \,\longrightarrow\, \bar{s}} {E \,\vdash\, \mathbf{begin}\, d;\, I \,\mathbf{end}, s \,\longrightarrow\, \bar{s}} \quad \mbox{ gdzie } L = \dom(s'') \setminus \dom(s) }

albo możemy poprosić o pomoc w posprzątaniu tego, kto nabałaganił, czyli deklarację d. Niech deklaracja zwraca, oprócz pary (E,s), dodatkowo zbiór L. Oto poprawione reguły dla deklaracji:


Ee,snE𝐯𝐚𝐫x=e,s(E,s,{l}) gdzie E=E[xmapstol],s=s[ln],l=new(s)

E𝐩𝐫𝐨𝐜x1(x2);I,s(E,s,) gdzie E=E[x1x2,I,E].

Ed1,s(E,s,L)Ed2,s(E,s,L)Ed1;d2,s(E,s,LL)

Wtedy ostatecznie reguła dla bloku wygląda następująco:

Ed,s(E,s,L)EI,sss,Ls¯E𝐛𝐞𝐠𝐢𝐧d;I𝐞𝐧𝐝,ss¯


Zadanie 2 (wiązanie dynamiczne)

Zastanówmy się, jakich modyfikacji wymaga nasza semantyka, aby wiązanie identyfikatorów było dynamiczne, zamiast statycznego. Rozumiemy przez to, że w przypadku odwołania do zmiennej wewnątrz procedury, odwułujemy się do środowiska w miejscu wywołania tej procedury, zamiast do środowiska z miejsca deklaracji jak dotychczas. Tak samo powinno być w przypadku wywołania innej procedury wewnątrz procedury, czyli wiązanie dynamiczne dotyczy i zmiennych i procedur. Oto przykład:

Parser nie mógł rozpoznać (błąd składni): {\displaystyle \mathbf{begin}\,\\ \quad \mathbf{var}\, x = 1;\\ \quad \mathbf{proc}\, p(y);\, y := y+x;\\ \ \\ \quad \mathbf{begin}\,\\ \quad \quad \mathbf{var}\, x = 10;\\ \quad \quad \mathbf{var}\, z = 0;\\ \ \\ \quad \quad \mathbf{call}\, p(z); \quad \,\mathbf{end}\\ \,\mathbf{end} }

Wartość końcowa zmiennej z=10. Gdyby wiązanie zmiennej x było statyczne, to wartość ta wynosiłaby 1. Podobnie dla procedur:

Parser nie mógł rozpoznać (błąd składni): {\displaystyle \mathbf{begin}\,\\ \quad \mathbf{proc}\, q(x);\, x := x+1;\\ \quad \mathbf{proc}\, p(y);\, \mathbf{call}\, q(y); \mathbf{call}\, q(y);\\ \ \\ \quad \mathbf{begin}\,\\ \quad \quad \mathbf{proc}\, q(x);\, x := x+x;\\ \quad \quad \mathbf{var}\, z = 2;\\ \ \\ \quad \quad \mathbf{call}\, p(z); \quad \,\mathbf{end}\\ \,\mathbf{end} }

Wartość końcowa zmiennej z=8. Gdyby widoczność procedury q była statyczna, to wartość ta wynosiłaby 4. A oto przykład programu, który nie wykonałby się poprawnie przy wiązaniu statycznych, a wykonuje się poprawnie przy dynamicznym:

Parser nie mógł rozpoznać (błąd składni): {\displaystyle \mathbf{begin}\,\\ \quad \mathbf{proc}\, q(x);\, \mathbf{call}\, r(x);\\ \quad \mathbf{proc}\, p(y);\\ \quad \quad \mathbf{begin}\,\\ \quad \quad \quad \mathbf{proc}\, r(x);\, x := x+x;\\ \ \\ \quad \quad \quad q(x); \quad \quad \,\mathbf{end}\\ \quad \mathbf{var}\, z = 7; \ \\ \quad \mathbf{call}\, p(z); \,\mathbf{end} }

Wartość końcowa zmiennej z wynosi 14. Procedura p wywołuje procedurę r, ,,przekazując" jej również środowisko z miejsca wołania, zawierające informację o procedurze r, która przy widoczności statycznej byłaby lokalna, a teraz nie jest.


Rozwiązanie

Spójrzmy na regułę dla wywołania procedury:

E[xl]I,ssE𝐜𝐚𝐥𝐥x1(x2),ss o ile E(x1)=x,I,EPROC i E(x2)=l𝐋𝐨𝐜

O statyczności decyduje to, że wnętrze procedury I wykonywane jest w środowisku zmiejsca deklaracji E. Wystarczy więc, jeśli zignorujemy to środowisko, a zamiast niego użyjemy bieżącego środowiska E (czyli środowiska z miejsca wywołania):

E[xl]I,ssE𝐜𝐚𝐥𝐥x1(x2),ss o ile E(x1)=x,I,EPROC i E(x2)=l𝐋𝐨𝐜

Oczywiście w takim przypadku w środowiskach wystarczy przechowywać dla procedur pary x,I.

Zastanówmy się teraz, jak uwzględnić rekurencję? Oczywiście moglibyśmy postąpić tak jak poprzednio, np.

E[xl][x1x,I]I,ssE𝐜𝐚𝐥𝐥x1(x2),ss o ile E(x1)=x,IPROC i E(x2)=l𝐋𝐨𝐜

ale jeśli uważnie przyjrzymy się tej regule, to okazuje się, że ,,przelewamy z pustego w próżne". Sciślej, dodajemy do E parę x1x,I, która już tam tak naprawdę jest! Okazuje się, że dzięki dynamicznemu wiązaniu identyfikatorów ,,za darmo" otrzymujemy rekurencje! Tak jest na przykład w programie:

Parser nie mógł rozpoznać (błąd składni): {\displaystyle \mathbf{begin}\,\\ \quad \mathbf{proc}\, p(x);\, \mathbf{if}\, x < 100 \,\mathbf{then}\, x := x+x; \mathbf{call}\, p(x) \,\mathbf{else}\, \mathbf{skip};\\ \quad \mathbf{var}\, z = 8; \ \\ \quad \mathbf{call}\, p(z); \,\mathbf{end} }

ponieważ w momencie wywołania rekurencyjnego 𝐜𝐚𝐥𝐥p(x), w środowisku jest już informacja nt. procedury p!


Zadanie 3 (różne mechanizmy przekazywana parametru)

Rozważ inne mechanizmy przekazywania parametru w języku Small (wiązanie statyczne):

  • przez wartość
  • in-out

Należy wyjaśnić ostatni mechanizm (in-out). Parametrem aktualnym jest zmienna, której wartość jest przypisywana parametrowi formalnemu (tak jak przy przekazywaniu przez wartość, gdy parametrem aktualnym jest zmienna). Ale po zakończeniu procedury, wartość parametru formalnego, która mogła zmienić się w czasie dzialania procedury, jest spowrotem przypisywana na zmienną będącą parametrem aktualnym (a więc podobnie do przekazywania przez zmienną). Parametr formalny jest traktowany jak zmienna lokalna procedury.


Rozwiązanie

Przekazywanie przez wartość

Omówimy tylko instrukcję wywołania procedury, której składnia jest teraz szersza niż popzrzednio:

I::=|𝐜𝐚𝐥𝐥x(e)

Przed wywołaniem procedury należy zaakolować nową lokację, którą przypiszemy parametrowi formalnemu; następnie obliczamy wartość parametru aktualnego i umieszczamy ją w tej lokacji:

Ee,snE[xl]I,s[ln]sE𝐜𝐚𝐥𝐥x(e),ss o ile E(x)=x,I,EPROC i l=new(s)


Przekazywanie in-out

Początkowo postępujemy tak jak w przypadku przekazywania przez wartość: alokujemy nową lokację l, którą przypiszemy parametrowi formalnemu, i umieszczamy w niej wartość zmiennej (x2 w regule poniżej) będącej parametrem aktualnym. Zasadnicza różnica widoczna jest po zakończeniu procedury: wartość z lokacji l powinna zostać spowrotem przypisana zmiennej x2. Oto reguła:

E[xl]I,s[ls(l2)]sE𝐜𝐚𝐥𝐥x1(x2),ss[l2s(l)] o ile E(x2)=l2𝐋𝐨𝐜 i s(l2) jest określone i E(x1)=x,I,EPROC i l=new(s)


Zadania domowe

Zadanie 1

Zaadaptuj semantykę języka Small z ,,deklaracjami równoległymi" dla rekurencji wzajemnej wewnątrz jednej deklaracji równoległej. To znaczy, procedury zadeklarowane w jednej deklaracji równoległej mogą się wzajemniej wywoływać bez żadnych ograniczeń.


Zadanie 2

Zamiast procedur, rozważ w języku Small funkcje z pojedynczym parametrem przekazywanym przez zmienną. Wywołanie funkcji może teraz pojawić się wewnątrz wyrażenia:

e::=|𝐜𝐚𝐥𝐥x1(x2)

Uwaga na efekty uboczne!


Zadanie 3

Rozważ warianty semantyki języka Small, w którym

  • wiązanie zmiennych jest statyczne a procedur dynamiczne
  • wiązanie zmiennych jest dymamiczne a procedur statyczne