FocusLexer - dokumentacja

Po 2 dniach w końcu sporządziłem pełną dokumentację języka FocusLexer w wersji 0.1 alpha.

Dzięki temu nie będę pisał po omacku tylko wedle dokumentacji i założeń :). Po implementacji FocusLexera zacznę pisać FocusLexer w FocusLexer i stworzę ręcznie Parsher by móc po tym przystąpić do pisania FocusParshera i kolejnej dokumentacji.

W następnym kroku zajmę się upodabnianiem i upraszczaniem FocusLexera by można było w nim pisać na kilka sposobów - na przykład za pomocą wyrażeń regularnych jak w Lex albo Flex.

Później pod klawiaturę trafi "FocusLexer SynEdit edition", wersja FocusLexera do tworzenia algorytmów kolorujących składnię wybranego języka.

Work, work, work...

Po przerwie

Na pewien czas porzuciłem bloga "focuscore". Porzuciłem na rzecz poszukiwania sensu mojej dalszej pracy. Czy ktoś już to napisał? Czy to już powstało? Jaki ma to sens? Czy warto? Czy nie jestem za głupi i czy sięgam wzrokiem wystarczająco daleko by stwierdzić: "Ten tunel ma światełko".

Zanim coś wrzucę tutaj większego, postanowiłem, że najpierw sporządzę dokumentację i przedstawię ją pewnemu dr hab. na mojej uczelni. Byłem u niego dawno temu... Na początku moich prac. Pewnie już zapomniał. Ale za to kilka jego rad utkwiło mi dobrze w pamięci.

Cierpliwości. Ciągle pamiętam o tym projekcie i poszukuję prawdy... Po co pisać rzeczy nieprzemyślane?

PS. Ciekawe czy nakład pracy umysłowej i poświęconego czasu w moich pracach kiedyś się zwróci? Warto?

Czas Leci

Trudno określić jak szybko postępują prace nad "Kompilatorem" jako całości. Język do tworzenia lexerów okazuje się mało przydatny/praktyczny.

Obecnie pracuję nad algorytmem, bazującym na wyrażeniach regularnych - umożliwia ich używanie (jak w perlu, php) jak i generowanie lexelrów (coś jak lex i flex dla yacc/bisona).

New News soon...

Edytor FocusParser :)

W końcu małe co nieco :). Przepisałem parser pascala z pascala do mojego nowego języka do tworzenia parsherów :). Może to UberScript ? :) Raczej jego nagłówek.

Na pierwszy rzut oka można powiedzieć że wygląda dość masochistycznie i topornie, jednak w istocie jest to bardzo prosty, intuicyjny język (jego opis zamieszczę niebawem).

W drodze przetwarzania jest z niego generowana składnia w Pascalu. Język ten jest pierwszą z kilku warstw kompilatora. Zapraszam do oglądania i komentowania :)

Link Do Kodu Źródłowego

Książka - "Kompilatory - Reguły, metody i narzędzia"

W końcu! :) Po dość długim czasie udało mi się zdobyć książkę którą miałem upatrzoną od dość dawna, aczkolwiek nie miałem sposobności na jej zdobycie. Raz, że była zbyt droga (160zł) a dwa nie byłem studentem. Jako, że obecnie "jeszcze" jestem studentem a w mojej bibliotece (o dziwo) są aż 3 egzemplarze tej książki, pokusiłem się o wypożyczenie jednej z nich :).

Co dalej? Pożyjemy - zobaczymy.

Teoria Wizualnego Tworzenia Kompilatorów

W związku z pracami nad internetowym systemem DaThoX linki przestały działać - dzięki za spostrzeżenie - naprawiłem. Nastąpiła dość długa przerwa, spowodowana studiami, trochę też robotą dla mojego gamedev teamu. Nic to :). Zamierzam kontynuować dotychczasowe blogowe osiągnięcia - co najmniej jeden post na jeden miesiąc.

Podczas męczenia się z Uber Script powstała wizja narzędzia nadrzędnego dla "Uber Scripta" - mianowicie "Langu Age". Wizja systemu logicznego dla Kompilatorów. Jako, że na jednym kompilatorze (tudzież języku skryptowym JIT) nie chciałbym poprzestać, projektuję na wyrost techniki które chciałbym wykorzystać w przyszłości.

Langu Age - narzędzie trzymające wszystkie dane, struktury kompilatora w ramach spójnej całości. Prosta edycja wyrażeń regularnych, tworzenie błędów na poziomie wstępnego przetwarzania języka oraz logicznej analizy. Mam nadzieję, że moja wizja przyniesie wymierne korzyści :)

Chciałbym zauważyć iż nie wzoruję się na żadnym znanym rozwiązaniu a tworzą całość wg. mojej koncepcji (dzięki temu nie jestem w żaden sposób ograniczony - z jednej strony może powstać coś innowacyjnego a z drugiej coś gorszego od znanych rozwiązań). Oglądając różne kompilatory najbardziej mnie dobijała ich struktura - dość hermetyczne w wprowadzaniu ulepszeń (może moje subiektywne odczucie? a może widziałem zbyt mało przykładów).

Nic to :).

Langu Age powinien wspomagać następujące warstwy kompilatora:

