IT Laboratoř

To jsem zase na Twitteru něco napsal:

„Existuje nějaký rozumný důvod, proč většina (?) programovacích jazyků neumožňuje v identifikátorech funkcí/proměnných dávat otazník?“

~ Lukáš Havrlant, about 5 hours ago from TwitterFox

Výsledek? Mnoho strašně chaotických reakcí, na které už radši ani odkazovat nebudu, protože čert aby se v tom vyznal. Teď se trochu oklikou jdeme dostat k otazníkům v identifikátorech.

Kdo mě četl, ten už jazyk Scheme zná. Scheme je ve zkratce (ne čistě) funkcionální jazyk, která má docela zajímavé konvence pro identifikátory. Máte-li funkci, která vrací true/false, končí tento predikát otazníkem. Jako byste se ptali: platí tento výrok? Je toto číslo sudé? A tak ve Scheme naleznete predikáty jako even?, number? nebo list?. Je to těžce návykové a hezky čitelné. Kód pak čtete jako větu. (if (even? 5)). Krása, ne?

Scheme má i jiné hezké konvence jako vykřičník. Ten se dává na konec funkce v případě, kdy má funkce destruktivní účinky. Programujeme-li funkcionálně, píšeme obvykle programy jako matematické funkce, to jest zanořujeme do sebe funkce a výsledek jedné funkce je předán jako argument jiné funkci: f1(f2(f3(), f4())). To je dobrý systém, protože máte vše pod kontrolou a nestane se vám, že by nějaká funkce měnila něco někde úplně mimo prostředí funkce. Pro příklad: „funkcionální“ verze reverse (převrátí hodnoty v seznamu) by se chovala takto (použiji nějaký pseudojazyk):

Seznam = (1, 2, 3);
PrevracenySeznam = reverse(Seznam);

V Seznam by byl stále seznam (1, 2, 3) a v PrevracenySeznam by byl seznam (3, 2, 1). Destruktivní verze reverse by se chovala takhle:

Seznam = (1, 2, 3);
reverse(Seznam);

V Seznam by nyní bylo uloženo (3, 2, 1). Původní seznam jsme nenávratně ztratili. Rozdíl je jasný. No jo, ale jak teď rozlišit, kdy funkce pracuje destruktivně a kdy ne? Obvykle jde funkce naprogramovat oběma způsoby. Scheme má na to konvenci – pokud se funkce chová destruktivně, má na konci identifikátoru vykřičník. Stejně jako má predikát otazník. Takže funkcionální verze reverse by se jmenovala reverse, kdežto destruktivní reverse!. Rozdíl je opět vidět na první pohled. Pro příklad z jiných jazyků nemusíme chodit daleko. PHP asi skoro všichni čtenáři znají, takže co třeba tenhle případ:

$Array1 = array("red", "green", "blue", "yellow");
$Array2 = array("red", "green", "blue", "yellow");

array_splice($Array1, 2);
array_slice($Array2, 2);

var_dump($Array1);
var_dump($Array2);

Pro jistotu: Funkce array_splice odstraňuje vybrané prvky, array_slice extrahuje. array_splice tedy odstraní z pole vše od indexu 2 a dál, array_slice naopak zachová vše od indexu dva a dál. A teď otázka, především pro ty, kteří tyto funkce neznají podrobně. Co bude uloženo v proměnných $Array1 a $Array2? Změní některá funkce své předané argumenty? Pokud by zde existovala vykřičníková konvence jako ve Schemu, odpověď by byla jasná. Správná odpověď je, že funkce array_splice je destruktivní, zato array_slice ne. Dle Schemovské konvence by pak zápis funkce vypadal takto: array_splice!.

Poslední konvencí je konverze jednoho typu na druhý. To se neprovádí dvojkou, jako to člověk občas vidí jinde (html2pdf apod.), ale pomocí ->. Takže funkce na převod z desítkové do binární soustavy by se mohla jmenovat dec->bin.

Výborně, už známe konvence Scheme a zpět k mému twitu. Jak je vidět i na těchto příkladech, použité konvence se vztahují hlavně (jenom?) na názvy funkcí. Bohužel jsem nahoře napsal „v identifikátorech funkcí/proměnných“ a snad všichni reagující se chytili té proměnné, kterou jsem tam vlastně přidal do počtu (což nemohl nikdo vědět, že). Aneb když může být otazník ve funkci, proč ne třeba i v té proměnné. Prásk to za lomítko. A už to bylo v háji :-).

Takže abych to upřesnil. Nejde mi o otazníky v názvech proměnných, je pravda, že si nevzpomínám, jestli jsem je používal ve Scheme, asi spíš ne. Otázka měla znít, proč většina jazyků nedovoluje použít otazníky v názvech funkcí? V C# máme kupříkladu funkci TrueForAll, proč by se nemohla jmenovat TrueForAll?? Nebylo by to čitelnější?

Poznámka na konec: Nejde mi o naroubování této feature do současných jazyků, takže odpověď „není to možné kvůli kolizím s jinými prostředky jazyka“ není relevantní, pokud by se s tím počítalo od začátku (o což mi jde), nebyl by s tím problém. Navíc u funkcí by nejspíš kolize nenastala nikde.