Specyfikacja języka Junexis 0.2
Ta robocza referencja opisuje zapis programu, udokumentowane kontrakty i ich ograniczenia. Nie zawiera instrukcji instalacji, dokumentacji providerów, roadmapy ani historii implementacji.
Status dokumentu
Robocza referencja wersji 0.2 Experimental. Nie jest nowym wydaniem języka. Opracowano ją na podstawie gramatyki i istniejących kontraktów w repozytorium. Może być publikowana jako dokument roboczy; nie stanowi kompletnej, stabilnej specyfikacji normatywnej. Luki są jawnie wskazane w ograniczeniach i potwierdzonych lukach; nie zastępuje ich zachowanie jednego backendu.
| Oznaczenie | Znaczenie |
|---|---|
| Reguła składni | Zapis dopuszczany przez wskazaną regułę gramatyki. |
| Znaczenie | Właściwość konstrukcji opisana przez specyfikację lub kontrakt semantyczny. |
| Ograniczenie | Granica stosowalności reguły, gwarancji lub zakresu 0.2. |
| Nierozstrzygnięte | Nie ma dostatecznej podstawy do podania jednej obowiązującej reguły. |
„Musi” określa wymaganie poprawności. „Nie gwarantuje” wyklucza wyciąganie wniosku wykraczającego poza opisany kontrakt. Nie każdą regułę znaczeniową wykrywa obecny kompilator.
Struktura jednostki źródłowej
Importy poprzedzają deklaracje najwyższego poziomu. Instrukcje wykonywalne, takie jak
send, nie są samodzielnymi deklaracjami najwyższego poziomu.
program
: importDeclaration* topLevelDeclaration* EOF
;
Układ referencji
- Elementy leksykalne — identyfikatory, słowa kluczowe i literały.
- Typy — nazwy typów, kolekcje, unie i typy komunikacyjne.
- Deklaracje danych i funkcji.
- Zadania oraz stan i czas.
- Wyrażenia i instrukcje.
- Komunikacja i połączenia zadań.
- Platformy i wiązania protokołów.
- Importy i zakres nazw.
- Deklaracje storage — składnia, warunki poprawności i granice potwierdzonego wykonania.
- Granica extern i bloki metadanych.
Pełna gramatyka ANTLR stanowi załącznik składniowy. Rejestr przykładów podaje wynik kontroli każdego fragmentu.
Granica kontroli przykładów
„Przykład poprawny” oznacza tu pełną jednostkę przyjętą przez check.
Nie jest to dowód wykonania, zgodności wszystkich backendów ani kompletności semantyki.
Przykłady błędne zawierają konkretną wadę składni lub kontrolowanego warunku semantycznego; ich odrzucenie musi pochodzić
z diagnostyki języka, a nie błędu manifestu lub środowiska.