Whirlpool model návrhu/vývoje Perlu 6

30.7.2010 11:47 | Přečteno: 1635× | Ostatní

Poněkud delší reakce na názor v jedné diskuzi.

Psaní kompilátoru je to poslední, co by mělo trápit návrháře jazyka, ne? Primární je uživatelnost jazyka, ne složitost kompilátoru...

Larry Wall označuje způsob návrhu Perlu 6 jako whirlpool model (model víru). Při psaní testů a implementaci zjistíte co je ve specifikaci špatně, takže upravíte specifikaci, upravíte testy, upravíte implementaci, vyhodnotíte co je špatně a zase znovu upravit specifikaci, uprati testy, ... pak začnete psát první aplikace a knihovny a zase znovu. Tím se dostanete právě k té uživatelnosti jazyka. Navrhnout jazyk bez psaní v jeho kódu nebo psaní kódu bez možnosti spustit jej je nesmysl.

Specifikací/návrhů, které byly psány bez implementace existuje bezpočet. Dobře víme kolik chyb, rozporů a nejednoznačností v nich je.

Myslím si, že napsat implementaci dynamického programovacího jazyka jen podle specifikace nejde. Perl 6 za správnou implementaci jazyka (určité verze) považuje tu, která splňuje existující testy Perlu 6 (pro tuto verzi). Testy jsou v podstatě součástí specifikace. Testových případů jsou tisíce a další tisíce se musí ještě dopsat.

Programátor by neměl používat nespecifikovanou/netestovanou funkci jeho Perl 6 kompilátoru. Měl by test napsat a protlačit jej do jazyka. Když to neudělá, tak se může stát, že funkce nebude v příští verzi podporována (bez zmínky v changelogu). To je velký rozdíl oproti Perlu 5. V Perlu 6 jsou si všechny implementace rovny. Kvalita se dá měřit počtem splněných testů.

Perl 5 ani specifikaci nemá. V případě, že je dokumentace v rozporu s kompilátorem perl, tak jde o chybu dokumentace. Svou roli zde hraje důraz na zpětnou kompatibilitu (jazyk má přes 20 let). Perl 5 je jeden a tak to asi i zůstane.

Python, Ruby, PHP a další moc nesleduji. Existují zde "alternativní" kompilátory. Nevíte jak je to u nich? Je to jako u Perlu 6, že správnou implementací můžete napsat podle oficiální specifikace (oficiálních testů jazyka)? Nebo jako u Perlu 5, že specifikace je jen tak zhruba a při psaní kompilátoru musíte porovnávat s hlavní implementací, která určuje co je ten správný Python/Ruby?        

Komentáře

[Ladicek]

V Ruby existuje projekt RubySpec – – – který vznikl právě z potřeb alternativních implementátorů

[frEon]

a hlavne ruby ceka iso standartizace: kuk

[Marek Bernát]

Whirlpool model je fajn. Je to podobné ako prototypovanie pri návrhu aplikácií. A obecnejšie je to veda: vytvoríš teoretický model a potom ho overuješ a upravuješ podľa experimentov

Na druhej strane, ak niekto plánuje písať stabilný program, ktorý musí vydržať niekoľko rokov, tak asi neni moc zábavné, keď sa mu každý týždeň mení špecifikácia jazyka pod rukami. Starý problém rolling updates Takže rozumnejšie asi je mať release cycles (napr. po 5 rokoch). Vždy vydať špecifikáciu jazyka, nechať ľudí ho pár rokov používať a tvoriť v ňom programy, a tie skúsenosti reflektovať do novej verzie (plus mínus ako to robí Scheme s RnRS).

Čo sa týka Pythonu, tak tam je štandardná implementácia v C, ale hlavná je špecifikácia a vďaka nej existuje aj kopa alternatívnych implementácií. Python napísaný v pythone, kompilátory do bytekódu rôznych virtuálnych mašín a pod. Zaujímavejšie je to napr. s Common Lispom alebo Scheme, kde žiadna štandardná implementácia neexistuje, máš len desiatky rôznych implementácií (viac či menej podporujúcich špecifikáciu).

[Trained.Monkey]

Ona i Scala ktera je 'ultra hard typed' ma dost slozity kompilator. Kompilace take trva klidne i 60x dele nez srovnatelny kod v Jave.

[Jakub Lucký]

Nejsem si jist, jestli to tak má být, ale podle mě nejsme ve sporu...

Jinak oceňuju přínosné informace o vývoji...

[mj41]

Myslel jsem to tak, že bez implementace se nedostanete k dobré specifikaci tj., že psaní kompilátoru musí návrháře zajímat.

