Na co všechno je dobrý LISP?

[Mirek Prýmek]

Já už jsem jeden docela drsný kdysi napsal:

Kód: [Vybrat]

http://www.root.cz/clanky/perlicky-uvod-do-referenci/nazory/187499/


Ten je moc hezkej. Hlavně na ilustraci, že v rámci nadšení z funkcionálního programování jde i do jinak hezkého pythonu zatáhnout dokonce i parenthesis hell*

Ten asi netrumfnu, vzdávám se

* http://esoteric.voxelperfect.net/wiki/Parenthesis_Hell

[Reklama]

[Inkvizitor]

No vida a zrovna na tohle je ideální funkcionální konstrukce

Kód: [Vybrat]

" ".join(["a", "b", "c", "d", "e"])

Tak teď teda už vůbec nechápu, co se slovem "funkcionální" míní, pokud volání metody objektu je "funkcionální konstrukce"

Napřed se omluvím, že jsem zas použil blbý tag v předchozím příspěvku.

Volání metody objektu je IMO funkcionální konstrukce právě v případě, že se chová, jakoby šlo o volání funkce s malinko jinou syntaxí. s.join(l) lze snadno převést na join(s, l) a funguje to úplně stejně dobře - to, že je ta implementace uvnitř třídy, v tomto případě nic moc nemění. K tomu bych chtěl poznamenat dvě věci. Vzhledem k tomu, že jsi poznal Haskell, asi víš, že v Haskellu se, až na dědičnost, celé OOP slušně nahrazuje typovými třídami (školní ukázka je funkce show). Takže kdybychom napsali

Kód: [Vybrat]

join :: String -> [String] -> String
join s [] = ""
join s [x] = x
join s (x:xs) = x ++ s ++ (join s xs)

main = print $ " " `join` ["a", "b", "c", "d", "e"]
dostali bychom se k podobné syntaxi a v zásadě i sémantice. A volání metody, která má jenom jeden parametr, lze ve Scale napsat ve stylu infixové funkce. Kdyby třída String měla metodu join(), bylo by možné psát normálně

Kód: [Vybrat]

" " join List("a", "b", "c", "d", "e")

[Mirek Prýmek]

Promiň, ale jestli budeme za "funkcionální obrat" považovat všechno, co nám *nějak* (v tomhle případě jenom pořadím "objektů") připomíná něco z nějakého funkcionálního jazyka, tak to už jsme ten pojem definitivně vyprázdnili a pro mě osobně ztrácí smysl ho vůbec používat...

(nic ve zlým, to není kritika, jenom takový povzdech)

[JS]

Mimochodem, to, ze se smycka da zapsat jako funkce nazyva Doug Hoyte v Let Over Lambda pripadem "syntakticke duality", a tvrdi, ze tyto duality jsou hlavni duvod, proc je Lisp tak dobry jazyk (a proc programatori snaseji ty zavorky).

Kde přesně to je?

Kvuli tomu tu knizku nema cenu cist.. V podstate tvrdi, ze cim vic ma jazyk regularnejsi syntaxi (napr. tedy pokud se specialni formy, makra i funkce zapisuji jako volani funkce, jako v Lispu, ale to neni jen tento pripad), tim je snazsi programy (zrejme mysli dobre napsane) v tom jazyce modifikovat. Nejsem si uplne jisty, ze s nim souhlasim, ale ta idea ma neco do sebe.

Priklady takovych syntaktickych dualit v Pythonu by byly napriklad moznost predefinovat si vlastni operatory v tridach (coz treba Java nema), nebo explicitni self v metodach.

[JS]

Promiň, ale jestli budeme za "funkcionální obrat" považovat všechno, co nám *nějak* (v tomhle případě jenom pořadím "objektů") připomíná něco z nějakého funkcionálního jazyka, tak to už jsme ten pojem definitivně vyprázdnili a pro mě osobně ztrácí smysl ho vůbec používat...

