Specyfikacja języka programowania - Programming language specification

W obliczeniowych , wykorzystując specyfikację języka programowania (lub standardowy lub definicja ) jest artefakt dokumentacji, która określa język programowania , tak aby użytkownicy i implementors mogą uzgodnić, co to znaczy, że w programach językowych. Specyfikacje są zazwyczaj szczegółowe i formalne i są używane głównie przez wdrażających, a użytkownicy odwołują się do nich w przypadku niejasności; specyfikacja C ++ jest często cytowana przez użytkowników, na przykład ze względu na złożoność. Powiązana dokumentacja zawiera odniesienie do języka programowania , które jest przeznaczone specjalnie dla użytkowników, oraz uzasadnienie języka programowania , które wyjaśnia, dlaczego specyfikacja została napisana w takiej postaci; są one zwykle bardziej nieformalne niż specyfikacja.

Normalizacja

Nie wszystkie główne języki programowania mają specyfikacje, a języki mogą istnieć i być popularne przez dziesięciolecia bez specyfikacji. Język może mieć jedną lub więcej implementacji, których zachowanie jest de facto standardem, bez udokumentowania tego zachowania w specyfikacji. Perl (do Perla 5 ) jest godnym uwagi przykładem języka bez specyfikacji, podczas gdy PHP zostało określone dopiero w 2014 roku, po 20 latach używania. Język można zaimplementować, a następnie wyspecyfikować lub określić, a następnie zaimplementować, lub mogą one rozwijać się razem, co jest obecnie powszechną praktyką. Dzieje się tak, ponieważ implementacje i specyfikacje zapewniają wzajemne kontrole: pisanie specyfikacji wymaga precyzyjnego określenia zachowania implementacji, a implementacja sprawdza, czy specyfikacja jest możliwa, praktyczna i spójna. Pisanie specyfikacji przed implementacją było w dużej mierze unikane od ALGOL 68 (1968), z powodu nieoczekiwanych trudności we wdrożeniu, gdy implementacja jest odroczona. Jednak języki są nadal czasami implementowane i zyskują popularność bez formalnej specyfikacji: implementacja jest niezbędna do użycia, podczas gdy specyfikacja jest pożądana, ale nie niezbędna (nieformalnie, „rozmowy o kodzie”).

ALGOL 68 był pierwszym (i prawdopodobnie jednym z ostatnich) głównym językiem, dla którego sformułowano pełną formalną definicję przed jej wdrożeniem.

Formularze

Specyfikacja języka programowania może przybierać różne formy, w tym następujące:

  • Jawna definicja składni i semantyki języka. Chociaż składnia jest zwykle określana za pomocą gramatyki formalnej, definicje semantyczne mogą być pisane w języku naturalnym (np. Podejście przyjęte dla języka C ) lub semantyką formalną (np. Specyfikacje Standard ML i Scheme ). Godnym uwagi przykładem jest język C, który zyskał popularność bez formalnej specyfikacji, zamiast tego został opisany jako część książki The C Programming Language (1978), a dopiero znacznie później został formalnie znormalizowany w ANSI C (1989).
  • Opis zachowania kompilatora (czasami nazywanego „tłumaczem”) dla języka (np. Język C ++ i Fortran ). Z tego opisu należy wywnioskować składnię i semantykę języka, który można zapisać w języku naturalnym lub formalnym.
  • Modelu wdrożenia , czasami napisane w języku jest określony (np Prolog ). Składnia i semantyka języka są wyraźne w zachowaniu implementacji modelu.

Składnia

Składni języka programowania jest zwykle opisywana za pomocą kombinacji dwóch następujących elementów:

Semantyka

Sformułowanie rygorystycznej semantyki dużego, złożonego, praktycznego języka programowania jest trudnym zadaniem nawet dla doświadczonych specjalistów, a wynikająca z tego specyfikacja może być trudna do zrozumienia dla każdego poza ekspertami. Poniżej przedstawiono niektóre sposoby opisu semantyki języka programowania; wszystkie języki używają co najmniej jednej z tych metod opisu, a niektóre języki łączą więcej niż jedną

Język naturalny

Najczęściej używane języki są określane za pomocą opisu ich semantyki w języku naturalnym. Opis ten ma zwykle formę podręcznika referencyjnego dla języka. Podręczniki te mogą obejmować setki stron, np. Wersję drukowaną The Java Language Specification, wyd. ma 596 stron długości.

Nieprecyzyjność języka naturalnego jako narzędzia do opisu semantyki języka programowania może prowadzić do problemów z interpretacją specyfikacji. Na przykład semantyka wątków Java została określona w języku angielskim, a później odkryto, że specyfikacja nie zapewnia odpowiednich wskazówek dla implementatorów.

Semantyka formalna

