Na co všechno je dobrý LISP?

[JS]

No tohle už je úplná zoufalost... Takže vlastně ostatní jazyky jsou špatné proto, že mají něco, co Lisp nemá, takže v Lispu si to člověk musí sám napsat, čímžpádem pak nenadává na to, že to někdo jinej napsal blbě.

Vy jste ta makra stale nepochopil. Treba moje oblibena jsou anaforicka makra, viz http://www.bookshelf.jp/texi/onlisp/onlisp_15.html (vubec ta knizka je uzitecna, ta prave ukazuje silu tech maker). Pointa skutecne je, ze muzete jazyk prizpusobit problemu, ktery resite - a tim odpadnou problemy, jestli uz autori jazyka pridali nejakou vami zadanou vlastnost do specifikace. Makra jsou ten duvod, proc Lispari snaseji tu syntaxi - a protoze jsou obvykle docela chytri, mel byste pochopit, ze jim to zrejme za to stoji.

(Kdyz jsme u toho, Viky zminil Forth - to je take jazyk, na ktery byste se mel podivat, ma k Lispu velmi blizko tim, jak je programovatelny.)

Tri dalsi pekne nedocenene vlastnosti CL jsou podle me:

Vraceni vice navratovych hodnot (coz z ostatnich jazyku pokud vim hezky umi jen Python), i kdyz zapis je ponekud pres ruku. Opravdu nevim (podobne jako u tech restartu) proc tak jednoduchou vec jeste nezavedly i ostatni jazyky.

Reader makra (a vubec cely koncept reader-printer) - v podstate vam umoznuje predelat si syntaxi totalne. Takze pokud chcete nejaky syntakticky cukr, neni problem si ho dovyrobit.

Zobecnene promenne - v podstate jde o neco podobneho jako lvalue v C, akorat si muzete definovat vlastni.

[Reklama]

[Inkvizitor]

Vraceni vice navratovych hodnot (coz z ostatnich jazyku pokud vim hezky umi jen Python), i kdyz zapis je ponekud pres ruku. Opravdu nevim (podobne jako u tech restartu) proc tak jednoduchou vec jeste nezavedly i ostatni jazyky.

Ve Scale to je s Pythonem prakticky srovnatelné: http://hestia.typepad.com/flatlander/2009/02/scala-for-c-programmers-part-4-multiple-return-values.html.

[Mirek Prýmek]

Bral bych raději tykání, jestli vám to neva...

Vy jste ta makra stale nepochopil.

Z čeho tak usuzujete? Napsal jsem, že nevidím žádnou výhodu v tom, když jazyk nějakou vlastnost nemá, přestože je dostatečně flexibilní na to, aby si uživatel mohl (musel) tuto vlastnost psát sám. Daleko lepší mi přijde klasický koncept, kdy jazyk má přímo zabudováno 99.99% vlastností, které uspokojí 99.99% jeho uživatelů. A ti ostatní použijí nějaký jazyk vhodnější pro daný účel. No problem - nikdo netvrdí, že třeba CLI je vhodné na vše.

(Kdyz jsme u toho, Viky zminil Forth - to je take jazyk, na ktery byste se mel podivat, ma k Lispu velmi blizko tim, jak je programovatelny.)

Forth jsem v tom výčtu jazyků, se kterými jsem se setkal, zapomněl uvést. Ne, že bych v něm něco psal, ale trochu jsem si ho prošel. Ano, je rozhodně zajímavý - a k seznámení s ním mě vedly JASNĚ UVEDENÉ výhody oproti jiným jazykům: brutální minimalismus, jednoduchý koncept, dostatečná vyjadřovací schopnost. Mimo to znám forthovský bootloader z FreeBSD a musím říct, že to je moc hezká věc. Jinými slovy, milovníci Forthu mi jasně předvedli, k čemu se ten jazyk hodí víc než jiné a  neotravovali mě kecy o tom, že jedině oni jsou ti správní real men, protože si pomocí nářadí vyrábí nářadí...

Vraceni vice navratovych hodnot (coz z ostatnich jazyku pokud vim hezky umi jen Python), i kdyz zapis je ponekud pres ruku. Opravdu nevim (podobne jako u tech restartu) proc tak jednoduchou vec jeste nezavedly i ostatni jazyky.

Jaktože nezavedly? V CLI se dá vracet pole objektů a v Boo se s tím dá pracovat úplně stejně jako v Pythonu:

def f() as (string):
   return "a","b"
a,b = f()

Takže bez problému. Není to moc používané - asi to nikdo moc nepotřebuje...
Má to taky nevýhodu, že tím člověk může ztrácet část typové kontroly - ale tu lisp tak jako tak (afaik) nemá vůbec, takže to není argument.

Reader makra (a vubec cely koncept reader-printer) - v podstate vam umoznuje predelat si syntaxi totalne. Takze pokud chcete nejaky syntakticky cukr, neni problem si ho dovyrobit.

To je pořád dokola. Ano, tohle je zajímavé. A dá se to využít k něčemu *praktickému*, co by se bez toho (v jiném jazyce) nedalo napsat? Pořád dokola tady slyším, jak jsou lispaři geniální, tak by snad mohli pochopit i tuto jednoduchou otázku. Ale možná jsem málo real man, abych pochopil že lapidární odpověď "makra" vyjadřuje vše...

...tak mě napadá, že odpovídat takhle blbě je asi trochu deformace z lispu - zřejmě odpovídající předpokládá, že si odpověď na svoji otázku doplním sám, protože přirozený jazyk je na to dostatečně flexibilní

Zobecnene promenne - v podstate jde o neco podobneho jako lvalue v C, akorat si muzete definovat vlastni.

Tomu nerozumím. Můžete mi ukázat příklad?

[Mirek Prýmek]

Bedno, přijde ti normální propagovat jazyk tím, že těm, kdo ho neznají, ukážu nekomentovaný zdroják?

Japonština je geniální jazyk! Koukej: 器質性構音障害 - 音声器官における形態上の異状により引き起こされる発音上の障害。No není to paráda?! Kdo nevidí tu krásu, není real man, ale cvičená opice!

Vůbec to není hardcore lisp, normální 2 makra a jedna funkce.

Ok, tak co to teda dělá tak báječného? Vezme to zdroják a udělá to z něho spustitelnou funkci. A co se týče ***praktického použití***, tak se to od běžné evalu liší jak? Přijde mi, že leda tím, že to, co mi z běžného evalu vypadne, už nemůžu dál modifikovat. Tak fajn, no, to je pěkný - akorát jsem to zatím nikdy nepotřeboval. A to je teda všechno?

[Ondřej]

No tak tohle konečně zní opravdu dobře a zajímavě! A to makro to umělo OBECNĚ? (jde to vůbec? Teď nějak nemám buňky nad tím přemýšlet…)

Jo, obecně. Ale jde to jen u určitého typu rekurze, to jsem myslel tím "pokud to jde". Konkrétně to jde u koncové rekurze (http://en.wikipedia.org/wiki/Tail_call). Scheme to umí automaticky, Lisp pokud vím ne. Ale asi jsem dal špatný příklad, ten jednodušší zápis faktoriálu v koncové rekurzi není.

Obecně si ale můžete vytvořit jakýkoliv modifikovaný defun, který nějak přežvýká vámi definovanou funkci. Třeba jsme ještě psali makro defun-counter, který udělal jen to, že na začátek definice funkce vložil příkaz na inkrementaci nějakého globálního čítače. Mohl jste tak mít přehled, kolikrát byla která funkce za celou dobu zavolána. Nebo si můžu vytvořit makro, které mi vytvoří definici celé třídy :-). Pecinovský tomu myslím říkal přepravka, něco jako

(create-crate 'point '(x y))

a ono to vytvoří třídu point s atributy x a y a přístupovými metodami pro tyto atributy.

 

No až na ten převod na iterativní algoritmus tam všechno (nějak) dělat jde.

No to zas taková bomba není - když už by to teda člověk tak strašlivě chtěl, stačí mu napsat něco podobného ICallable, co bude zároveň zapouzdřovat zdroják... Jasně, není to tak elegantní - no a? Copak je to něco, co používáme denně pětkrát?

Ono jde právě o tu eleganci, myslím si, že syntaktický cukr je hodně důležitý a Lisp umožňuje definovat prakticky jakýkoliv syntaktický cukr, jaký vás napadne, což je výhoda. I když asi i zároveň nevýhoda, když si každý Lispový programátor definuje vlastní syntaktické cukry, tak prase aby se v tom pak vyznalo :-).