Stream - Odpowiada za wczytywanie danych (z plików źródłowych). Jest dość potrzebna by zapewnić obsługę znaków UTF-8, UTF-16 etc.

Lexer - Wczytuje "język". Język nieco bardziej niskopoziomowy. Trudno mi to dokładnie nazwać z powodu mojej niewiedzy, ale chodzi o czyszczenie źródeł (pomijanie) "white chars" i wykrywanie błędów w stylu "Illegal character in input file: 'ą' ($B9)" w przypadku gdy np. słowa kluczowe czy też nazwy zmiennych nie mogą zawierać polskich znaków (składają się tylko z liter angielskiego alfabetu i +/- znaku w stylu _).

Log Lexer - Na podstawie wstępnie oczyszczonych źródeł przez warstwę Lexer, następuje przetwarzanie przez Log Lexer. Ta warstwa dba o logikę języka, zgłasza błędy wyższego poziomu - "Declaration expected but identifier 'xxx' found"

Script Lex / Optimisation - Trudna decyzja. Być może osobne warstwy a być może złączone w jedną. Dane przetwarzane przez Log Lexer będą zmieniane w język skryptowy (NIE JIT - więc jeśli nie dam rady zaimplementować wersji IA-64 i tak skrypty będą działać na 64 bitach ponieważ mój Uber Language będzie trawiony na kod Delphi a 64 bitowa wersja kompilatora Delphi jest już w drodze pod kodową nazwą Commodore64). Tylko pytanie - optymalizacje w trakcie zamiany na język skryptowy czy tuż po niej(?) (bardziej prawdopodobne jest pierwsze rozwiązanie).

Odnośnie Script Lex nie sposób nie wspomnieć iż przetrawiony kod na język skryptowy będzie wspólny dla różnych języków jakie będzie można tworzyć przez Langu Age i Uber Scripta. Zachowanie takie jest bardzo właściwe i pożądane - będzie można szlifować optymalizacje niezależnie od języka w którym programujemy :D, oraz dodawać platformy docelowe jakie dusza zapragnie - jedna baza danych, różne języki, i wiele platform (cel baaardzo daleki i abstrakcyjny :)).

Binary Code - Przetwarzanie języka skryptowego do plików pośrednich, skryptów JIT. Nic dodać nic ująć :).

Linker - Linkowanie do plików w stylu EXE, DLL...

Podsumowanie Langu Age

Koncepcja szalona. Projekt długoterminowy z niepewną przyszłością. Dziś wydaje się mało realny, jak wiele rzeczy o których myślałem kiedyś - nigdy tego nie napiszę (a dzisiaj działają w pełni ukończone :)).

nie wiem czy moja koncepcja jest słuszna i jak sobie poradzę z Mem Menagerem, RTTI i wieloma innymi mechanizmami. Jednak powoli i konsekwentnie. Na początek muszę dojść do celu realizując tylko części projektu - język skryptowy z moich marzeń.

Parser

Plik: Parser_TEST.rar

Po wielu różnych parserah w końcu doszedłem do odpowiedniej jego formy. Zawsze wychodziły za bardzo oddalone od kompilacji/przetwarzania logicznego albo zbytnio z nim powiązane. Pierwszy raz mam poczucie, że to jest dokładnie to co być powinno :). Parsery można pisać na wiele sposobów - elastycznie (łatwo je dostosować do dowolnej składni) czy też sztywno - przeznaczone dla konkretnego języka (co może zaowocować wydajnością). Są też dostępne generatory parserów lecz te zupełnie mi nie odpowiadają. Po pierwsze zastanawiająca jest wydajność czegoś takiego, a po drugie chciałbym by UberScript był niezależny od zewnętrznych narzędzi - nie ma to jak być na swoich śmieciach ;).

To działa ;):
wykrywanie błędów na poziomie parsera (w stylu error_constant_expression_expected za znakiem # czy error_unterminated_string, error_syntax_error_in_real_number), składanie w locie stringów, czyli na przykład takiego czegoś: #72#$45'''Napis w apostrofach'''#$FFFFFFFFF#55' :D działa' w jednym "pop" :) (co chyba nie jest niczym nadzwyczajnym?). Mam radochę :D.

Parser jest tylko niewielką częścią UberScript jednak najważniejszą ponieważ całość (przetwarzanie logiczne, generowanie binarek) odwołuję się do niego setki razy i dlatego tak ważna jest jego wydajność, niezawodność i sposób przekazywania danych dalej.

TESTY. Może ktoś miałby ochotę posprawdzać czy Parser działa bez zastrzeżeń? Byłbym wdzięczny za wykrycie jak największej liczby błędów :P. (parser pisałem na 100% zgodności z parserem Delphi - mam nadzieję, że się udało). A błędy jak nie teraz to i tak wyjdą kiedyś przy okazji :)...

PS. Zrezygnowałem jedynie z zabytkowych Delphi Caret Chars (które nie działają już poprawnie w najnowszych wersjach Delphi).

PS.PS. Parser do wstawek asm będzie bardzo podobny, właściwie taki sam tylko z kosmetycznymi poprawkami (drugie apostrofy " " do napisów i specyficzne nazwy etykiet)