HackerScript

Table of Contents

• Struktura repozytorium
• Jak to dziala
• Szybki start
• Kolorowe CLI i pasek postepu
• Historia wersji
• Status projektu
• Dokumentacja
• Uwaga

Jezyk programowania ogolnego przeznaczenia. Zwykla fun kompiluje sie do prawdziwego Rusta (statyczne typy, bezpieczenstwo pamieci, zero-cost abstractions). direct [ …​ ] to ucieczka do czystego Pythona, wykonywanego przez wbudowany interpreter (PyO3) - dla tego niewielkiego fragmentu kodu, ktory nigdy nie bedzie wymagal wydajnosci.

Status	Bootstrap osiagniety + FFI 0.3 + workspace 0.4 - hackerc (transpilator) i hack3rc (kompilator AOT) sa dzis w calosci napisane w samym HackerScript (.hcs), nie w Pythonie/Rust jak w wersji 0.0.1. Menedzerem pakietow i narzedziem budowania jest bit - osobny projekt (napisany w H#, repozytorium bit-io/bit), ktory czyta Bit.hk, instaluje zaleznosci i wola hackerc. Od 0.3 dochodzi przeprojektowane FFI: get <extern:…​> use <static|dynamic> + region [ …​ ], get <c:…​>/get <cpp:…​> oraz native {C++} [ …​ ]. Od 0.4: get <work:czlonek[::plik]> (import DOWOLNEGO czlonka workspace, nie tylko core/std), sekcja [build] w Bit.hk usunieta (plik wejsciowy jest teraz zawsze cmd/main.hcs, bez konfiguracji), oraz naprawiony blad z duplikujacym sie cache/ w workspace (patrz Historia wersji).
Wersja	0.4 (ta - self-hostujaca sie, wydawana na GitHub Releases) - 0.0.1 to zamrozona wersja startowa sprzed bootstrapu (patrz Historia wersji).
Licencja	MIT (c) 2026 HackerOS Team

struct Point [
    x: Int,
    y: Int
]

fun distance_squared(p: Point) -> Int [
    end (p.x * p.x) + (p.y * p.y)
]

fun main() [
    let p = Point(3, 4)
    log("dist^2 =", distance_squared(p))

    direct [
        print("To jest czysty Python wykonywany wewnatrz binarki Rust.")
    ]
    end
]

Zobacz docs/hello-world/, docs/module-demo/, docs/showcase/ (ogromny, jednoplikowy przeglad niemal calego jezyka - zmienne, funkcje, struct/enum/match/impl, kolekcje, stringi, manual[…​], oraz FFI 0.3) i docs/ffi-demo/ (minimalny, samodzielny przyklad samego FFI: get<extern:…​> use<…​> + region, get<c:…​>/ get<cpp:…​>, i kompilowany build-time blok C++) - dzialajace przyklady, wszystkie zweryfikowane realna kompilacja i uruchomieniem (patrz naglowkowy komentarz kazdego pliku po instrukcje budowania). Oraz docs/SYNTAX.md - pelny opis skladni (w tym, od 0.4, get <work:czlonek[::plik]> - import dowolnego czlonka workspace) i docs/ROADMAP.md - pelna, szczera lista tego co jeszcze brakuje.

Struktura repozytorium

HackerScript/
  hackerc/cmd/          transpilator .hcs -> Rust, W CALOSCI w HackerScript (self-hosted)
    lexer.hcs              tokenizacja + resolve_escape (\n \t \r \e ...)
    parser.hcs              recursive-descent parser -> AST
    ast_nodes.hcs           definicje Expr/Stmt/typow AST
    typecheck.hcs           diagnostyki (bledy/warningi), builtin-y
    typeinfer.hcs           inferencja typow, sygnatury projektu
    codegen.hcs             AST -> tekst Rust (~3700 linii, najwiekszy plik)
    transpiler.hcs          spina lexer/parser/typecheck/codegen w calosc
    project.hcs             wielo-plikowe skladanie projektu, Cargo.toml
    formatter.hcs            formater kodu .hcs
    diagnostics.hcs          renderowanie bledow w stylu rustc (podkreslona linia)
    main.hcs                 CLI: build/check/lint/fmt (kolorowe, z paskiem postepu) - do 0.3: cli.hcs
    playground.hcs           demo/checker uzywany przez playground WASM
  hack3rc/cmd/         kompilator AOT (Cranelift), W CALOSCI w HackerScript
  Bit.hk                  workspace (czlonkowie: hackerc, hack3rc, libs/core, libs/std)
  libs/
    core/lib/memory/        4 alokatory: arena, chained_arena, stack_allocator, pool_allocator
    std/lib/                fs, io, string, math, path, json, toml, hk, env,
                             process, http, term (KOLORY + PASEK POSTEPU - nowe),
                             result, cybersecurity/ (constant_time_eq, shannon_entropy)
  playground/             checker HackerScript skompilowany do WASM (przegladarka, 0.4)
    cmd/main.hcs            statycznie linkuje hackerc przez get<work:...>, @wasm_export check_source
    web/                    index.html + main.js - dzialajaca strona w stylu Rust Playground
    web/README.md           dokladne kroki budowania (bit build --wasm + wasm-bindgen-cli)
  docs/
    hello-world/            minimalny dzialajacy przyklad (.hk + .hcs)
    module-demo/            przyklad systemu modulow (get <core:...>)
    showcase/               ogromny, jednoplikowy przeglad jezyka (0.3/0.4)
    ffi-demo/               samodzielny przyklad FFI 0.3 (extern/region/c/cpp)
    SYNTAX.md                 pelny opis skladni (w tym get <work:...>, 0.4)
    ROADMAP.md                 co jeszcze brakuje (szczegolowo, per-plik)
  scripts/                install.sh/remove.sh (HackerOS) + skrypty .hl
  .github/workflows/      CI (buduje I URUCHAMIA wygenerowany crate) + Release

Tip	Wczesniejsza architektura (hackerc/ w Pythonie) zostala calkowicie zastapiona kodem HackerScript powyzej - patrz Historia wersji jesli szukasz kontekstu tej zmiany. Wspolpraca z menedzerem pakietow bit jest opisana w docs/BIT.md.

Jak to dziala

1. fun → hackerc generuje prawdziwy Rust (struct → struct
impl new(), manual[] → unsafe{}, List<T> → Vec<T>, parametry struct/List/Str automatycznie dostaja &/&mut zamiast przenoszenia wlasnosci).

2. direct [ …​ ] → surowy Python wykonywany w trakcie dzialania programu przez Python::with_gil (PyO3, tryb auto-initialize) - Rust jest hostem.

3. get <core:memory::arena> → realnie importuje kod z libs/core/lib/memory/arena.hcs (system modulow: project.hcs dwufazowo zbiera sygnatury z calego projektu, zeby wywolania cross-plikowe tez dostaly poprawne &/&mut).

4. get <crates:nazwa> → prawdziwa zaleznosc Cargo. get <pypi/npm/jsr:…​> → pobierane przez bit install (bezposrednio z PyPI/crates.io/npm/JSR API, BEZ pip/cargo add/npm install).

5. bit install → instaluje zaleznosci z Bit.hk ([dependencies]): biblioteki z indeksu bit.io, repozytoria git (→ x ⇒ git <url> v1), sciezki lokalne oraz pakiety PyPI/crates.io/npm/JSR. Biblioteki HackerScript trafiaja do cache/libs/<nazwa>/ (tryb projektowy) albo ~/.hackeros/libs/<nazwa>/current/ (tryb wspolny) i sa importowalne wprost przez get <bit:nazwa[::plik]> (zrodla w lib/: lib/mod.hcs = caly pakiet, lib/<plik>.hcs = ::plik). bit ustawia BIT_LIBS dla hackerc; reszte (linkowanie get <c:…​>/get <cpp:…​> do wygenerowanego crate’a) robi bit build. Szczegoly: docs/BIT.md.

6. using <wersja> na poczatku pliku (albo [package] using w Bit.hk) → deklaruje wymagana wersje hackerc. Jesli nie jest zainstalowana, bit pobiera ja automatycznie z GitHub Releases:

   https://github.com/HackerOS-Linux-System/HackerScript/releases/download/v<wersja>/hackerc

   (przez curl, z natywnym paskiem postepu, cache’owana w cache/env/hackerc-<wersja>/) - patrz bit.

7. bit build → hackerc build (generuje cargo crate) → cargo build (jedyne miejsce, gdzie bit uzywa cargo - jako kompilator, nie menedzer pakietow). Uruchomiony na korzeniu z [workspace] w Bit.hk (patrz glowny /Bit.hk tego repo) buduje KAZDEGO czlonka majacego wlasny, uruchamialny plik wejsciowy - analogicznie do cargo build w workspace Cargo.

8. (0.4) Plik wejsciowy KAZDEGO budowalnego czlonka/projektu jest teraz ZAWSZE cmd/main.hcs - sekcja [build] → entry ⇒ <sciezka>, pozwalajaca to kiedys nadpisac, zostala calkowicie usunieta z formatu .hk (dokladny analog tego, jak Cargo samo znajduje src/main.rs, bez zadnego pola w Cargo.toml) - patrz find_cmd_entry() w bit.

9. (0.4) get <work:czlonek[::plik]> → importuje lib/mod.hcs (albo lib/<plik>.hcs) DOWOLNEGO czlonka [workspace] → members, nie tylko uprzywilejowanych core/std (ktore maja wlasne, krotsze aliasy get <core:…​>/get <std:…​>, dzialajace identycznie) - analog Rustowego use nazwa_membera::modul::*; w workspace Cargo. Patrz docs/SYNTAX.md.

10. (0.4) cache/ jest teraz NAPRAWDE wspolny dla calego workspace, niezaleznie z ktorego czlonka odpalisz bit (hackerc/, bit/, libs/core/, libs/std/ czy korzenia) - wczesniej kazdy z nich (majac WLASNY, poprawny Bit.hk) dostawal WLASNY, osobny cache/ zamiast dzielic jeden z korzeniem, dokladnie tak jak cargo w workspace zawsze dzieli jeden target/. Patrz bit.

Szybki start

# hackerc i bit sa binarkami natywnymi (self-hosted) - najprosciej
# pobrac gotowe wydanie:
curl -L --fail -o hackerc \
  https://github.com/HackerOS-Linux-System/HackerScript/releases/download/v0.4/hackerc
chmod +x hackerc

./hackerc check docs/hello-world/Bit.hk
./hackerc build docs/hello-world/cmd/main.hcs -o /tmp/out
cd /tmp/out && cargo run   # wymaga zainstalowanego Rust

Albo, w projekcie zarzadzanym przez bit (patrz Bit.hk):

bit init --name moj-projekt
cd moj-projekt
bit build --release   # pobierze wlasciwy hackerc automatycznie (using <wersja>)

Kolorowe CLI i pasek postepu

hackerc build/bit build/check/lint/fmt maja teraz kolorowe wyjscie (zielony = sukces, czerwony = blad, cyan = nazwy/etykiety) i realny, procentowy pasek postepu renderowany w miejscu (nie osobna linia per krok) - patrz nowy modul libs/std/lib/term.hcs (get <std:term>).

• Kolory wylaczaja sie automatycznie gdy ustawiona jest zmienna srodowiskowa NO_COLOR (https://no-color.org).

• Pasek dla hackerc build: 4 kroki (parsowanie → sygnatury projektu → sprawdzanie typow → generowanie crate’a Rust).

• Pobieranie binarek (bit install, auto-pobieranie hackerc wg using <wersja>) uzywa natywnego paska curl --progress-bar zamiast wlasnego renderowania - bit nie ma dostepu do bajtow strumienia w trakcie trwania procesu pobierania (patrz docs/ROADMAP.md, sekcja "CLI - kolory i pasek postepu", po wyjasnienie dlaczego).

Historia wersji

0.0.1	Zamrozona. Wersja startowa: hackerc w Pythonie, bit (cli/hk-parser) w Rust z clap/reqwest. Nie jest juz rozwijana - punkt odniesienia "skad zaczelismy".
0.1	Bootstrap. hackerc i bit przepisane w calosci na sam HackerScript (.hcs), kompilowane przez wlasny transpilator do Rusta. Pierwsze wydanie publikowane binarnie na GitHub Releases pod v0.1.
0.2	Wewnetrzna. Kolorowe CLI i realny pasek postepu (libs/std/lib/term.hcs, get <std:term>) dla hackerc build/check/lint/fmt i bit odpowiednikow - patrz "Kolorowe CLI i pasek postepu" wyzej.
0.3	Przeprojektowane FFI. Stare, jedno-funkcyjne extern "lib" fun nazwa(…​) zastapione przez get <extern:sciezka> use <static|dynamic> + region [ …​ ] (dowolnie wiele sygnatur naraz, powiazanych z jedna biblioteka). Dolozono get <c:nazwa>/get <cpp:nazwa> (zaleznosci C/C budowane przez crate `cc`) oraz `native {C} [ …​ ]` (analog native {JavaScript}, ale kompilowany build-time zamiast interpretowany). Mechanizm using <wersja> pobieral wtedy v0.3. Pelny opis skladni: docs/SYNTAX.md, sekcja "FFI: extern/region/c/cpp".
0.4	Ta wersja. Workspace + porzadki + WASM. Szesc zmian: get <work:czlonek[::plik]> i include <work:czlonek[::plik]> - ogolny import/statyczne linkowanie DOWOLNEGO czlonka [workspace] → members (nie tylko core/std), analog Rustowego use nazwa_membera::…​;; sekcja [build] w Bit.hk calkowicie usunieta - plik wejsciowy jest teraz zawsze cmd/main.hcs, bez zadnej konfiguracji (przy okazji naprawiono realny blad: [build] → entry ⇒ cli.hcs w hackerc/Bit.hk nigdy nie wskazywalo na istniejacy plik, wiec hackerc byl po cichu pomijany przy bit build na calym workspace - plik przemianowany na cmd/main.hcs); naprawiony cache/ - wczesniej kazdy czlonek workspace majacy WLASNY Bit.hk (hackerc/, bit/, libs/core/, libs/std/) dostawal WLASNY, osobny katalog cache/ zamiast dzielic jeden wspolny z korzeniem, jak cargo dzieli jeden target/ w calym workspace; oraz @wasm_export + bit build --wasm - pierwszy dzialajacy pipeline do WASM, uzyty w nowym playground/ (playground/cmd/main.hcs linkuje statycznie caly checker hackerc`a przez `include <work:hackerc::…​>, playground/web/ to gotowa strona w stylu Rust Playground). Mechanizm using <wersja> pobiera teraz v0.4. Pelny opis: docs/SYNTAX.md (sekcje “get <work:…​>”, “include <work:…​>”, “@wasm_export”) i docs/ROADMAP.md (sekcja "Zrobione w 0.4").

Status projektu

Caly kompilator (hackerc/cmd/) i kompilator AOT (hack3rc/cmd/) sa dzis napisane w HackerScript i weryfikowane strukturalnie przez hackerc check + inspekcje, a koncowo przez CI (.github/workflows/ci.yml), ktore kompiluje i uruchamia wygenerowany crate na prawdziwym runnerze z Rustem - to jedyne miejsce, gdzie poprawnosc generowanego kodu Rust jest dzis realnie zweryfikowana automatycznie przy kazdym PR.

W trakcie przepisywania na self-hosting znaleziono i naprawiono kilka realnych bledow odziedziczonych z oryginalnej wersji Pythonowej (m.in. != mylone z komentarzem, Vec::len() zwracajace usize a nie i64, przenoszenie wlasnosci struct/Vec/String przy wielokrotnym uzyciu tej samej zmiennej).

Pelna, szczera lista tego co jeszcze brakuje - braki jezykowe bootstrapu (iteracja po Dict, Set, numery linii w AST, prawdziwe ParseError, log() dla struct/enum), uproszczenia per-plik (codegen.hcs/typeinfer.hcs/project.hcs/main.hcs/ formatter.hcs/parser.hcs), luki w libs/std poza rdzeniem, oraz gapy w FFI 0.3/0.4 (kompilacja wlasnego zrodla .c/.cpp z projektu przez cc zamiast linkowania systemowej biblioteki dla get <c:…​>/get <cpp:…​>) - jest w docs/ROADMAP.md, razem z lista tego, co juz naprawiono w 0.4 (wspolny cache/ dla workspace, usuniecie [build], get <work:…​>).

Dokumentacja

• docs/SYNTAX.md - pelny opis skladni (w tym FFI 0.3: get <extern:…​> use <…​> + region [ …​ ], get <c:…​>/get <cpp:…​>, native {C++} [ …​ ]).

• docs/ROADMAP.md - co brakuje, szczegolowo i per-plik

• Format .hk: https://hackeros-linux-system.github.io/HackerOS-Website/tools-docs/hk.html

Uwaga

HackerScript osiagnal juz bootstraping.