Co se týče toho ICallable — pokud to chápu správně, tak to mi jen pomůže v tom, že místo toho abych předal přímou hodnotu, tak ji musím předat buď jako objekt nebo jako funkci, což může být dost nepohodlné a makro je v tomto případě daleko jednodušší a elegantnější.

Podle mě převod rekurzivní funkce na iterativní je to samé co optimalizace "tail rekurze" (což Lisp snad dělá automaticky, ne?). A C# má (podobně jako jiné jazyky) podporu pro líné vyhodnocování. Ty příklady jsou ale na demonstraci docela fajn.

Jak jsem psal výše, myslím, že Lisp to nemá; Scheme ano. Co se týče podpory pro líné vyhodnocování — dá se v C# nějak napsat funkce(a+b) tak, aby se to a+b vyhodnotilo až uvnitř funkce? Nebo možná lepší příklad: mám funkci print(), která vypíše na obrazovku "ahoj". Můžu nějak napsat funkci fun tak, abych potom mohl napsat fun(print()) a na obrazovku se nevypsalo "ahoj"? Bez modifikace printu. V C# znám jen yield, ale to mi AFAIK nepomůže.

[Reklama]

[Ondřej]

Daleko lepší mi přijde klasický koncept, kdy jazyk má přímo zabudováno 99.99% vlastností, které uspokojí 99.99% jeho uživatelů. A ti ostatní použijí nějaký jazyk vhodnější pro daný účel. No problem - nikdo netvrdí, že třeba CLI je vhodné na vše.

Já bych s tímto v podstatě souhlasil, jen bych ubral procenta. On je problém, že většina programátorů se s makry nesetkala, nebo případně jen s Céčkovými makry. Těžko si řeknete, že kdybych programoval v Lispu, tak by to teď dalo krásně vyřešit makrem, když makra v Lispu vůbec neznáte. Takže jo, tenhle model mi taky přijde lepší, ale ubral bych tak na nějakých 90 %. Už jsem se i já sám přistihl, že jsem si v jiném jazyce řekl, že na tohle bych si v Lispu napsal krásné makro :-). Co to bylo už nevím.

Ok, tak co to teda dělá tak báječného? Vezme to zdroják a udělá to z něho spustitelnou funkci. A co se týče ***praktického použití***, tak se to od běžné evalu liší jak? Přijde mi, že leda tím, že to, co mi z běžného evalu vypadne, už nemůžu dál modifikovat. Tak fajn, no, to je pěkný - akorát jsem to zatím nikdy nepotřeboval. A to je teda všechno?

Do evalu obvykle strkáte string, kdežto makra v Lispu jsou na úrovni syntaxe jazyka. Navíc následné použití maker je řádově jednodušší než parsovat předaný string. A pak tam bývá problém s prostředím. Když to předám jako string do evalu, tak se v Lispu (nevím jak jinde) nemůžu odkazovat na lokální proměnné, protože eval si to vyhodnotí ve svém prostředí. Nemůže napsat něco takového:

(let ((a 10))
  (eval "(print a)"))

…protože a je definováno v let-prostředí a eval se vyhodnocuje ve vlastním a pokud nenajde vazbu na "a", tak pokračuje v globálním prostředí, kde ten symbol nenajde. Ale myslím, že tam šlo předat v argumentu odkaz na aktuální prostředí, ale ruku do ohně za to nedám. Pokud tomu kódu nerozumíte, tak bych to mohl přepsat takto:

a = 20;
function fun() {
  a = 10;
  eval("print a");
}

V tom evalu by se mělo vytisknout 20, protože eval nevidí zpět do prostředí té funkce a hledá "a" v globálním prostředí. Nezkoušel jsem to, tak snad to mám správně, ještě by mi zpětně zhoršili známku z paradigmat programování :-)).

[Mirek Prýmek]

Jo, obecně. Ale jde to jen u určitého typu rekurze, to jsem myslel tím "pokud to jde". Konkrétně to jde u koncové rekurze (http://en.wikipedia.org/wiki/Tail_call). Scheme to umí automaticky, Lisp pokud vím ne. Ale asi jsem dal špatný příklad, ten jednodušší zápis faktoriálu v koncové rekurzi není.

Hm, tak to už zas taková bomba není.

Abysme si rozuměli, já ten základní princip chápu: kód jsou data. Proto můžu kód měnit za běhu stejnými prostředky, jako měním data - a poté ho úplně normálně spustit. Už jsem tady uváděl, že si umím představit, že si např. můžu za běhu programu u nějaké funkce vymazat každý druhý příkaz a poté ji spustit. No dobrá, ale opravdu mě napadá jenom velmi málo skutečně dobrých *praktických* využití téhle vlastnosti takových, aby v "normálním" jazyce nešly NĚJAK napsat taky (znovu opakuju: jistě, bude to krkolomnější - ale to mi žíly netrhá u věci, která je takhle strašně úzkoprofilová...).

Jediná oblast, kde si využití dovedu představit hodně dobře, je automatická verifikace kódu, ale s tím tady kupodivu žádný obhájce lispu neoperuje...

Nebo si můžu vytvořit makro, které mi vytvoří definici celé třídy :-).

