Názory k článku
LISPová makra aneb programovatelný programovací jazyk

Jen si dovolím upřesnit, že zmiňované makro with-gensyms pochází z vynikající knihy Petera Seibela Practical Common Lisp.

aj mne sa paci, nejaky cas ju uz mam rozcitanu :/

Skvělé, doufám, že další díl bude o syntax-rules a o syntax-case. :-)

len neviem preco tu saskujes s Prologom, navyse ti na konci chyba bodka.

Protože zdejší redakční systém to pro mě neprezentuje dost formálně. A žádná vodka mi tam nechybí, to je pomluva. A Rejpal jsem tady já, tak hezky do řady.

tecka ;-)

To neřeš, já mám jen v noci a po ránu divnou náladu. ;-)

Je nějaký způsob, jak "naučit" Lisp (Scheme) infixovou notaci - nějaké rozšíření, dialekt? Jeho použitelnost by tím (nejen) pro mě drasticky vzrostla.

http://www.google.com/search?hl=en&q=lisp+infix&btnG=Search

To je celkem beznej pozadavek lidi co zacinaj s lispem, nicmene to ze nic takovyho neni soucasti lispu je jenom dukaz toho ze "lispovsky" zpusob ma sve opodstatneni - tim ze zavedu do lispu infixovou notaci se zbavim vetsiny toho co dela lisp tak skvelym programovacim jazykem a co mu umoznuje to co zadny jiny jazyk neumi.

Je to jenom otazka zvyku.

Je to ještě lepší: Původně se infix (resp. M-expressions) plánoval a už už se ho chystali naimplementovat, ale uživatelé jazyka to nakonec sami odmítli. A to bylo, prosím pěkně, na začátku 60. let. Zjevně takovou berličku nepotřebovali.

Na to je už patnáct let hotové makro. ;-) Stačí hledat.

.. rekl bych ze o DOST dyl nez 15 let ;)

No já mluvím konkrétně o tom od Kantrowitze, které je pro Common Lisp. Na něm jako nejstarší letopočet vidím 1993. Předpokládám, že i na dřívějších makrosystémech si s tím někdo hrál. ;-)

Lisp je to, co by XML rádo chtělo být.

"Pokud v nějakém jiném jazyce chceme syntaxi, která tam není, musíme prosit tvůrce jazyka. Ne tak v LISPu: tam si můžeme takovou syntaxi nadefinovat sami."

