Názory k článku
Programovací jazyk TCL (4)

Perl's Unicode Support

Starting from Perl 5.6.0, Perl has had the capacity to handle Unicode natively. Perl 5.8.0, however, is the first recommended
release for serious Unicode work. The maintenance release 5.6.1 fixed many of the problems of the initial Unicode implementa-
tion, but for example regular expressions still do not work with Unicode in 5.6.1.

Starting from Perl 5.8.0, the use of "use utf8" is no longer necessary. In earlier releases the "utf8" pragma was used to
declare that operations in the current block or file would be Unicode-aware. This model was found to be wrong, or at least
clumsy: the "Unicodeness" is now carried with the data, instead of being attached to the operations. Only one case remains
where an explicit "use utf8" is needed: if your Perl script itself is encoded in UTF-8, you can use UTF-8 in your identifier
names, and in string and regular expression literals, by saying "use utf8". This is not the default because scripts with legacy
8-bit data in them would break. See utf8.

Perl již od verze 5.6.0 pracuje s unicode nativně, přičemž se dnes asi už najde dost málo lidí, kteří by používali verzi nižší než 5.8.0. Perl je tedy pro práci s řetězci výhodnější než dnes mnohdy mylně upřednostňovaný Tcl :-) Než něco plácnu, zjistím si co a jak. Mimochodem, jak je na tom Tcl co se týče použití unicode v názvech proměnných? :-D

Ještě malé upřesnění. Ona poznámka o nefunkčnosti v regulárních výrazech se týká verze 5.6.1. Ve verzi 5.8.0 je podpora unicode v regexpech o jaké se tcl ani nesní.

Od sedmé verze Tcl jsou všechny řetězce interně reprezentovány v Unicode. Takže se to ihned projevilo i v používaných knihovnách. Jediný problém by mohly mít knihovny, které soubory načítají po bytech, ale většinou (~99%) se používají puts() a gets(). Programátor tedy může zapomenout na nějaké rozdíly v kódování a prostě si používat ty svoje češtiny a čínštiny bez omezení.

S Perlem byly problémy například v modulu CGI při zpracování requestů. Na druhou stranu se mi líbí specifikace kódování při otevírání souborů pomocí OPEN - to často pomůže (třeba teď děláme intranetovou aplikaci, kde komunikace striktně probíhá v UTF-8, ale databáze, logy a externí tabulky atd. jsou v ISO-8859-2).

Mimochodem, za tou větou je xichtík :-), na který se měli chytnout lidé, co mi stále říkají, že regexpy umí pouze Perl (najdou se dokonce tací, kteří ani neví o existenci knihoven pro regexpy na C a Javě - i to musíme používat).

Poznamka: i PHP umi regexp ... po pravde by me prekvapilo kdyby to dneska nejaky interpretovany jazyk neumel. Rozdil je jen v rozsahu podpory.

Napada me tak akorat Basic a jeho "klon" Visual Basic. Tam jsou regexpy resene pomoci knihovnich funkci, coz je neco uplne jineho nez podpora primo v jazyku. Z knihovny muzu regexpy pouzivat klidne i v assembleru :-)

Diskuse o Tcl použití názvů proměnných je například zde:
http://wiki.tcl.tk/2874
další info jsou zde
http://wiki.tcl.tk/515

Hmm. Tak to přesně odpovídá tomu co jsem včera zjistil. Můžu použít unicode v názvu proměné, ale nemůžu to napsat přímo, ale zakódované \u. To je trapárna. V perlu žádné takové omezení není. Pouze je potřeba na začátku napsat use utf8; a od té chvíle můžu psát do proměných co si zamanu. Tcl je sto let za opicema :-)

A který jazyk z tohoto hlediska není :-) Python viz http://mail.python.org/pipermail/idle-dev/2000-April/000133.html :-) Java - prakticky nefunkční při přenosu zdrojáků atd.

Dobře, v tomto uznávám Perl a opět se klaním Larrymu :-))) [to však nic nemění na podpoře Unicode při práci s řetězci a regexpy]

ps: jen pro zajímavost: používá někdo tuto featurku? Já jsem zatím viděl pouze poznámky k programům psané v azbuce a i to bylo zajímavé, což takhle vidět program, ve kterém jsou funkce a proměnné psané v unicode, například v korejštině (předpokládám, že co platí v Perlu pro proměnné, platí i pro názvy funkcí).

Samozřejmě, jména proměnných, filehandly i jména funkcí. Ani já bych takový kód číst nechtěl. Když Larry implementoval unicode do interního uložení stringu a potažmo do klíčů hashe, tak už s tím žádnou velkou práci neměl. Stačí si jen uvědomit jak jednoduše jsou jednotlivé věci uloženy v paměti. Viz třeba vypsání všech funkcí v main prostoru :-D