To zní sice strašně hóch, ale v Pythonu to jde taky. Akorát běžný pythonista za celý život nepocítí potřebu to dělat... Čili asi ani nepocítí potřebu zrovna kvůli tomuhle zahodit python a jít do lispu...

Ono jde právě o tu eleganci, myslím si, že syntaktický cukr je hodně důležitý a Lisp umožňuje definovat prakticky jakýkoliv syntaktický cukr, jaký vás napadne, což je výhoda. I když asi i zároveň nevýhoda, když si každý Lispový programátor definuje vlastní syntaktické cukry, tak prase aby se v tom pak vyznalo :-).

No a to jsme právě u toho, co jsem psal výš: jestliže "normální" jazyk má svoje prvky napevno, tak to není nevýhoda, ale výhoda - protože všichni jeho uživatelé tuhle vlastnost používají stejně, což vede ke snadné znovupoužitelnosti, což je přesně to, co mě zajímá (efektivita práce). Plácnu to takhle: Nechtěl bych dávat dohromady kód pěti lispařů, kde každý z nich psal objektově, ale každý si ten objektový systém napsal jinak, "protože to lisp umožňuje".

Co se týče toho ICallable — pokud to chápu správně, tak to mi jen pomůže v tom, že místo toho abych předal přímou hodnotu, tak ji musím předat buď jako objekt nebo jako funkci, což může být dost nepohodlné a makro je v tomto případě daleko jednodušší a elegantnější.

Já jsem to myslel takhle: vezmu string obsahující kód a předám ho nějaké factory, která mi vytvoří objekt, který zároveň obsahuje ten zdrojový string (abych ho kdyžtak mohl upravit, kdybych to nakrásně chtěl)  a zároveň přeloženou verzi - takže ho můžu zavolat jako funkci.

Jasně, mám tam ty dvě věci (zdroják a přeložený kód) odděleně, takže to není tak elegantní, jako kdyby oboje bylo totéž, ale co se týče praktického využití, přijde mi, že to vyjde nastejno.

REJP:
A bez haldy závorek!
/REJP

[Mirek Prýmek]

Těžko si řeknete, že kdybych programoval v Lispu, tak by to teď dalo krásně vyřešit makrem, když makra v Lispu vůbec neznáte.

To je pravda a tenhle argument chápu. Jenom se nějak pořád nemůžeme dobrat těch *praktických* věcí, u kterých by si to pythonista mohl říct

Do evalu obvykle strkáte string, kdežto makra v Lispu jsou na úrovni syntaxe jazyka.

Tomu taky rozumím a taky se mi to líbí. Ale opět tam nevidím žádnou tak zásadní přidanou hodnotu. A v tom je ten problém.

Navíc následné použití maker je řádově jednodušší než parsovat předaný string.

V jakém smyslu "jednodušší"? Pro programátora nebo pro stroj? Jestli pro stroj, tak to je jasné, protože proto to bylo tak vymyšlený, že tomu stroj rozumí líp než člověk.

No a jestli programátor, tak o tom bych s úspěchem pochyboval:

Kód: [Vybrat]

# kod ve stringu
code = """
def f(a):
   print "Ahoj "+a
"""
# sem si ulozim vysledny objekt
globals={}
# prevod string -> funkce
exec code in globals
# ziskanou funkci si ulozim do lokalni promenne
f = globals['f']
# a spustim ji
f("Mirek")
# vysledek: Ahoj Mirek


A pak tam bývá problém s prostředím. Když to předám jako string do evalu, tak se v Lispu (nevím jak jinde) nemůžu odkazovat na lokální proměnné, protože eval si to vyhodnotí ve svém prostředí.

