Vlákno názorů k článku Operátory a asociativní pole v jazyku Lua od redhead - mrzime jen ze neexistuji zkraceniny operaci jako in(de)krementace,...
-
Pavel TišnovskýZlatý podporovatelPravda, taky mě to zpočátku zarazilo, autoři tu absenci vysvětlují po svém, cituji:
"
Why does Lua lack the += operator, etc.?
One of Lua's design goals is simplicity. Most languages are large, meaning that they have many sophisticated features built-in. Examples are C, C++, Python, Lisp, ML. A very few languages are small. Examples are Forth and Lua. Lua aims to provide a small range of atomic features which are truly essential, and from which many other sophisticated features can be constructed if desired. Examples of sophisticated features which can be added to Lua from within the language include modules, object orientation, and now exceptions and threads which can be implemented via coroutines in Lua 5. The absent += operator is one more example.
I thought the reason was more practical. Many argue for adding these operators because of the efficiency gains they enable. But in Lua things would get confusing because of the extension system. It's in the lua-l archives somewhere... --JohnBelmonte
I think it's more basic than that - you must draw a line in the sand for the amount of operators a small language should have. You allow +=, then people ask why not *= and -= etc etc. Before you know it, you have added many operators which simply makes it bigger. Small and simple is Lua's tenet.
"
da se s tim zit (i kdyz nekdy skripu zuby), nebo pouzit tuto techniku:
http://lua-users.org/wiki/CustomOperators -
Pavel TišnovskýZlatý podporovateljj, s Metalua se daji delat veci... <flame>takový čitelnější Lisp :-)</flame>
-
anonymní
takový čitelnější Lisp
Jak v čem. :-) To, že zdrojový kód je datová struktura syntaktického stromu může podle situace být výhoda i nevýhoda. Na Lua se mi líbí, že to je vlastně takové Scheme s méně závorkami (a tudíž s ním člověk zažene na útěk méně lidí). :-)
Spíš nechápu, jak někdo může kritizovat absenci += (což je skutečně vyšším jazyku vyložená prkotina) a naopak si nepovšinout třeba plné podpory tail callů, což mi přijde jako docela bonus (stavové automaty přímočaře a podobně). Když chybí to první, je to prakticky úkol pro find-and-replace v textovém editoru. Přepsat kód počítající s dostupností tail callů do jazyka, který je nepodporuje, je podle mě mnohem větší otrava.
-
Ksl (neregistrovaný)
To snad záleží na sémantice operátoru, datovém modelu jazyka a konkrétních datových typech, ne? Kupříkladu u immediate hodnot (třeba tagovaných) žádné "vytvoření kopie instance" ani nepřichází v úvahu. (Jak byste chtěl třeba změnit hodnotu (abstraktního) celého čísla?)
A Lua (naštěstí) není C++. BTW, třeba Ruby ani nepovoluje definovat operaci x+=y tak, aby měla jinou sémantiku, než x=x+y. A taky mi to přijde jako docela dobrý nápad. Umím si živě představit, jaké bugy by se pak začaly vyskytovat.
Překladač by to sice v případě, že dochází k zapisování do té samé proměnné, mohl reflektovat, ale to mi nepřijde moc košer.
Tak to je asi nejstrašidelnější myšlenka dne. :) -
Inkvizitor (neregistrovaný)Inkrementace a dekrementace mi přijdou vcelku zbytečné; je to jenom speciální případ += a -= a prefixová a postfixová notace v C apod. jenom zbytečně zesložiťují jazyk a zdrojové kódy. += apod. naopak smysl mají všude tam, kde existuje možnost přetížení operátorů v typovém systému; pokud se bavíme o imperativním kódu.
-
Pavel TišnovskýZlatý podporovatelTaky je zde otazka, jakou by ty operatory mely semantiku, protoze prirazeni v Lua je trosku obecnejsi, nez prirazeni v ceckovych jazycich. Urcite by se to dalo zadefinovat, ale mozna by to bylo trosku zmatecne (coz je presne proti tendencim, kam Lua miri):
a,b+=2,3
nebo jeste jinak:
a,b*=fce()
