Názory k článku
'(Programovací (cons 'jazyk 'Scheme))

Tak jsem se dočkal, díky…

Chtěl jsem se učit scheme, ale jsem na pochybách, zda bych se neměl rovnou začít učit lisp. Přeci jenom, lisp je rozšířenější, existuje kvalitní kompilátor sbcl, je k dispozici více knihoven…

Lisp je o něco rozšířenější, nicméně v Scheme se IMHO programuje pohodlněji a vlastní i cizí kód se líp čte.
Scheme má taky špičkové kompilátory/in­terpretry jako Gambit, Chicken nebo Gauche. Např. z Gambit-C leze efektivnější kód než ze SBCL co do rychlosti běhu a paměťových nároků.

Problémem Scheme oproti Common Lispu a jiným „velkým“ jazykům jsou samozřejmě základní knihovny, resp. oblasti praktického programování kterou pokrývají.

Pořád nechápu jaký je rozdíl mezi scheme a lisp.

Pro scheme není ani pořádné gui, navíc většina scheme knihoven je vázána s konkrétní implementací scheme…

asi nejvetsi rozdil mezi nekterymi Lispy a Scheme je prave v dynamickem vs lexikalnim scopingu, par minoritnich rozdilu tam navic je taky, ale nejsou tak velke (dvoji vs jeden namespace, zminovany rozdil v chapani prazdnich seznamu). Pokud mate rad minimalisticky navrzene jazyky, je Scheme celkem jasna volba, pokud naopak hledate neco pro vyvoj vetsich aplikaci, mozna bych sel do CL.

Pro Scheme není pořádné GUI? A DrScheme (resp. PLT Scheme) je co? www.plt-scheme.org

jj ale je to pouze pro plt-scheme, a plt-scheme se nekompiluje do nativního kódu…

Ale na druhou stranu tu mám gtk-server… a zakomponovat tcl/tk – wish by také nemuselo být obtížné… to podporuje např chicken…

Ale stejně, lisp je na tom lépe.

Ps: Nevíte o knihovně umožnující v lispu prototype-based programování?

DrScheme podporuje asi 20 dialektů, mimo jiné i R5RS.

Ps: Nevíte o knihovně umožnující v lispu prototype-based programování?

http://redmine.sykosomatic.org/projects/show/sheeple

Asi plácnu blbost ale nešlo by pomocí maker udělat z lispu scheme?

Ide to. Na kontinuacie pouzijes kniznicu (napr. http://common-lisp.net/project/cl-cont/ ) a potom spravis code walker, ktory si uklada pri prechadzani kodu lexikalne bindingy. Pokial najdes takuto premennu v na zaciatku zoznamu (ked nie je quotovany) strcis tam ‚funcall‘ a mas scheme :)

No, jde to docela jednodušeji s využitím primitiv… To same zasobnikovy jazyk. Na UPOLu vas to čeká ve druháku. ;-)

Ten zasobnikovy jazyk by me zajimal. Jsou o tom nekde na netu informace?

nevim jestli to odpovida tomu, co se aktualne uci na UPOL. nicmene, upravenou variantu toho zasobnikoveho modelu pouzivame v schemiku (implicitne paralelnim dialektu schemu). pokud byste mel zajem o podrobnosti, napiste mi na email (je naspodku tech stranek)

Našel jsem nějaké poznámky a zdrojové kódy: http://krupka.inf.upol.cz/2009Z/PP3.html

Teorie: http://krupka.inf.upol.cz/2009Z/09.pdf
Zdroják: http://krupka.inf.upol.cz/2009Z/code/stack-scheme.lisp (+ nějaké pokračování http://krupka.inf.upol.cz/2009Z/code/continuations.lisp)

A případně ještě na http://phoenix.inf.upol.cz/esf/materialy.htm skripta Paradigmata programování 2, díl A/B od dua Vychodil/Konečný.

Ja jsem sel do Common Lispu, da se to celkem vydrzet, ale Scheme moc neznam. Z toho co pisi ostatni me prijde, ze Common Lisp ma pragmatictejsi pohled na svet nez Scheme, na ukor elegance (a to je vec, ktera mi velmi vyhovuje treba na Pythonu).

Kdyz ale srovnam Common Lisp s Pythonem, vadi mi na nem oproti Pythonu par veci:
- nedostatek standardnich knihoven (treba co mi dost chybi jsou i takove zakladni veci jako string.split a podobne), ale to muze byt moje neznalost (docela bych uvital stranku ekvivalentu CL a Pythonich knihoven); a tech par co jsem videl, mely dost horsi API oproti Pythonu (coz muze souviset s dalsimi body)
- neobjektovost, z cehoz vyplyva treba dichotomie mezi eql, equal, equalp, nebo spatna podpora hash tabulek a vlastnich struktur ve smyckach
- nema iteratory a generatory, vim ze na to existuji nejaka makra, ale zase, neni to tolik integralni soucast jazyka jako v Pythonu