Teď tomu asi přesně nerozumím, ale v pythonu je prostředí tvořeno slovníkem, do kterého si můžu uložit co chci ("globals" v prikladu vyse).

[JS]

Vy jste ta makra stale nepochopil.

Z čeho tak usuzujete? Napsal jsem, že nevidím žádnou výhodu v tom, když jazyk nějakou vlastnost nemá, přestože je dostatečně flexibilní na to, aby si uživatel mohl (musel) tuto vlastnost psát sám.

Usuzuji z toho, jak odpovidate, ze nevite, o cem je rec, kdyz se rekne makra v Lispu. To je cele. Samo o sobe to neni problem - ja jsem to take nevedel, a take jsem se tomu konceptu branil, nez jsem to prekonal a neco si o tom precetl. Vy byste mel take, protoze se proste pletete, kdyz mi tvrdite, ze tomu rozumite.

Makra jsou v zasade jen dalsi moznost abstrakce, podobne jako funkce. Asi byste jen tezko tvrdil, ze "nevidím žádnou výhodu v tom, když knihovna jazyka nějakou funkci nemá, přestože je dostatečně flexibilní na to, aby si uživatel mohl (musel) tuto funkci psát sám" a obhajoval tim jazyk, ktery neumoznuje uzivateli definovat vlastni funkce.

Forth jsem v tom výčtu jazyků, se kterými jsem se setkal, zapomněl uvést. Ne, že bych v něm něco psal, ale trochu jsem si ho prošel. Ano, je rozhodně zajímavý - a k seznámení s ním mě vedly JASNĚ UVEDENÉ výhody oproti jiným jazykům: brutální minimalismus, jednoduchý koncept, dostatečná vyjadřovací schopnost.

Pak by vam melo byt jasne, ze Forth jistou formu maker ma (IMMEDIATE slova). A ze to je uzitecna vlastnost.

Jinými slovy, milovníci Forthu mi jasně předvedli, k čemu se ten jazyk hodí víc než jiné a  neotravovali mě kecy o tom, že jedině oni jsou ti správní real men, protože si pomocí nářadí vyrábí nářadí...

Nevim, co bych vam jeste mohl predvest. Cist odkazy se vam nechce. Tak co s vami?

Jaktože nezavedly? V CLI se dá vracet pole objektů a v Boo se s tím dá pracovat úplně stejně jako v Pythonu:

Jiste, muzete vratit pole. Ale vicenasobne hodnoty se v Lispu bezne vraci na zasobniku (driv to mohlo mit i vykonnostni dopady), navic vracet pole je nesikovne, pokud nemate tuple unpacking. Uznavam, ze v nekterych dynamickych jazycich to lze pomerne snadno obejit, ale takova Java nebo C++, tam to fakt chybi.

To je pořád dokola. Ano, tohle je zajímavé. A dá se to využít k něčemu *praktickému*, co by se bez toho (v jiném jazyce) nedalo napsat? Pořád dokola tady slyším, jak jsou lispaři geniální, tak by snad mohli pochopit i tuto jednoduchou otázku. Ale možná jsem málo real man, abych pochopil že lapidární odpověď "makra" vyjadřuje vše...

Je mi lito, ja za vas nemuzu delat domaci ukol a vsechno vam dopodrobna popisovat, abyste pak rekl - ale me se to stejne nelibi. Proste, musite se podivat na ty veci sam. Ja vam k tomu dal dost informaci.

[Ondřej]

To je pravda a tenhle argument chápu. Jenom se nějak pořád nemůžeme dobrat těch *praktických* věcí, u kterých by si to pythonista mohl říct

To taky nevím, protože v Pythonu jsem nenapsal ani řádku, takže nevím, co tam lze a co ne. Z těch příkladů, které jsem tady napsal, bych tipl, že nejdou napsat ty vlastní ify nebo ta logická spojka at-least-two. Ale nevím, jak moc ti to přijde praktické :-). Tady jsme asi u konce, pokud máš v Pythonu k dispozici eval, tak tím asi nějak uděláš všechno, co lze udělat makrem, akorát to bude hnusnější (viz dále) a to je možná ten důvod, proč to, narozdíl od maker v Lispu, nikdo nepoužívá.

Tomu taky rozumím a taky se mi to líbí. Ale opět tam nevidím žádnou tak zásadní přidanou hodnotu. A v tom je ten problém.

