SpaceTraffic

Dotazy vyplývající ze schůzky s Lipkou:
1. Do příkazů by asi měl být přidán příkaz ELSE. Switch asi nemá cenu, nebo jo?
2. Lipka dal návrh, že vše co by se týkalo lodí a zkoumání herního světa by mohlo být implemntováno jako knihovní funkce. Co ty na to? Zdá se Ti to jako rozmný nápad?
3. Co si myslíš o dynamických datových strukturách? Podle mého názoru se bez nich obejdem. Souhlasíš?
4. Odmocnina by asi spíš měla být SQRT místo příkazu SQR, který by měl být pro mocninu.
5. Jaké datové typy budem potřebovat? Myslím, že bychom mohli vystačit s jedním celým číslem a desetiným číslem. Pak si nejsem jistej jestli bude ještě STRING, nebo místo toho vytvořit například datový typ PLANETA, LOĎ atd. Případně udělat vyšší datový typ LOĎ, který by měl např. jméno, který by bylo STRING, ale to už je podle mě zbytečně složitý.
6. Jak se bude interpretovat? Předpokládám, že rovnou, nebo myslíš, že by mělo smysl napřed překládat do bytecodu jako např. u Javy?
7. Budem povolovat funkce či jiný typ podprogramu? Asi je to zbytečný aby tam byly, ale nejsem si uplně jistej.

Dík

1. ELSE není třeba, při návrhu jsem vycházel ze Spectrum BASICu a ten nepodporoval větev ELSE u příkazu IF. Praxe byla ta, že pokud bylo třeba tuto konstrukci udělat, při splnění podmínky se použil příkaz skoku. Tím lze ELSE plně nahradit. Cílem není vytvořit jazyk se všemi featurami moderních jazyků, ale jazyk, který umožňuje řešit problémy ve hře. Je záměrné, že je jazyk omezen a mnoho běžně používaných "vychytávek" je zde třeba řešit složitou cestou.

2. Rozhodně je třeba najít všechny potřebné funkce pro zkoumání světa, které bude hráč potřebovat. Nevím, co se myslí v tomto případě knihovníma funkcema, v zásadě je třeba rozšířit jazyk o sadu speciálních příkazů (doménově specifických). Jejich implementace je dvoufázová: definovat příslušné akce na herních objektech - příslušné API bude stejné i pro interní používání enginem - a potom vytvoření příslušného mechanismu volání z jazyka. Hráč by obecně neměl mít přístup k funkcím, které nejsou přístupné přes uživatelské rozhraní a je třeba se snažit o jednotnost, jinak se celá implementace rozpadne.

3. Datové struktury nejsou nutně třeba. Pokud by bylo třeba pracovat s dynamickými daty, lze přidělat funkce na přímý přístup do paměti a nechat hráče, ať se snaží sám.

4. Odmocnina byla skutečně jen SQR (viz: http://www.worldofspectrum.org/ZXBasicManual/zxmanchap9.html). Víceméně jde jen o syntaxi, určitě neni problém použít slovo SQRT. Mocnina se v těchto jednoduchých jazycích nedělá. Je chyba využívat funkce typu Math.pow pro druhou a třetí mocninu čísla a pokud je třeba vyšší, jen ať si člověk ten cyklus napíše sám a vidí, že to neni triviální operace.

5. Rozhodně stačí základní datové typy. integer, float a string a jednoduchá pole (ne asociativní). Rozhodně bych se vyhnul pokusům o začlenění objektových konceptů do jazyka - to nebylo nikdy záměrem a není to třeba. Každá funce vrací jen tyhle hodnoty, takže pokud budu chtít zjistit o lodi víc informací, musím zavolat víc funkcí. Všechny proměnné jsou globální a typ se určuje při inicializaci podle ukládané hodnoty. Pak už nejde změnit. Jména proměnných typu string končí znakem $. To je taková vtipná jazyková pomůcka pro interpreter, dnes už nemá takový význam, ale snažil bych se držet standardu basicu.

6. Určitě přímá interpretace po řádkách kódu (= 1 příkaz). Bytecode je v tomhle případě nesmysl a brutální overkill. To by se to rovnou mohlo překládat do MSIL ("bytekód" do kterého se překládá C#).

7. GO SUB a RETURN je jediná přímá konstrukce podprogramu. Možná bych povolil nahrání jiného programu (příkaz LOAD) a jeho spuštění, ale to rozhodně nepatří mezi must have featury. A oddělenej problém je jestli umožnit předání parametrů takto nahranému programu (mělo by smysl jen při umožnění přímého přístupu do paměti, kdy by se paměť nesmazala a bylo by možné najít data předchozího programu).

Jen bych ještě chtěl doplnit: cílem je vytvořit uměle omezené programovací prostředí. Současné programovací jazyky a počítače umožňují začátečníkům přistupovat k programování, jako by neexistovali žádné limity. Přitom je třeba na ně myslet vždycky, ne až při odstranění problémů. To je třeba se naučit a to by naše hra měla poskytnout právě díky jazyku, který je omezený a těžkopádný a nutí programátora řešit základní věci, které za něj normálně řeší mašina.