To je trosku LISP-centricke :-) I jine jazyky nabizi podobnou rozsiritelnost, i kdyz je pravda, ze nejde zrovna o jazyky mainstreamove (mezi ty radim Javu, C, C++, C#, PHP atd.). Treba takovy FORTH a vlastne i Tcl jde podobnym zpusobem rozsirovat o dalsi syntakticke prvky.

Ale zamysleme se nad tim, proc to je vlastne mozne? Tyto jazyky (LISP, Scheme, FORTH, Tcl) maji velmi jednoduchou syntaxi, stary LISP dokonce nemel syntaxi zadnou, protoze se zapisoval primo derivacni strom, ktery si jinak prekladace a interpretery vytvari sami.

Pridani nove syntakticke kategorie je tedy velmi jednoduche, protoze vlastne samotna syntaxe zustava nezmenena (treba smycky v LISPu neni nic jineho nez specialni forma), ale v jinych jazycich se slozitejsi syntaxi (C, C++, Java, Python...) to uz mozne vetsinou neni. Maximalne se daji pretizit operatory, ale to je vrchol moznosti daneho jazyka, operatory uz nejdou pridat (+nastavit jejich asociativitu ci prioritu) a to vubec nemluvim napriklad o novych typech smycek ci opravdu slozitych makrech, kterym se predava cast kodu na "schroustani".

Ak je potreba optimalizovat kod (s pouzitim declare optimize speed a pod...), mozu prist tieto makra vhod - tlet a tlet*. Su to vlastne let a let*, ale namiesto dvojic akceptuju trojice, kde treti prvok je typ premennej. Priklad:

(tlet ((a 10 fixnum)
       (b 20 fixnum))
   (+ a b))

sa rozlozi na:

(LET ((A 10) (B 20))
  (DECLARE (TYPE FIXNUM B) (TYPE FIXNUM A))
  (+ A B))

Obdobne pre tlet*...

Kod makier:

(defun tletbody (typed-vars)
  (let (typedefs)
       `((,@(loop :for declaration
                  :in typed-vars
	          :collect (destructuring-bind (name expr typedef) declaration
						  (push (cons name typedef) typedefs)
						  `(,name ,expr))))
	 (declare ,@(loop :for type-declaration
		          :in typedefs
		          :collect `(type ,(cdr type-declaration) ,(car type-declaration)))))))
   
(defmacro tlet (typed-vars &body body)
  `(let ,@(tletbody typed-vars)
      ,@body))

(defmacro tlet* (typed-vars &body body)
  `(let* ,@(tletbody typed-vars)
      ,@body))

Mozno to niekomu niekedy pride vhod... :)

někteří používají LSD, někteří používají BSD...

Vždycky, když vidím kdekoliv kousek kódu v LISPu, utvrzuje mě to v přesvědčení, že používání LSD je základní podmínkou pro to, aby člověk s LISPem vůbec začal...

A protože používání tvrdých drog je nezákonné, zůstane LISP doménou několika málo extremistů, akademickým trápidlem a dobrým příkladem toho, jak se programovací jazyk opravdu navrhovat nemá...

Hezká ukázka úrovně našeho školství...že plodí takovouhle (^^^) duševní konfekci jako na běžícím páse. Oni na MIT vědí, proč na tom učí. A proto jsme my v prdeli a Amerika někde úplně jinde.

Ale samozřejmě, LISP se učí i na našich vysokých školách. Stejně jako spousta jiných věcí, které jsou zcela odtržené od reality...

Můžeme samozřejmě diskutovat o tom, kdo kde je (a rozhodně na to máme trošku jiný názor :-)), ale dobří programátoři jsou všude (rozhodně nejsou výsadou USA) a obávám se, že jejich výskyt statisticky opravdu nijak nesouvisí s výukou LISPu...

BTW, až tohle uděláš v tom svém oblíbeném Pascalu (Javě, C#, whatever...), tak, aby se to dalo dát studentům za domácí úkol a něčemu se přiučili (já si z prvního semestru na FELu odnesl jen velký kulový, asi tak půlku první kapitoly téhle knihy, což jsem měl za pár dní - ty další kapitoly by asi byly na další ročníky nebo co? :D), tak se můžeme začít bavit o návrhu jazyků (jo, i to se dá vměstnat do prváku, ale určitě ne s Pascalem, Javou a C#em).

Ano, určitě také dokážu vymyslet stovky velmi zajímavých příkladů, které se v LISPu dají řešit elegantně. Problém je, že se skutečným světem ty příklady mnoho společného mít nebudou...

Naopak, ty reálné problémy a úlohy, ačkoliv se v LISPU jistě řešit dají také, jsou mnohem efektivněji a přehledněji řešitelné v jiných programovacích jazycích. A to je právě důvod, proč reálných nasazení LISPu ubývá a ubývá.

"...efektivněji a přehledněji řešitelné v jiných programovacích jazycích."

Hezké. Jenže pointa Lispu je v tom, že to není programovací jazyk. Je to nástroj pro tvorbu progrmaovacích jazyků. ("Lisp isn't a language, it's a building material." - Alan Kay) Když jedna firma místo dvou milionů řádků C++ raději napsala dvě stě tisíc řádků v Lispu, asi k tomu měli důvod. (Třeba to, že se neupsali...)

No, myslím, že pokud taková firma skutečně existuje (možné to samozřejmě je, i když si nemyslím, že by to bylo příliš pravděpodobné), nevypovídá to nic o programovacím jazyku jako takovém, ale spíš o programátorech, který daný problém řešili...

Čím je problém komplikovanější a řešení rozsáhlejší, tím víc se stírají rozdíly (v kategorii množství kódu) mezi jednotlivými programovacími jazyky. Stejně jako cokoliv jiného, ani tohle tvrzení určitě neplatí pro zcela všechny programovací jazyky, ale pro většinu by myslím bylo možné je i exaktně dokázat. Stojí za ním totiž úvaha, že i když nějaký jazyk sám o sobě nabízí nějaké podstatné výhody, je většinou možné si vytvořit jejich kopii v jiném programovacím jazyku... Pro malá řešení bude taková kopie samozřejmě podstatnou částí řešení... ale čím je řešení rozsáhlejší, tím se ona kopie stává méně a méně podstatnou a zbylý kód je rozsahem velmi podobný...

Pokud je to možné, můžete prosím uvést konkrétní jméno firmy?

ITA Software. A vůbec to není nepravděpodobné, oni neprogramovali žádné účto.

"Čím je problém komplikovanější a řešení rozsáhlejší, tím víc se stírají rozdíly (v kategorii množství kódu) mezi jednotlivými programovacími jazyky."

Legrační. Copak by na to řekli jejich zaměstnanci?

Díky za odkaz. Máte s tou společností nějaké bližší kontakty nebo čerpáte čistě z jejich webu? Používají zajímavou kombinaci jazyků, ale protože vím, jak se vytvářejí podobné PR prohlášení či webové stránky, neviděl bych za tím snahu o efektivitu. Já vím, jsem pochybovač, ale asi to bude tím, že prostě mám dlouhodobější kontakt s realitou. Ovšem, je možné, že na společnost máte nějaký užší kontakt a oni na svých stránkach skutečně nemají běžné reklamní cancy, ale pravdu (je to tak řídký jev, že se blíží zázraku, ale nemožné to není).

Společnost, kde nyní pracuji by mohla mít podobné stránky (zkracuji):

používáme různé technologie:
RPG - protože nám dává maximální kontrolu nad systémem AS/400
Visual Basic - pro rychou tvorbu aplikací a maximální uživatelskou přívětivost
C++ - pro maximální výkon
Java - pro vysoký výkon a snadou přenositelnost serverových aplikací

Skutečnost je ovšem taková - používáme tyhle technologie z historických/pragmatických důvodů. RPG používáme, protože se historicky v ničem jiném pořádně na AS/400 pracovat nedalo. Visual Basic - prostě jsme potřebovali řešit problém a byl k dispozici programátor se znalostí dané domény, který pracoval v VB. Céčkové programátory má skoro každá společnost.
Téměř veškeré nové věci ovšem děláme v Javě (jedna věta ze stránek oné společnosti mě utvrzuje v tom, že oni na tom budou podobně: We began our project with a mix of Perl, Lisp and Java, but have since migrated to a pure Java codebase.)

Když máte velkou bázi kódu např. v RPG, nezačnete ho z ničeho nic přepisovat do Javy. Protože to nikdo nezaplatí... Zákazníky v podstatě nezajímá, v čem je daný produkt vytvořený (až na módu okolo J2EE v posledních letech), ale jak funguje, jak je spolehlivý, rychlý a jak je drahý...

Co se týče poslední věty... zkuste se skutečně zamyslet nad oním tvrzením... zkuste ho třeba rozporovat (může z toho být zajímavá debata :-) )... "Legrační" není přeci argument...

"Téměř veškeré nové věci ovšem děláme v Javě (jedna věta ze stránek oné společnosti mě utvrzuje v tom, že oni na tom budou podobně: We began our project with a mix of Perl, Lisp and Java, but have since migrated to a pure Java codebase.)"

Jistě jste si také všiml, že tahle věta se týká jakéhosi "Dataspace Browseru", což je jen jeden z mnoha jejich projektů, a že v Javě dělají web, protože na to jsou frameworky. Myslím, že přepisovat jádro search enginu by je v životě nenapadlo, protože na to žádné frameworky nejsou a nebudou, natožpak v Javě (se stále ještě nedostatečným JITem a s nepříliš pohodlným rozhraním k nativnímu kódu).

Jejich hlavní produkt ("IDOS pro celosvětové letecké spoje") začal vznikat jako nový (!) lispový projekt někdy kolem roku 2000 s cílem nahradit levnějším (Lintel clustery) a lepším (algoritmy) softwarem původní mainframové vyhledávače, které tyhle věci dělají někdy od sedmdesátých let.

Spousta zajímavých informací pochází z interního emailu a myslím, že ještě později se objevily nějaké zajímavé informace ze zákulisí, ale narychlo to nedohladám. Když se to začalo před lety vynořovat, tak jsem to sledoval.

RPG je na svou oblast použití zřejmě dost použitelný jazyk, stejně jako asi i Java, pokud jde o psaní pro konkrétní aplikační platformu. S J2EE jsem naštěstí do styku nepřišel a ani o to nestojím, musel bych si pro slušný vývoj asi dokoupit do desktopu další giga paměti a na to jsem moc líný. :-)

Apropos kompaktnost a rychlost vývoje...kdysi na to vznikla zajímavá studie, ale možná by stálo za to ji zopakovat. Každopádně C++ a Lisp se od té doby moc nepohnuly, takže jejich vztah ve výsledku by neměl být tolik ovlivněn, ale tohle je hloupé hádat, že. Java snad od té doby na ten plyn aspoň trošku přišlápla.

uz davno som nevidel takyto ukazkovy priklad srackoveho vyberu technologii ktory isto spravil nejaky kravatkovy manazersky blbecek.

V Lispe, data su kod, a kod su data. To pre teba ale neznamena nic lebo vies trt barani o skutocnom programovani.

Az Oracle bude krome Pro*C, Pro*C++, Pro*COBOLu, ODBC, JDBC, DBI, ... driveru dodavat i nejaky Pro*LISP, tak o tom zacnu uvazovat.

Vzhledem k tomu, kde pracuji, pro me rozmezi mezi hrackou a nastrojem je, zda v tom napisu aplikaci bezici proti Oracle databazi. YMMV.

Wow! :-D To by člověk nečekal, co? ;-)

Jenže počet řádků kódu není jediné kritérium. Kolik například stáli ti vývojáři? Co se stane, když všichni zahynou? Dokáže to po nich ještě někdo přečíst? Nemohu si pomoci, ale mně Lisp moc čitelný nepřijde. Kdyby to naprasili v Perlu, tak by těch řádek taky mohlo být málo, ikdyž je mi jasné, že Lisp není zdaleka takové zvěrstvo. Psaní vlastních jazyků mi z hlediska flexibility týmu přijde jako dost velké riziko - proč se mám učit nějaký nový jazyk, ve kterém se rochní Pepa od vedlejšího stolu a jinak ho nikdo nezná a proč by se měl Pepa namáhat s jazykem, který jsem si vymyslel já sám?

Možná by se při bližším pohledu zjistilo, že by bylo výhodnější to napsat v Javě nebo C# (dnešní IDE se snaží ruční psaní minimalizovat) nebo, pokud se někomu nechce psát moc řádek, třeba v Pythonu nebo Ruby. A i v tom C++ se dá docela kouzlit.

Takže se mlčky předpokládá, že se deset průměrných vývojářů (== schopných ušmudlat něco v Javě), vyrovná jedinému člověku, který k využití svého potenciálu potřebuje lepší nástroj, případně si musí vyvinout vlastní, aby svůj nápad mohl zrealizovat? Já nevím, ale ve vědě a inženýrství rovnostářství nikdy tak nějak nefungovalo. Tohle "hraní na jistotu" mi nějak nejde dohromady s tím, že cestu k dnes masami využívaným vědomostem a výdobytkům někdo prokopat musel - a nebyl to žádný "Pepa od vedlejšího stolu", ani omylem. Ale jo, při smolení kódu pro webovky to může fungovat - je pravda, že tam se schopný lisper nepohrne. Ten půjde řešit jiné věci.

Mlčky se nepředpokládá nic, jenom se ptám, resp. si dovoluji tu bohorovnost zpochybnit. Že ten jediný člověk je schopný udělat práci za 10 průměrných vývojářů, je dost dobře možné. Že ale nějaký génius bude k dispozici vždycky, to už není jisté. Pokud ten program ale napíše geniální (a disciplinovaný) javista, bude firma v poněkud lepší pozici, dle mého názoru.

Myslim ze na to pozerate trochu zle...

Vytvorenie "noveho jazyka" je len prostriedok, nie ciel. Prostriedok ako dosiahnut vyzsiu citatelnost jazyka.

Urcite viete, ze jazyky sa od seba delia aj urovnou abstrakcie, ktoru poskytuju. Bezne jazyky maju datovu (a pripadne riadiacu abstrakciu - teraz si niesom isty tymito nazvami, ale o to nejde). V takom Cecku Pepa implementuje udajovu strukturu stromu, alebo prioritnej fronty. Niekam do dokumentacie napise ako s nou narabat - a hotovo... mame datovu abstrakciu. Vy pouzivate funkcie ako add_node a pod. a vobec vas nezaujima ako to Pepa vnutri naimplementoval. Ak Pepa odide, nic sa nedeje (ak je jeho implementacia korektna, samozrejme...).

Toto vsetko ma aj Lisp, plus ma nieco, co vami menovane jazyky nemaju, a to syntakticku abstrakciu. Tato abstrakcia vam umoznuje nie len vymysliet a implementovat datove struktury, ktore ostatnym ulahcia pracu, ale aj vytvorit "jazyk" na pohodlnu manipulaciu s nimi. A mnoho dalsieho...

Myslim ze je najdolezitejsie pochopit "krasu a silu" toho, ked nieje rozdiel medzi datami a programom. Ja by som uz Lisp nemenil za iny jazyk (len sa trosku bojim, ze budem musiet... drviva vacsina IT firiem v cechach a na slovensku zial nevie co je Lisp... kopaci kanalov s "modernymi" krompacmi ako Java, C# a pod...)

Pardon, oprava:
Vytvorenie "noveho jazyka" je len prostriedok, nie ciel. Prostriedok ako dosiahnut vyzsiu citatelnost kodu (programu).


Aha a toto, niektore z toho stoji za precitanie:
http://norvig.com/

Samozřejmě je možné, že se takový jazyk čas od času hodí. Ale to se dá zvládnout třeba pomocí Lexu+Yaccu nebo ANTLR. S pomocí nich podobných prostředků lze vytvořit spec. jazyk prakticky pro libovolný programovací jazyk, ikdyž chápu, že v Lispu je ta integrace se zbytkem aplikace z principu přirozenější. Na druhou stranu, např. v C++ je pomocí přetížení operátorů dosáhnout podobného efektu a dokonce i v C s pomocí preprocesoru si člověk podobné úlohy často může usnadnit i bez externích nástrojů.

Jazyk ako Lisp sa hodi podla mna vzdy (az na specialne pripady, ako driver alebo nejaka RealTime aplikacia - teda nieco blizke HW).

V Lispe nepotrebujete ziaden externy nastroj, to robi ten jazyk tym cim je... ale aspon ste uznali, ze je to uzitocne :)... ved preto sa o nieco podobne snazia aj ine jazyky. Skuste si ale predstavit to, ze nieje ziaden preprocesor, ziadne "pretazovanie" operatorov a pod... Ze mate jazyk, v ktorom mozete pisat kod, ktory generuje kod - a to bez obmedzenia nejakym inym jazykom preprocesora, ale presne takym istym jazykom do akeho kod generujete.

Meta-programovanie je mocna zbran, a "brana" do pre vas netusenych moznosti, ako vyjadrit svoje myslienky. Lisp je jazyk, ktory vam nehadze polena pod nohy. Vyberiete si paradigmu (proceduralnu, objektovu - CLOS, funkcionalnu... pripadne ich kombinaciu), ktora sa vam najviac pre dany problem hodi, upravite si jazyk tak, aby sa vam to co najlepsie, najrychlejsie a najcitatelnejsie pisalo...

Pretazovanie operatorov... ach jaj... keby ste len vedeli co vsetko mozete v lispe... :) Skusali ste niekedy implementovat v C++ matice a na pracu s nimi pouzit pretazene operatory? Ak nie skuste... hadajte kolko-krat sa skopiruje matica (objekt) pre napr: A = B + C; ... :)

btw CLOS: http://en.wikipedia.org/wiki/Common_Lisp_Object_System

Este jedna vec k syntaxi. Ak ju raz clovek pochopi, zisti ze vlastne nemoze byt moc ina... a co je dolezitejsie, so spravnymi editormi (parent-matching a automaticke odsadzovanie) sa stane velmi mocnou zbranou. Len z tvaru funkcie sa da zistit, ci je pisana funkcionalne alebo proceduralne :)... ale to len tak btw...

Nebojte sa Lispu, na vysokych skolach je znasilnovany k uceniu funkcionalneho programovania... verte mi... ja som Lisp na skole nenavidel, ked nas ho "ucili"... nastastie som nezanevrel a isiel na neho uplne inak... a nelutujem...

Co se týče toho C++, tak tam se kopírování těch matic dít vůbec nemusí, pokud operátor pracuje s referencemi. ;-)

Například v Pythonu taky poznám hned, kdy se používá funkcionální, kdy procedurální a kdy objektové paradigma. ;-)

Já jsem na VŠ absolvoval kurs Lispu, dokonce je mi ten jazyk i v mnohém sympatický a lákají mě i další jazyky, ale to neznamená, že v těch jazycích budu chtít automaticky dělat věci, které mě živí. Chtěl jsem vyvolat zajímavou polemiku o některých otázkách spíše z pragmatického pohledu. Já netvrdím, že se v Lispu nedá nic pořádného udělat, akorát bych rád slyšel nějaké pádné argumenty, proč a kdy je dobré nasadit Lisp. Že Paul Graham programuje v Lispu, je asi jasné, ale pro mě z toho nic moc nevyplývá. Že nějaká firma X použila pro projekt Y jazyk Z a pochvaluje si to, také automaticky neznamená, že by to s jazykem W nezvládla lépe.

K tym maticiam este :)...

Asi som to trochu zle napisal... referencie pouzit ide, pretazi sa + aj =, a kopiruje sa ta nova matica, teda napr...

A = (B + C) + D;

B + C - jedna matica X

X + D - druha matica Y

A = Y

funguje to takto niejako, nie?... lenze B + C aj X + D musia tu maticu (X, resp. Y) vytvorit pomocou operatora new, to znamena v heape, nie na zasobniku (aby po ukonceni funkcie/operatora + stale existovala)... povedzte mi ako ju potom upracem, zmazem????

Ak je nieco zle na tom, co som tu pisal, tak mi povedzte, rad sa poucim (vazne, nemyslim to ironicky, je kludne mozne ze sa mylim) :)

Tohle se da vsechno obejit pres expression templates. Zhruba receno to znamena, ze treba operator+ nedela zadnou praci, ale vrati nejakou strukturu popisujici vypocet souctu dvou matric.

To je něco jako lazy evaluation svépomocí? ;-)

Aneb jak velmi složitě provést něco, co jinde uděláte jednoduše.

Pokud

Matice &A = B + C;

pak nikoliv. Samozřejmě ale předpokládám, že operator+ vytvoří novou matici, ale je možné změnit jednu z původních "in place" a vrátit referenci na ni. Každopádně si nemyslím, že by se tohle dalo vyřešit v nějakém jazyce výrazně lépe.

Abych řekl pravdu, na programování třeba expertních systémů mi více sedí jazyky typu Prolog, ale uznávám, že flexibilita Lispu by mohla v podobných případech pomoci. Podobně jako tng vidím ale největší brzdu v nedostatku vhodných knihoven (rychlý GUI prototyp udělám třeba v PyQt nebo PyGtk, v CL to asi tak snadné nebude a podobně v dalších oblastech - zkrátka CL nemá "batteries included" jako některé jiné jazyky), je ale třeba možné uvažovat o použití Lispu nad JRE, což by ten handicap poněkud snížilo. A vývojářů ochotních používat Lisp asi taky bude o něco méně, jak výše jmenovaný předřečník taky zmiňoval.

Takze k nasim maticiam :) V lispe by nebolo problem spravit makro, ktore by zobralo matematicky vyraz s maticami (kludne aj v infixe), a cele spocitavanie matic by sa rozlozilo na kod, ktory modifikuje jednu jedinu maticu... Napr.: (toto je len cisto hypoteticky priklad, ak sa nastvem tak vam to mozno aj nakodim ;)

(with-matrix (A B C D)
  (setf A (+ (+ B C) D)))

Staci napisat funkciu na scitanie dvoch matic, ktore modifikuju tretiu:

(defun matrix+ (dest-matrix source-matrix-1 source-matrix-2)
  "nejaky kod co nasetuje dest-matrix")

Makro with-matrix by sa rozlozilo na nieco taketo (jeho kod by myslim nebol zlozity, nejaka ta rekurzia):

(progn
  (matrix+ A (matrix+ A B C) D)
  A)

Toto je samozrejme len nacrt, nechce sa mi to teraz kodit :)... len som chcel demonstrovat, co vsetko je mozne s lisp makrami... a sak o tom je aj tento clanok, nie?

Btw: toto len pre toho koho to zaujima... myslim ze vo forme (seft A ..bla bla..), v tom ...bla bla.. by sa v tomto pripade nemohlo pouzit samotne A, lebo funkcia matrix+ robi na A side-effect...

Pre niekoho kto by nechapal o co mi islo... to makro by mohlo vyzerat kludne aj takto:

(with-matrix (A B C D)
  (A = ((B + C) + D)))

A este k tym GUI... no hej, existuje ich par:

http://www.cliki.net/Graphics%20Toolkit

Ale pravda je, ze o klavite a rychlosti niektorych z nich by sa dalo polemizovat... ja pouzivam vyhradne REPL ked pracujem so svojimy programami... ked som potreboval nieco jednoduche vykreslit, pouzil som LTK (Tcl/Tk binding, mnou trosku upraveny... uznavam ze to nieje nic moc...). Inak kniznic do CL je hromada a na vselico, doporucujem popozerat spomenute www.cliki.net

V C++ řešit práce s maticemi pomocí overloaded operátorů není dobré řešení, ale budiž, někomu se na to může hezky koukat.

Jen reference nevyřeší vše. Ještě přidám jeden způsob "kopírování" matic. Při overloaded operatoru+ se nevrátí class "matice" ale jiná (třeba zděděná) struktura, kterou nazveme třeba "generovana_matice". A tím dáme v compile-time najevo, že do takovéto matice se dá "hrabat", není const, můžeme do ní zapisovat následující výsledek a že smíme její data ukrást pro cíl.

Technicky, předpokládám, že class "matice" neobsahuje vlastní data, ale jen odkaz na alokovanou strukturu, plus nějaké info o rozměrech. V copy constructrou se pak nemusí udělat new a memcpy, stačí zkopírovat pointer (z generované matice).

A kdybych to chtěl dotáhnout fakt až do konce, tak i info o rozměrech přesunu do onoho alokovaného prostoru a class matice i generovana_matice je jen pointer na data. Proč to? Protože pokud mám dobrý kompilátor (umí to i borland 5.0 z před 12 lety) a pointer má stejný sizeof jako int, tak kompilátor dokáže divy - při return matice nealokuje žádné extra místo na stacku, celý class (4 bytes) vrátí via (E}AX;

Potom např. deklarace "matice A=B+C;" provede _jediný_ construktor, kterým je právě jeden copy constructor. A bude-li to z "generovane_matice" tak copy constructor sestává z překopírování ukazatele. Vše. Přičemž overloaded operator+ provede new pro cílová data B+C.

Obdobně, "matice A=B+C+D;" provede nejprve B+C, vrátí generovanou matici. Pak se provede (jiný) overloaded operator+ (generovaná_matice&, const matice& D) který přímo do generované (tedy už bez new) přičte D. Nakonec se obdobně jako v předchozím odstavci copy constructorem vyplní A (opět jen kopie pointerů, ne dat).

Pokud bychom nepoužili sčítání při dekladaci A, ale až později přiřazení:
matice A;
... něco...
A=B+C+D;

tak přibude navíc volání default constructoru A (při deklaraci) ... pravděpodobně vyplnění 0 do pointeru na data. Následně pak overloaded operator= (přiřazení do A) by se nejprve pokusil smazat stará data (zde pointer 0, delete neproběhne, ale kontrola tam být musí pro jiné případy) a pak do toho pointeru se dal hodnotu pointeru z generovana_matice. Tedy opět žádné new a kopie dat matice.
---
Všechny příklady předpokládají, že po přesunu pointeru z generované matice se její pointer nuluje. Ale i tak se při destrukci generované matice musí jistotu kontrolovat a při nenulovém delete data. To jen pro případ, kdybychom jen tak napsali "B+C+D;" bez přiřazení. Nejsem si totiž jist, zda při takovém šíleném overloadování se dá v comile-time jednoznačně určit, že jde o nonvolatile operace a že si kompilátor může dovolit celý výraz nevykonat.

A honem honem se opravím - upřesním.
... deklarace "matice A=B+C;" provede _jediný_ construktor ...
Má být jediný (copy) constructor _pro A_. Předtím se musí ještě vykonat constructor generované matice.

Tedy, že "matice A=B+C;" kompilátor přeloží jako "matice A(B+C);" a ne "matice A; A=B+C;"

Toť otázka.

1) Pro A=B+C; se vždy a ve všech prog. jazycích musí číst dvě matice {B,C) a uložit do alokované třetí (A). Pokud to nechci, tak použít třeba B+=C;

2) "new / malloc" bývá celkem optimalizované na rychlost. A to je jediné, čim se B+C liší od B+=C. Vždy se musí pushnout double z konkrétního místa C, pushnout double z konkrétního místa B, add, pop na konkrétní místo (B nebo A). FP operace se pokud vím stále nedokáží provádět přímo na cílovém místě v paměti - pokud se mýlím a umí to, tak se omlouvám (už to nějaký ten pátek nesleduji tak podrobně).

A teď co je rychlejší. FP add, sub, ..., nebo memory read & write. V dnešní době L1, L2, ... si netroufám odhadovat. Pravda, možná tady by se projevila výhoda "+=" oproti samotnému "+".

Prošel jsem několika programovacími jazyky, ovšem posledních 16 let programuji v C-like jazycích (jednoznačně převažuje C++).
V LISPu jsem napsal jenom několik velmi drobných studijích příkladů na vysoké škole.

On LISP, stejně jako jiné akademické projekty, není nezajímavý... je jen pro řešení většiny reálných problémů nepraktický... a myslím, že to velmi dobře odráží "mohutnost" skupiny jeho uživatelů...

Mohu se zeptat, jaké že "reálné problémy" to máš na mysli?

Pod pojmem reálný problém jsem měl na mysli požadavek z reálného světa (nikoliv akademický příklad) jako např.
- nejrůznější webové aplikace, např. eShopy, přímé bankovnictví, redakční systémy, zákaznické webové aplikace
- jakákoliv desktopová aplikace, browser, ftp klient, grafický editor, CAD aplikace, přehrávač multimédií, atd. atd. atd.
- výkonné serverové aplikace, databáze, webové servery, indexování obsahu, simulace proudění kapalin atd...

speciálně se spoustou CAD aplikací psaných v lispu (ACAD Lisp) se denně setkávám

Ano, Autodesk kdysi zvolil pro svůj AutoCAD LISP coby interfacový jazyk (nevyplývá z toho ovšem ani v nejmenším, že by byl AutoCAD v LISPu napsán). Fakt, že takové Vámi popisované aplikace existují, je dle mého názoru daný tím, že AutoCAD se postupem času stal defacto standardem ve svém oboru a jiný interface nenabízel... Když není alternativa, je výběr jednoznačný ;-).... ovšem v jiných oblastech (kde alternativy jsou) LISP téměr nenajdete.

Pokud je mi známo (a to se můžu skutečně velmi mýlit, protože jde o oblast mi relativně vzdálenou), sám Autodesk od AutoLISPu upustil a už léta ho nerozvíjí (nemůže ho ovšem odstranit, když jak sám píšete existuje velká spousta aplikací, které ho využívají).

CAD software přinejmenším zčásti založený na Lispu nabízí ještě Fractal Concept, Design Power, Dassault... Spousta věcí v tomhle oboru ostatně vznikla na Lisp Machines...

Pokud se něco za posledních pár let nezměnilo, nesahá AutoLisp v možnostech tvorby aplikací pro Autocad C++ ani po kotníky (ObjectARX + OMF dovoluje "malinko" něco víc).

http://en.wikipedia.org/wiki/Viaweb

Podle me neprakticnost Lispu je zpusobena miniaturni komunitou, ktera nema silu napsat hromady knihoven a kvalitni multiplatformni implementace, dale samozrejme je asi skoro nemozne sehnat programatory ktere ho ovladaji. Sam o sobe mi ten jazyk ale neprakticky fakt neprijde ... Obavam se, ze clovek ktery napsal v Lispu par skolnich prikladu typu "vymaz zadany symbol ze zadaneho listu" apod. opravdu neni schopen ten jazyk rozumne posoudit. Z meho pohledu je Lisp jazyk ktery mi umoznuje se vyjadrovat na vysoke urovni abstrakce a tim psat strucny a vystizny kod ktery je blizky pseudokodu. V Lispu ma clovek moznost vyznamne zuzit propast mezi myslenkami a kodem.

no budu Ti trochu oponovat, z vlastni zkusenosti vim ze je to spis obracene. lisp vedle napriklad prologu jsou jazyky vlastni kybernetice a podoboru umele inteligenci. treba na praci s grafy je lisp opravdu skvely, a to nemluvim o velice snadne zmene kodu za behu kterou napriklad java jeste neumi.

neco jineho uz je "bezne" programovani kde pro lisp existuje spoustu ruznych implementaci a kde si clovek musi vyslapat tu svoji spravnou cesticku a nebo si koupit napriklad allegro common lisp ktery stoji neco pres 100t a pak je bez problemu pouzitelny i na kompletni aplikaci. sam jsem vyzkousel ekvivalent javove knihovny struts, a je to opravdu nesrovnatelne s javovou verzi. je to velice jednoduche a pritom nezjednodusene oproti struts v jave, ostatne jako vetsina veci v lispu :-)

Lisp je jazyk, který nechává svojím elegantním návrhem, mocností a přitom jednoduchostí, svou krásou a půvabem, i radostí s tvorby všechny ostatní jazyky daleko daleko za sebou :-D

Ne, opravdu nefetuju. Ale za tímhle si stojím :-D

Tak seš teplej, že jo? ;-)

V tomhle počasí ty ne? :-P

LSD není tvrdá droga ale psychedelikum. Odvození analogie ponecháme na čtenáři jako cvičení. :)

Jen drobná poznámka (dneska mám nějakou diskuzní ;-) ):

Fakt, že LSD je halucinogen (to je samozřejmě pravda) není v rozporu s tvrzením, že je to tvrdá droga.
Dělení drog na měkké a tvrdé je samo o sobě dost diskutabilní... ale pokud na ně přistoupíme, pak LSD je řazeno spíše do skupiny tvrdých drog.

Typický postup zakomplexovaného člověka... Něco jsem nepochopil, tak je ta věc špatná. Takže nazývejme věci pravými jmény. V LISPu jste se nedokázal zorientovat a pochopit jeho filosofii, ale místo abyste to pochlapsku přiznal, tak budete tvrdit, že to LISP je špatný.

V read-time? Já myslel, že tehdy běží jen reader makra. Každopádně defmacrovaná makra se vyhodnocují v compile-time, jen v tom prvním příkladě měla ta (asi poměrně nešťastná) formulace znamenat, že v REPLu se výsledná forma vyhodnotí hned po makroexpanzi. (A vyhodnotí ji samozřejmě eval již bez asistence makroexpandéru.)