while ( my($name, $sym) = each %main:: ){
no strict;
print $name,$/ if *$sym{'CODE'};
}

Teď koukám, že to no strict je tam zbytečně. To je tak, když to upravuju z něčeho jiného. Ten kód je komplet strict :-)

Hele, tady se asi inspiroval jazykem Tcl :-) Tam se také dají podobným způsobem vypsat (ale i interpreteru pod rukou updatovat - fuj) funkce a proměnné.

Asi už nevypátráme kdo se kým nechal inspirovat, ale je to skoro nezbytná feature například při testování. Viz. například úryvek z jednoho testu co jsem psal nedávno:

sub test_checkRCache : Test(5) {
my $testObj = shift()->{obj};
no warnings;
local *Cache::CheckCache = \&MyCheckCache;
use warnings;
...
}

On je vlastně podobným způsobem napsán i debugger pro Perl ne? Musím se mu mrknout do zdrojáků (číst cizí zdrojáky v Perlu, hlavně od některého z guruů, je docela dobrodružství).

Myslím, že nečitelnost zdrojáku v perlu nemá nic společného s guru/notguru. U guru je akorát vetší ryziko, že použije obrat, který neznáš. Na druhou stranu u neguru je větší pravděpodobnost, že použije na úplně jednoduchou konstrukci zbytečně komplikovaný kód. Výsledek u neguru může být horší než u guru. Je fakt, že v perlu máš větší volnost napsat nečitelnou prasárnu než u jazyků, které nevytvořil lingvista :-)

Já jsem to myslel právě tak, že se z guruovského kódu zase naučím něco nového. Něco jsem se mimochodem naučil i ze zdrojáků, které byly uvedeny tady na Rootu, když se otáčelo pořadí bytů v souboru s obrázkem (to byla ta soutěž o složení obrázku nového Roota). Chtěl jsem sice poslat co nejkratší program ve Forthu, ale některé Perlové výtvory mě opravdu dostaly :-)

Je fakt, že v perlu máš větší volnost napsat nečitelnou prasárnu než u jazyků, které nevytvořil lingvista :-) - neboj, to stejné platí i například i pro Forth :-) Tam není problém napsat slovo (funkci), které nějakým způsobem změní samotný interpreter (viz například slovo DOES> apod.), takže každou chvíli se může například operátor + chovat nějak jinak :-)

Když tak nad tím přemýšlím, tak debuger asi ne, ale profiler napsaný tímto způsobem si představit dovedu. To bych zvládl i já :-)

Asi ne celý debugger, ale nějaký komentovaný výpis obsahu paměti (datové typy, reference atd.) by asi šel, ne?

Pro výpis paměťových struktur je tu Data::Dumper. Na druhou stranu si dokážu představit dynamické nastavování brakepointu na začátek a konec jednotlivých funkcí a nějaký ten interface taky. Takže říkám, asi by to šlo a možná, že to tak dokonce je.

Ještě dodám, že toto je problém pouze vstupu do interpreteru, interně je opravdu vše (řetězce, proměnné, funkce) v Unicode:

http://mail.python.org/pipermail/python-dev/2000-March/002606.html (týká se to i Tcl/Tk, ten název stránky je v tomto případě trošku matoucí).

tcl >= 8.1 uklada interne veskere string reprezentace v UTF-8 (ne v Unicode).
oktet 0x0 koduje jako C0 80, tj. 2-byte UTF-8.

zdrojak/script muzete psat klidne v jakemkoli kodovani, napr. utf-8,
jde o to, aby v okamziku nacteni skriptu pomoci source prikazu
bylo 'implicitni' encoding pro kanaly (to co vrati encoding system)
bylo shodne s encoding scriptu

flag -encoding encname pro source prikaz se snad nijak neujal,
osobne pouzivam fsource ze spravne na-fconfigure-ovaneho kanalu

encoding system se zpravidla urci dle LC_, locale apod

samozrejme zapis pomoci \uxxxx je vuci neshode encoding system a encoding souboru imunni

co vim, tak <?xml ...encoding='utf-8' ?>
a
# vim: fileencoding=iso-8859-2
oznacuji kodovani entity/souboru, ma perl use utf-8 take takovou povahu?

Nevyjádřil jsem se asi přesně, když jsem říkal, že Tcl má stringy v Unicode. Myslel jsem tím UTF-8, což je - alespoň pokud tomu dobře rozumím - pouze jeden ze způsobů (IMHO nejlepší, protože nezávislý na platformě), jak zakódovat znaky Unicode do datového streamu.

To modifikované kódování oktetu 0x00 je použito například i v Javě. Je to z toho důvodu, aby se konec řetězce dal vždycky bezpečně označit nulou (C-like řetězce) a mohlo se s řetězcem zacházet jako s byty (funkce strcpy(), strcmp() atd).