[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Gramatyka PROGRESS'a
W kilku odpowiedziach dotyczących "truskawkowego QUERY" powtarzało się
zdanie, że gramatykę języka 4GL PROGRESS można znaleźć w podręcznikach i w
helpie. Jest to prawda ale nie do końca. Tam jest opisana składnia i
semantyka poszczególnych INSTRUKCJI tego języka a nie całego języka. Np:
gdzie jest opisane, że DEF VAR można napisać gdziekolwiek w procedurze i że
zakres tak zadeklarowanej zmiennej jest poniżej tej deklaracji a nie w
całej procedurze a w przypadku procedury wewnętrznej tak nie jest ? Albo
gdzie w dokumentacji jest napisane, że różne obiekty procedury mogą mieć
ten sam identyfikator, np: QUERY i BROWSE ? Takie rzeczy wynikają z
przykładów a nie z formalnej gramatyki języka.
Gramatyka języka to coś więcej niż gramatyka poszczególnych "instrukcji"
i tego w PROGRESS'ie brak. Przecież oprócz istrukcji przewijają się w
dokumentacji pojęcia: procedura, procedura wewnętrzna, trigger, blok,
instrukcja złożona, funkcja itp a ich synaktycznej definicji brakuje. Np:
w dokumentacji jest opis "instrukcji" (!!!) END. Co to za instrukcja ???
Nie lepiej wprowadzić pojęcie instrukcji strukturalnej np: CASE ... END,
DO: .. END itp zamiast wymyślać jakiś dziwoląg w postaci instrukcji END. Po
prostu gramatyki języka nie da się sprowadzić do gramatyki poszczególnych
instrukcji, bo jężyk skałada się nie tylko z instrukcji.
Wystarczy wziąć np: książkę opisującą język PASCAL i zobaczyć jak
wygląda opis gramatyki zapisany w notacji Bahusa-Naura lub treż przy pomocy
diagramów syntatktycznych. Tam jest wiadomo jaka jest składnia obiektu
PROGRM, obiektu PROCEDURA itp. Podobnie rzecz ma się z semantyką. Tutaj
wprawdzie nie ma formalnej notacji, ale jest uczciwy opis jak to działa a
nie tylko przykłady i praktyka.
Powyższe braki implikują bardzo poważne skutki
- sygnalizacja błędów jest fatalna - ale jak opisać, że coś jest złe,
kiedy brak formalnego wzorca (gramatyki) z uczciwie nazwanymi
elementami języka (a nie tylko instrukcjami)
- pisanie programów, przynajmniej na początku nauki języka, odbywa się po
omacku i wymaga szukania przykładów w których coś podobnego było (ja
przynajmniej tak startowałem)
Wg mnie firma PSC nie chce podać formalnej gramatyki z dwóch powodów:
- pierwszy, to taki, że gramatyka ta jest pełna niekonsekwencji
wynikających z zaszłości i stąd byłaby dość skomplikowana
np: poniższe oba przykłady są poprawne:
IF AVAILABL Bufor THEN ...
IF AVAILABLE(Bufor) THEN ...
Co to jest AVAILABLE - funkcja czy operator i jak tu ładnie zapisać
składnię funcji ?
Albo inny przykład:
&IF Wyrazenie &THEN
Jak zapisać elegancko składnię Wyrażenia, które ku memu zdziwieniu
(znalazłem to w dokumentacji) może być typu LOGICAL lub INTEGER
lub CHARACTER. Zużyłem trochę czasu, by to zrobić i wcale nie jest
to takie banalne.
Innym ciekawym przypadkiem jest znak - jako znak identyfikatora a
jednocześnie minus unarny i operator minus. Stąd te
nieszczęsne spacje wokół operatora minus. Natomiast spacje wokół
operatorów + / * są chyba tylko po to, by było tak samo jak dla
minusa bo innych uzasadnień nie widzę.
W ogóle przyjęcie zbyt szerokiego znaczenia dla niektórych symboli np:
= jako operator porównania i jako operator przypisania powoduje
szereg komplikacji semantycznych. Podobnie ze znakiem .
(kropka), który jest elementem liczby i znakiem końca
instrukcji. To się później odbija na sygnalizacji błędów
w błędnym programie, bo kompilator nie może się odnaleźć.
Nie bedę już się znęcał nad literałami (np: nazwy plików systemu
operacyjnego występujące np: w INPUT FROM itp).
- drugi powód, to błędne przekonanie, że opis języka za pomocą
przykładów trafi do szerszej rzeszy odbiorców i to mniej
przygotowanych informatycznie. To przekonanie wg mnie jest
błędne, bo 4GL PROGRSS dawno już przestał być językiem dla "osób z
biura" (bardzo cenię "osoby z biura" i proszę nie
traktować, że coś przez to sugeruję) chociaż na początku swojej kariery
zapewne takim językiem był.
Na koniec bardzo przepraszam za zbyt długi wywód na ten temat. Lubię
pisać programy w PROGRESS'ie ale niektóre rzeczy strasznie mnie denerwują
jak chociażby ten brak gramatyki i mnóstwo niekonsekwencji stąd pozwoliłem
sobie na dłuższy wówód na ten temat.
PS. Paweł napisał, że instrukcja CAN-FIND nie zawsze dobrze działa.
Niedawno np: udało mi się odkryć taki kwiatek, który być może jest znany
dla wielu.
W triggerze DELETE dla tablicy jeśli szukam skasowanego rekordu instrukcją
FIND to go nie znajduję, słusznie zresztą, bo został skasowany. Ale
CAN-FIND do tego samego rekordu nadal go znajduje. Poradziłem sobie dodając
we frazie WHERE warunek wykluczający rekordy o RECID takim jak RECID
skasowanego rekordu. Panowie z PSC mogli by powiedzieć po co szukam zapisu,
który wiem, że skasowałem, ale to już inna sprawa.
Jeśli znajdę trochę czasu, to chciałbym do dyskusji "rzucić" temat pod
tytułem: RECID i co tak naprawdę firma PSC uważa za identyfikator rekordu:
RECID, czy też jego Primary Key.
Pozdrowienia dla wszystkich PROGRESS-men'ów
Henryk Jusza
-------------------------------------------------------
Ośrodek Informatyczny Politechniki Gdańskiej
Pracownia Rozwoju Oprogramowania
tel (058) 47-28-01 fax (058) 47-24-63