Musim rict, ze s Inkvizitorem v tomhle trochu nesouhlasim, a taky jsem ti dal lepsi definici, coz bylo pouzivaji se funkce vyssich radu (bere funkce jako argument a vraci zase funkci) nebo (coz je v podstate specialni pripad) provadi specializace argumentu (pro funkci a argument funkce 2 argumentu vraci funkci na 1 argumentu). Pricemz "funkcionalni" jazyk je takovy, ktery umoznuje takove funkce psat (a Python jim tedy je, protoze ten je, podobne jako Common Lisp, multiparadigmaticky).

[Reklama]

[Mirek Prýmek]

Kvuli tomu tu knizku nema cenu cist..

Já chci jenom vědět, kde to v té knížce je.

[JS]

Kvuli tomu tu knizku nema cenu cist..

Já chci jenom vědět, kde to v té knížce je.

http://letoverlambda.com/index.cl/guest/chap3.html#sec_7

[JS]

Oops, a jeste pak v kapitole 7, ktera neni na webu. Je to tam trochu roztahane, a jak rikam, kvuli tomu nema cenu to cist (i kdyz ta knizka je celkem pekna a originalni, ale nedoporucoval bych ji nekomu, kdo Lisp vubec nezna).

[Mirek Prýmek]

http://letoverlambda.com/index.cl/guest/chap3.html#sec_7

No tohle jsem právě četl a nikde tam nevidím "to, ze se smycka da zapsat jako funkce". Takže je to v té 7mé kapitole? Kde přesně?

[JS]

No tohle jsem právě četl a nikde tam nevidím "to, ze se smycka da zapsat jako funkce". Takže je to v té 7mé kapitole? Kde přesně?

Myslel jsem si, ze do toho budes takto stourat. V te 7. kapitole je to vysvetlene, a v podstate jsem ti to shrnul. Nemam tu knizku ted po ruce, mam ji doma. Ale ta hlavni myslenka je, ze regularni syntaxe je dobra vec. Konkretne, aplikovano na smycky (nebo jiny syntakticky konstrukt) to znamena, ze je snadne nahradit smycku necim jinym.

Treba kdybych v Lispu napsal:

Kód: [Vybrat]

(loop for i from 1 to 10 do (print i))
Tak protoze ta smycka je vlastne volani funkce (nebo spis makra), neni problem pozdeji tu smycku zmenit a napsat tam my-loop misto loop, kde to my-loop muze treba tu smycku paralelizovat. Zatimco v Pythonu (nebo jinem jazyce) by to problem byl, protoze bych musel misto zapisu smycky pouzit volani funkce, nebo co ja vim, proste predelat cely ten kod. Takze v tomhle je videt, jak ta syntakticka dualita umoznuje menit kod na mene zasahu.

[Nomen]

je to v té 7mé kapitole? Kde přesně?

Když už se tu řeší ty programovací jazyky, tak jen připomínám, že v tom lidském, českém, se řadové číslovky označují tečkou. Připsaná pádová koncovka se připouští jen v místech, kdy může hrozit nedorozumění (záměna s nějakým symbolem atp.).

[Mirek Prýmek]

Tak protoze ta smycka je vlastne volani funkce (nebo spis makra), neni problem pozdeji tu smycku zmenit a napsat tam my-loop misto loop, kde to my-loop muze treba tu smycku paralelizovat.

Tak to jo ) Tak kvůli tomu tu knížku opravdu není potřeba číst...

[Ed]

A tady je IMO jasná demonstrace, že Lisp (Scheme) se jako jazyk pro skriptování Gimpu moc neosvědčil a jeho volba byla dána pravděpodobně dobovým kontextem: http://forum.root.cz/index.php?topic=1884.0 Zlatý Python, zlatá Lua...

Ja myslim, ze Scheme bylo v GIMPu pouzite z toho duvodu, ze je velice snadne pro nej napsat embedded interpreter. Pokud se nechces (nemuzes) spolehat na interface do jineho jazyka, je to vyborn volba. Ja jsem si ho kdysi naprogramoval jako skriptovaci jazyk do jednoho projektu v Pythonu, protoze v Pythonu nejde/neslo zarucit, ze cizi skripty jsou bezpecne. A interface do Lua je v Pythonu porad nejak moc obskurni.

[Ed]