Navíc u dynamického jazyka jako je Perl 6, který je založen na gramatice, která půjde za běhu měnit je to ještě složitější. Proto sám Larry píše STD.pm6, aby mohl pokračovat v návrhu jazyka.

[Jakub Lucký]

Aha, to jsem se asi špatně vyjádřil...

Já jsem v původní myšlence mínil, že složitost implementace uvnitř kompilátoru by neměla zatěžovat hlavu člověku, který vymýšlí featury jazyka... tj. Nemělo by být: "Hm, tohle tam dávat nebudu, to by bylo strašně složité naprogramovat"

[Marek Bernát]

Tak s týmto absolútne nesúhlasím. Návrhár jazyka musí byť zároveň schopný aj napísať jeho kompilátor, aby mal aspoň nejakú predstavu, či je niektorá vlastnosť vôbec realizovateľná v praxi. Nie všetky informatické problémy sú rozumne riešiteľné. A nie každá vlastnosť je vôbec rozumne programaticky podchytiteľná. Toho všetkého si musí byť návrhár vedomý, inak nikdy nevznikne nič viac než návrh.

[Jakub Lucký]

No, realizovatelné to musí být, to je jasné, nějak přijatelně (s nějakou rozumnou složitostí)... Ale kompilátor se píše jednou, programů pak v daném jazyce stovky až tisíce...

[Marek Bernát]

O to väčší dôvod, aby bol ten kompilátor kvalitný

[Jakub Lucký]

No to nepochybně... Ale o to spíš by měl taky obsahovat vychytávky, se kterýma se program dobře píše...

[Marek Bernát]

Ako som už napísal pod druhým blogom, vysokoúrovňovosť a prívetivosť jazyka nebráni peknému návrhu. Naopak

[Ondrej 'SanTiago' Zajicek]

To by pak dopadlo jako C++, kde nektere rysy jazyka nebyly implementovane v kompilatorech snad deset let. Samozrejme ze je treba pri navrhu brat v potaz i to, jak dane rysy jazyka ovlivni implementaci. Obcas drobne detaily v navrhu jazyka mohou vyrazne ovlivnit efektivitu a eleganci implementace a nevhodne specifikovany. Jak vnejsi chovani (pro programatora v tom jazyce) tak vnitrni implementace by mely byt v harmonii.

[mj41]

Při návrhu syntaxe Perlu 6 se např. myslí na rychlost parsování. Jinak mi ale nepřipadá, že by se nějak hledělo na složitost implementace na úkor elegance samotného jazyka.

[frEon]

Pro ruby, mimo specifikace, je sada testu, podle ktery se da zjistit, jak moc se kompilator blizi specifikaci. Jinak ruby kompilatoru je nekolik, jeden oficialni od Matze, JRuby ktery bezi jvmku a neco bastli microsoft. Pak jeste Enterprise Ruby (coz je vlastne fork Matzova ruby 1.8).

[Ivan]

Psaní kompilátoru je to poslední, co by mělo trápit návrháře jazyka, ne? Primární je uživatelnost jazyka, ne složitost kompilátoru...

Treba u C++ nemame poradne ani po 15ti letech kompilator ktery by jej bezezbytku implementoval. Zrovna nedavno jsem narazil ne nejakou nejednoznacnost vykladu specifikace mezi gcc a VC2008(i kdyz vic verim gcc). Co je tezke na implementaci pro kompilator musi by tezke na nauceni pro programatora. To mi nikdo nevymluvi.

[Marek Bernát]

Presne tak. C++ snáď nie je ani LALR, takže sa neni moc čo čudovať...

[Ladicek]

C++ je obecně GLR a pro jednoznačné parsování je potřeba spousta sémantické informace. Se sémantickými predikáty se dá dostat na LALR(1) a tuším že i LL(*), ale dělat bych to nechtěl

[Marek Bernát]

Aha, dík za upresnenie. Každopádne to musí byť humus

[Martin]

Poslyš, nechtělo by se ti konečně nastartovat blogový seriál o jazycích, gramatikách, překladačích a podobném voodoo po vzoru Marka a jeho seriálu o symetriích?

[Marek Bernát]

+1

Btw, keď už sa bavíme o tých jazykoch... netuší niekto či existuje prehľad, ktoré parsery (LL, LR, ...) sú najviac preferované pre kompilátory bežných jazykov? A súvisiaca otázka: ktoré sú najlepšie/najčastejšie používané generátory parserov (yacc, ANTLR, ...). Možno by o tom rovno Ladíček mohol napísať blog

[Martin]

To by teda určitě mohl.

A když už tady (zase) žebráme o seriály, kam vůbec zmizel Jakub Hegenbart (Kyosuke)?

[Marek Bernát]