Pokud vim, nic z toho Scheme moc neresi.

I kdyz s CL koketuji jiz pomerne dlouho, stale se mi prakticke veci lepe pisi v Pythonu.

string.split → http://www.cliki.net/SPLIT-SEQUENCE

– neobjektovost, z cehoz vyplyva treba dichotomie mezi eql, equal, equalp, nebo spatna podpora hash tabulek a vlastnich struktur ve smyckach

eq, eql, equal, equalp a pod nesuvisi s „objektovostou“ ale s identitou.
eq porovnava ci su 2 objekty jeden a ten isty – btw. v Lispe je VSETKO objekt, vcetne cisiel
eql porovnava cisla
equal porovnava zoznamy
equalp porovnava stromy (tzn – zoznamy/vektory, ale vnoruje sa rekurzivne dovnutra prvkov – je to strukturalna ekvivalencia)

spatna podpora hash tabulek – neviem kde je problem, mozno ti vadi ze Lisp nema „specialnu“ syntax ala table[key]?

Loop → doporucujem nahradit s http://common-lisp.net/project/iterate/

Tiez, http://common-lisp.net/project/alexandria/ by nemala chybat v kazdom Lisp projekte.

Dobra vec je aj http://github.com/ks/X.LET-STAR

Ha, diky. I kdyz stejne mi to pripada trochu rozstristene.

Co se tyce tech eql a tak, proste mi vadi, ze to nejsou genericke funkce. Totez plati i o rade dalsich veci, treba elt atd. Zkratka, ackoliv je v CL vsechno objekt, stale mi prijde, ze OO je tam jenom tam ex-post nasroubovane (narozdil od Pythonu, kde treba len() nebo == nebo + jsou genericke funkce). Ale mozna jsem jen neco nepochopil. A nebo je mozna nejaky snadny zpusob, jak ty funkce rozsirit.

Co se tyce hash tabulek, vadi mi prave tohle – ze na ne nefunguje vetsina funkci pracujicich s posloupnostmi. Ale to asi resi to ITERATE.

Kazdopadne, diky za odkazy, krome tech utilit jsem je neznal, a uzitecnost tech utilit jsem asi pri prvnim cteni podcenil.

K lispu jsem nedávno narazil na CLPython.

CLPython is an open-source implementation of Python written in Common Lisp. With CLPython you can run Python programs in a Lisp environment. Libraries written in Lisp are available to Python code, and Python libraries can be accessed by Lisp code.

Ked sa clovek zabeha v Common Lispe, a zorientuje v knizniciach, tak potreba pouzivat Pythonovske kniznice na prakticku pracu je nulova.

Konkrétně prosím…nemá smysl nadávat a přitom se nepokusit stav zlepšit.

Podstatnější (i když na první pohled možná méně viditelný) rozdíl než #f vs. nil mi přijde lisp 2 vs. lisp 1 (např. http://www.nhplace.com/kent/Papers/Technical-Issues.html)

Mas na mysli jeden vs dva jmenne prostory. Abych se priznal, tak jsem nikdy moc nechapal vyhodu dvou jmennych prostoru. Kdysi se to hodne resilo pri vyvoji LOGA (byly i nejake flamewars mezi vazenymi pany profesory :-), ale proc mit vlastne dva namespacy, jen to mate v pripade, ze prasici programator ma dva ruzne objekty pojmenovany stejne :-)

zatímco se v LISPu oblast platnosti proměnných stanovuje dynamicky v čase běhu programu, ve Scheme a v některých implementacích LISPu je oblast platnosti proměnné určena na základě toho, v jakém bloku se proměnná nachází (tato vlastnost jazyka se označuje lexical scope)

Zatiaľ čo toto môže byť pravda pre Elisp, tak Common Lisp používa dynamic scoping iba pre defvar/defparameter a podľa konvencie názov týchto premenných začína a končí hviezdičkou.

A pre tie s (declare (special *variable*))

Seznam literatury a odkazů je snad delší než článek, ale chybí v něm dvě kvalitní knížky dostupné v plném znění na webu (z jedné je přitom použit obrázek):

Structure and Interpretation of Computer Programs http://mitpress.mit.edu/sicp/full-text/book/book.html

a

How to Design Programs http://www.htdp.org/

Ja jsem zapomel na SICP? Jejda, tak to se omlouvam, ta knizka mela byt hned na prvnim miste v seznamu literatury kvuli jeji dulezitosti.