LISP a GIMP. V GIMPu je LISP pouzit ve script-fu pluginech. A me by zajimalo, jak to v tom GIMPu funguje, jakym zpusobem je LISP implementovany a jak spolupracuje s jazykem, ve kterem je GIMP napsany. Jestli to nekdo vi, nebo ma nekdo odkazy, kde se to lze dozvedet, tak je uvedte. A pripadne jestli nekdo pise script-fu pluginy, tak jak se pisou, a neco kolem nich (nejaky kratky povidani, nebo odkazy).

GIMP je napsany v C. V Script-fu skriptech pouzivas volani funkci ve stylu

Kód: [Vybrat]

(if (not (= shadow 0))
        (begin
          (gimp-image-add-layer img shadow-layer -1)
          (gimp-edit-clear shadow-layer)))

    (gimp-context-set-background '(0 0 0))

Na psani Script-fu skriptu se staci podivat na par skriptu (locate .scm|grep gimp) a potom pouzivat API browser, ktery je v GIMPu v menu Help. Teda aspon pokud pises skripty vicemene stejne, jako bys je psal treba v Perlu nebo Pythonu ;-).

Repozitory skriptu si najdi pres Google, pokud mas GIMP tak viz ten locate.

Jak je resene rozhrani do SF na strane GIMPu si uz nepamatuju, ale krome samotneho VM a definice typu uz staci vice mene napsat jenom funkci, ktera dostane jako parametr Lispovy list, podle car udela nejakou opraci a vrati list, nebo tak neco . A to "nejakou operaci" je treba volani ceckoveho gimp_image_add_layer(list[1], list[2], list[3])

[Inkvizitor]

Promiň, ale jestli budeme za "funkcionální obrat" považovat všechno, co nám *nějak* (v tomhle případě jenom pořadím "objektů") připomíná něco z nějakého funkcionálního jazyka, tak to už jsme ten pojem definitivně vyprázdnili a pro mě osobně ztrácí smysl ho vůbec používat...

(nic ve zlým, to není kritika, jenom takový povzdech)

Myslím, že si nerozumíme. Funkcionální řešení problému je u mě takové, které říká, co je třeba s daným vstupem udělat, aby na výstupu vyšla určitá hodnota závislá pouze na vstupních parametrech a na ničem jiném. Rovněž nemá funkcionální kód žádné vedlejší efekty, prostě jenom transformuje podle daného předpisu určitý vstup na nějaký výstup. Řečeno ještě jinak, definujeme matematicky určitou transformační funkci. Ta funkce je černá skříňka a naprosto nic neříká o reprezentaci mezivýsledků, o časové posloupnosti, o pořadí vyhodnocování operandů, protože na pořadí jejich vyhodnocení vzhledem k výsledku nezáleží. Proto tvrdím, že když zavolám s.join(l), jde o funkcionální zápis, zatímco pokud vytvořím cyklus, který postupně skládá podřetězec a na konci k němu připojí poslední prvek seznamu, nejde už o funkcionální zápis. Šlo by o něj pouze v případě, že bychom byli natolik tolerantní, že nám bude jedno, že nám Python kód zcela přeuspořádá a podle svého uvážení bude připojovat prvky seznamu odzadu dopředu. Nevěřím, že by existovalo mnoho imperativních programátorů, kteří by to přežili bez klení.

Z tohoto pohledu je mi jedno, jestli daný jazyk podporuje funkce vyšších řádů, zda dokáže skládat funkce tak, že vynechá mechanismus volání rutin a předávání parametrů přes zásobník atd. Jasně, že chci, aby program běžel co nejoptimálněji a neměl zbytečnou režii. Nicméně je pro mě důležité, abych mohl program psát (alespoň na nejvyšší úrovni) tak, že specifikuji co je třeba vypočítat a ne jak to má program/počítač udělat. Nakolik mi v tom daný jazyk/interpret/knihovny/virtuální stroj pomáhají, to je důležité, ale rozhodnutí, zda budu program záměrně strukturovat tak, abych se co nejvíce izoloval od fyzické implementace a reprezentace dat, je pouze na mně. Funkcionální přístup vychází z programátora a ne z jazyka. Doufám, že jsem svůj postoj dostatečně vysvětlil.