Neviem, ale dúfam v najpozitívnejšiu možnosť: dosiahol nirvánu, odišiel z nášho sveta a stráži rovnováhu vesmíru, ktorá závisí na správnom spárovaní zátvoriek

[Martin]

ROFL napadlo mě něco podobnýho.

[Ondrej 'SanTiago' Zajicek]

kam vůbec zmizel Jakub Hegenbart (Kyosuke)?

Nejaky Kyosuke (a mozna z Ceska, podle textu komentare) se vyskytl nedavno na Slashdotu: http://slashdot.org/comments.pl?sid=1669586&cid=32398916

[Marek Bernát]

Škoda, že Kyosuke (správne s dlhým ó) je úplne bežné japonské meno. Tiež si mohol vybrať lepší nick

[Ladicek]

Před časem jsem Robertovi tak napůl slíbil seriál pro ábíčko o "oborových jazycích" (DSLkách) a pomalu na to začínám mít čas. Tak snad. Na gramatiky by taky došlo, ale ne moc hardcore. Ostatně generátory parserů jsou skvělým příkladem takového oborového jazyka, ne nadarmo se používá název "compiler compiler"

[Marek Bernát]

Juchú

[Martin]

Jo a člověče, neměl bys tip na nějakou rozumně stravitelnou knihu o jazycích, překladačích a tak? Na takové to "prázdninové čtení". Rok jsem se teď pohyboval úplně mimo informatiku a celkem rád bych do toho jedoucího vlaku naskočil zase zpátky, ještě než mi úplně ujede. Navíc mám v září státnice, a to už by vůbec nebylo od věci si něco málo dostudovat.

[mj41]

Jako doplněk k nějaké pořádné literatuře doporučuji Squaak tutorial (a tutorial on building a compiler with the Parrot Compiler Tools). Snad je to už zaktualizováno celé.

[Martin]

Díky za tip.

Ty bláho, Parrot, jakpak to s ním asi vypadá... Si připadám, jako kdybych přesně po roce vylezl z jeskyně.

[mj41]

Zrovna mi prislo emailem, ze spravny link na tutorial je na Parrot.org.

[Marek Bernát]

Mne sa na disku povaľujú Red a Purple Dragon Book. Už je to dávno, čo som ich čítal (a aj to nie celé), ale mám pocit, že boli dosť dobré.

[Ladicek]

No, to je těžký Normálnímu člověku, který se chce v implementaci programovacích jazyků trochu zorientovat a možná i něco málo použít, bych okamžitě doporučil Language Implementation Patterns, ale obávám se, že to by tě asi neuspokojilo.

Jako intro do návrhu programovacích jazyků můžu doporučit Programming Language Pragmatics, a pokud jde přímo o překladače, tak asi odkazovaná Dragon Book (i když jsem ji nikdy nečetl; docela se mi ale zamlouvala výrazně kratší Modern Compiler Implementation in Java).

[Jirka P]

Treba u C++ nemame poradne ani po 15ti letech kompilator ktery by jej bezezbytku implementoval

To není tak úplně pravda; poslední verze standardu C++ je 7 let stará a kompilátor, který ji implementuje, pokud vím, existuje.

Zrovna nedavno jsem narazil ne nejakou nejednoznacnost vykladu specifikace mezi gcc a VC2008(i kdyz vic verim gcc)

To je dost nesmyslné tvrzení: Buďto je ta specifikace nejednoznačná (klidně může být), a pak je každý konformní výklad stejně dobrý (můžeme se bavit o tom, jestli je vhodnější/použitelnější, ale těžko můžeme jednomu "víc věřit"). Nebo je některá z těch implementací v rozporu se standardem, a pak se dá těžko hovořit o nejednoznačnosti výkladu.

Co je tezke na implementaci pro kompilator musi by tezke na nauceni pro programatora

Pokud by toto byla pravda, je pro programátora nejjednodušší (na naučení) stroják nebo assembler.

[Marek Bernát]

A ktorý to je?

Čo je na tom nezmyselné? Podstata je, že špecifikácia je nejednoznačná. To je celkom veľký problém. Lebo ak pripustíme nejednoznačnosť, tak už nám môže byť jedno, akého jazyka to vôbec špecifikácia je

Že sa 500 stránkový štandard bude učiť ťažšie než 50 stránkový Vám pripadá nezrejmé? Nič viac tá jeho veta nehovorila. A rozhodne nehovorila nič o assemblere (btw, ktorom konkrétne? A ste si istý, že každý assemble má triviálnu gramatiku?)

[stativ]

A ktorý to je?

Dost kompletní jsou Comeau C++ a kompilátor v Sun Studiu.

Mimochodem standard C++ ISO/IEC 14882:2003 má skoro 800 stran.

[alkoholik]

"Dost kompletni" zni skoro jako "trochu tehotna".
;^)