Semantyka formalna jest zakorzeniona w matematyce. W rezultacie mogą być dokładniejsze i mniej niejednoznaczne niż semantyka podawana w języku naturalnym. Jednak często dołączane są dodatkowe opisy semantyki w języku naturalnym, aby pomóc w zrozumieniu formalnych definicji. Na przykład norma ISO dla Modula-2 zawiera definicję języka formalnego i naturalnego na przeciwnych stronach.

Języki programowania, których semantyka została formalnie opisana, mogą przynieść wiele korzyści. Na przykład:

  • Semantyka formalna umożliwia matematyczny dowód poprawności programu;
  • Semantyka formalna ułatwia projektowanie systemów typów i udowadnia prawidłowość tych systemów;
  • Semantyka formalna może ustalić jednoznaczne i jednolite standardy implementacji języka.

Automatyczne wsparcie narzędziowe może pomóc w osiągnięciu niektórych z tych korzyści. Na przykład, automatyczne sprawdzanie twierdzeń lub sprawdzanie twierdzeń może zwiększyć zaufanie programisty (lub projektanta języka) do poprawności dowodów dotyczących programów (lub samego języka). Moc i skalowalność tych narzędzi jest bardzo zróżnicowana: pełna weryfikacja formalna wymaga dużej mocy obliczeniowej, rzadko wykracza poza programy zawierające kilkaset wierszy i może wymagać znacznej pomocy ręcznej ze strony programisty; bardziej lekkie narzędzia, takie jak narzędzia do sprawdzania modeli, wymagają mniej zasobów i były używane w programach zawierających dziesiątki tysięcy wierszy; wiele kompilatorów stosuje statyczne kontrole typów do każdego programu, który kompilują.

Realizacja referencyjna

Implementacja referencyjna jest pojedyncza implementacja języka programowania, który jest wyznaczony jako autorytatywny. Zachowanie tej implementacji ma na celu zdefiniowanie właściwego zachowania programu napisanego w języku. To podejście ma kilka atrakcyjnych właściwości. Po pierwsze, jest precyzyjny i nie wymaga ludzkiej interpretacji: spory co do znaczenia programu można rozstrzygnąć po prostu wykonując program na implementacji wzorcowej (pod warunkiem, że implementacja zachowuje się deterministycznie dla tego programu).

Z drugiej strony, definiowanie semantyki języka poprzez implementację referencyjną ma również kilka potencjalnych wad. Najważniejszym z nich jest to, że łączy ograniczenia implementacji referencyjnej z właściwościami języka. Na przykład, jeśli implementacja referencyjna ma błąd, to ten błąd należy uznać za zachowanie autorytatywne. Inną wadą jest to, że programy napisane w tym języku mogą polegać na dziwactwach w implementacji referencyjnej, utrudniając przenoszenie między różnymi implementacjami.

Niemniej jednak w kilku językach z powodzeniem zastosowano referencyjne podejście do implementacji. Na przykład uważa się , że interpreter Perla definiuje autorytatywne zachowanie programów w języku Perl. W przypadku Perla model dystrybucji oprogramowania typu open source przyczynił się do tego, że nikt nigdy nie stworzył kolejnej implementacji języka, więc kwestie związane z użyciem implementacji referencyjnej do zdefiniowania semantyki języka są dyskusyjne.

Zestaw testów

Definiowanie semantyki języka programowania w kontekście zestawu testów obejmuje napisanie szeregu przykładowych programów w tym języku, a następnie opisanie, jak te programy powinny się zachowywać - być może poprzez zapisanie ich prawidłowych wyników. Programy oraz ich wyjścia nazywane są „zestawem testów” języka. Każda poprawna implementacja języka musi następnie generować dokładnie poprawne wyniki w programach zestawu testów.

Główną zaletą tego podejścia do opisu semantycznego jest to, że łatwo jest określić, czy implementacja języka przechodzi pomyślnie zestaw testów. Użytkownik może po prostu wykonać wszystkie programy w zestawie testów i porównać wyniki z pożądanymi wynikami. Jednak, gdy jest używane samodzielnie, podejście zestawu testów ma również poważne wady. Na przykład użytkownicy chcą uruchamiać własne programy, które nie są częścią zestawu testów; w rzeczywistości implementacja języka, która mogłaby uruchamiać programy tylko ze swojego zestawu testów, byłaby w dużej mierze bezużyteczna. Jednak zestaw testów sam w sobie nie opisuje, jak implementacja języka powinna zachowywać się w każdym programie, którego nie ma w zestawie testów; ustalenie tego zachowania wymaga pewnej ekstrapolacji ze strony wdrażającego, a różni realizatorzy mogą się z tym nie zgodzić. Ponadto trudno jest używać zestawu testów do testowania zachowania, które jest zamierzone lub może być niedeterministyczne .

Dlatego w powszechnej praktyce zestawy testów są używane tylko w połączeniu z jedną z innych technik specyfikacji języka, taką jak opis w języku naturalnym lub implementacja referencyjna.

Zobacz też

Linki zewnętrzne

Specyfikacje językowe

Kilka przykładów oficjalnych lub roboczych specyfikacji językowych:

Uwagi