Já myslím, že právě ta přidaná hodnota je obrovská. Ve chvíli, kdy člověk "programuje ve stringu", tak přichází o velkou část podpory IDE (zvýrazňování, refactoring, asi i debug…) a zároveň o třeba o syntaktickou (a případně ještě další) kontrolu kompilátorem. Navíc to vypadá hnusně.

ad to parsování: Jo, takhle je to asi stejné, já měl na mysli přímo ruční parsování toho stringu.

[Mirek Prýmek]

Usuzuji z toho, jak odpovidate, ze nevite, o cem je rec, kdyz se rekne makra v Lispu. To je cele.

No tak to jste četl špatně. Nebo jsem já špatně psal. Chtěl jsem říct, že nevím, čím tak zásadním odlišují makra lisp od jiných jazyků ***z hlediska jeho praktického nasazení***.

Samo o sobe to neni problem - ja jsem to take nevedel, a take jsem se tomu konceptu branil, nez jsem to prekonal a neco si o tom precetl. Vy byste mel take, protoze se proste pletete, kdyz mi tvrdite, ze tomu rozumite.

No zatím se mi zdá, že se to principielně nijak diametrálně nelíší od evalu (resp. exec v Pythonu) - prostě se za běhu dá generovat struktura, která se dá spustit. Na tom není čemu rozumět.

Makra jsou v zasade jen dalsi moznost abstrakce, podobne jako funkce. Asi byste jen tezko tvrdil, ze "nevidím žádnou výhodu v tom, když knihovna jazyka nějakou funkci nemá, přestože je dostatečně flexibilní na to, aby si uživatel mohl (musel) tuto funkci psát sám" a obhajoval tim jazyk, ktery neumoznuje uzivateli definovat vlastni funkce.

Top je dost silně přitažené za vlasy

Nevim, co bych vam jeste mohl predvest. Cist odkazy se vam nechce. Tak co s vami?

Třeba vám dá inspiraci to, co mě zaujalo o Forthu: prý se jednou za čas někdo pokusí FreeBSĎácký forthovský bootloader přepsat v jiném jazyce, ale nikdy nedosáhne lepšího výsledku.

Stačilo by uvést tři takové příklady pro lisp a už se na nic dalšího nebudu ptát.

Jiste, muzete vratit pole. Ale vicenasobne hodnoty se v Lispu bezne vraci na zasobniku (driv to mohlo mit i vykonnostni dopady), navic vracet pole je nesikovne, pokud nemate tuple unpacking. Uznavam, ze v nekterych dynamickych jazycich to lze pomerne snadno obejit, ale takova Java nebo C++, tam to fakt chybi.

No tak je úspěch, že jsme se posunuli od "proč to ještě NIKDO nezavedl" k "v C++ a javě to chybí"

Navíc nechápu, o jakém "obcházení" je řeč - spousta jazyků prostě víc hodnot vracet UMÍ. Tečka.

Je mi lito, ja za vas nemuzu delat domaci ukol a vsechno vam dopodrobna popisovat, abyste pak rekl - ale me se to stejne nelibi. Proste, musite se podivat na ty veci sam. Ja vam k tomu dal dost informaci.

Není potřeba nic dopodrobna popisovat. Stačí deseti větami ukázat příklad něčeho *praktického*, co v Lispu dá napsat, a v běžnějším jazyce by to nešlo, nebo by byl zjevný propastný rozdíl v těch dvou implementacích.

[Mirek Prýmek]

Z těch příkladů, které jsem tady napsal, bych tipl, že nejdou napsat ty vlastní ify nebo ta logická spojka at-least-two. Ale nevím, jak moc ti to přijde praktické :-)

Tím slovem "praktický" myslím něco, co má nějaký jasný výstup MIMO ten samotný programovací jazyk - tj. např. vyřeší to nějaký problém, který by jinak řešit nešel (nový produkt), prokazatelně to urychlí vývoj (produkt rychleji na trhu), zvýší to stabilitu (snížené náklady na podporu) apod.

Věci, které nevidí nikdo jiný než programátor, za praktické nepovažuju.

Tady jsme asi u konce, pokud máš v Pythonu k dispozici eval, tak tím asi nějak uděláš všechno, co lze udělat makrem, akorát to bude hnusnější (viz dále) a to je možná ten důvod, proč to, narozdíl od maker v Lispu, nikdo nepoužívá.

On to spíš imho nikdo nepoužívá spíš proto, že to za běžných okolností prostě nikdo nepotřebuje.
Ale jinak jsem rád, že jsme se konečně aspoň s někým shodli, že makra nedávají lispu žádnou magickou sílu (!), která by ho nějak zásadně odlišovala od ostatních běžných jazyků. O to mi celou dobu šlo.

Já myslím, že právě ta přidaná hodnota je obrovská. Ve chvíli, kdy člověk "programuje ve stringu", tak přichází o velkou část podpory IDE (zvýrazňování, refactoring, asi i debug…) a zároveň o třeba o syntaktickou (a případně ještě další) kontrolu kompilátorem. Navíc to vypadá hnusně.

To je pravda. Jenže je potřeba si uvědomit, jakou část programu budu chtít takhle krkolomně za běhu měnit. V 99.99procentu programů žádnou. V polovině ze zbytku zanedbatelnou (u ní stringy budu muset přežít). A zbytek problémů by bylo určitě dobré řešit pomocí lispu, proti tomu nic nemám. Jen neustále zdůrazňuju, že nevím, co ten zbytek vlastně tvoří. Žádný takový problém jsem zatím nepotkal...

ad to parsování: Jo, takhle je to asi stejné, já měl na mysli přímo ruční parsování toho stringu.
[/quote]

[Mirek Prýmek]

Ještě Ondrovi:

ještě bych asi dodal, že to řešení čistě se stringem je samozřejmě těžkopádné co se týče možných úprav toho kódu. Mohl bych to udělat i tak, že bych si vytvoříl nějaký strom objektů a kořen by měl metodu __call__(), která by celý strom převedla na string, ten přeložila a spustila. Tím bych (jak se to mně - cvičené opici - zatím jeví) získal úplně stejnou sílu, jakou má Lisp. A proč? No protože bych si takhle de facto napsal interpret lispu v pythonu. Akorát bych tomu tak neříkal...

...no a tím jsme se dostali k tomu, co jsem tady psal hned na začátku: pokud mám eval nad turingovsky úplným jazykem, mám stejnou sílu jako lisp, ať si kdo chce co chce říká...

[JS]

No zatím se mi zdá, že se to principielně nijak diametrálně nelíší od evalu (resp. exec v Pythonu) - prostě se za běhu dá generovat struktura, která se dá spustit. Na tom není čemu rozumět.

To prave dokazuje, ze to nechapete. Protoze makra nejsou eval. Makra jsou elegantni zpusob, jak generovat "boilerplate" kod (a jak treba schovat technicke detaily implementace). A proto je to neco diametralne odlisneho, nez maji bezne jazyky.

Není potřeba nic dopodrobna popisovat. Stačí deseti větami ukázat příklad něčeho *praktického*, co v Lispu dá napsat, a v běžnějším jazyce by to nešlo, nebo by byl zjevný propastný rozdíl v těch dvou implementacích.

Knizka On Lisp, z ktere jsem odkazoval jednu kapitolu, je takovych prikladu plna (v kazde kapitole je takovy priklad). Stejna tak knizka Practical Common Lisp, z ktere jsem take odkazoval jednu kapitolu, dejme tomu http://www.gigamonkeys.com/book/practical-building-a-unit-test-framework.html. Problem je, ze vy na vsechno, co vam kdo predhodi, reknete, ze je to neprakticky priklad, a ze to svedete take. Coz je samozrejme v Turingovsky uplnych jazycich pravda. Otazka je, jak bude vypadat ten zapis.

[Mirek Prýmek]

To prave dokazuje, ze to nechapete. Protoze makra nejsou eval. Makra jsou elegantni zpusob, jak generovat "boilerplate" kod (a jak treba schovat technicke detaily implementace). A proto je to neco diametralne odlisneho, nez maji bezne jazyky.

Aha. A pomocí evalu se nedá boilerplate kód generovat. Proto eval není makro. Hm. Tak jo.

Problem je, ze vy na vsechno, co vam kdo predhodi, reknete, ze je to neprakticky priklad, a ze to svedete take. Coz je samozrejme v Turingovsky uplnych jazycich pravda. Otazka je, jak bude vypadat ten zapis.

No tak když tady někdo machruje s tím, že něco v lispu napíše na pět řádků a já mu ukážu, že v pythonu je to taky na pět řádků, tak to potom zjevně není otázka toho, jak bude vypadat kód, ale otázka toho, že někdo má prostě neutuchající potřebu machrovat...