Perlová magie 2 aneb zákeřnost

2.2.2007 14:42 | Přečteno: 1403× | Perl | poslední úprava: 5.2.2007 12:52

Při ladění jednoho kusu kódu jsem narazil na další perlovou nechutnost. Vyzkoušejte sami:

perl -le 'sub a {@{$_[0]}}; sub b {a($_[0]), a($_[1])}; print scalar b([1,2], [3,4,5])'

Jaký by jste čekali výsledek? Já jsem čekal 5 a ono 3. Skoro bych to považoval za bug. Proč 5? Protože

perl -le 'sub a {@{$_[0]}}; sub b {a($_[0]), a($_[1])}; print scalar(@c=b([1,2], [3,4,5]))'

Abych předešel dalšímu šíření chyby tak se to dá řešit třeba takto:

perl -le 'sub a {@{$_[0]}}; sub b {@{[a($_[0]), a($_[1])]}}; print scalar b([1,2], [3,4,5])'

Problém je v tom, že když chcete udělat funkci, která vrací spojení dvou a více polí vrácených dvěma a více jinými funkcemi, tak sice dostanete správné pole, ale funkce scalar vyhodnotí pouze výsledek poslední funkce. Je nutné to pole materializovat a potom se to chová správně. Ale kdo na to má myslet?

Update: Kdykoli funkce má vracet pole, ujistěte se, že skutečně vrací pole a to i ve skalárním kontextu. Tedy, že výsledkem je array proměnná, grep, map, split a další array funkce, nikdy hodnoty oddělené čárkou. V opačném případě ve skalárním kontextu nebude výstupem počet prvků pole, ale poslední prvek ve skalárním kontextu. (viz Comma Operator v perlop) Samozřejmě vyjma případu, kdy to opravdu zamýšlíte, nebo měníte chování podle wantarray

Update2:Minimalistická demonstrace problému:

perl -le 'print scalar sub{(3,2,1)}->()'

vs.

perl -le 'print scalar sub{@{[3,2,1]}}->()'

       

Komentáře

[zde]

Který sadista vás donutil používat perl?

[Hynek (Pichi) Vychodil]

Blokovat používám jen opravdu vyjímečně, pokračuj v načatém kurzu a jseš druhej člověk, na který ho použiju.

[zde]

Proč se hned urážíte? Mě v tom nutí dělat taky, jsme na stejné lodi. Akorát jsem moc nepochopil v čem je problém. To že si Perl vysvětluje programátorovy intence velmi volně a používá skalární a seznamový kontext naprosto neočekávaně je věc známá, proto peru syntaktický noise jako @{} kamkoliv se dá.

Posledně mě vypeklo něco jako

$a = undef;
$a += undef;
print defined($a);

[happy barney]

imho sa mýlite, k perl-u nútiť netreba

[Michal Vyskočil]

Mě v tom nutí dělat taky, jsme na stejné lodi.

Myslím že ne Time . Afaik je Perl jeho oblíbeným jazykem.

[Hynek (Pichi) Vychodil]

Sorry, asi jsem to špatně pochopil, mě do toho nikdo nutit nemusí, já v tom programuju profesionálně, dobrovolně a velké projekty. Syntaktický cukry bych radši necpal, kde se dá, protože to degraduje rychlost. To radši budu vědět co to dělá a proč. Ten váš poslední příklad je celkem normální. Zapněte si warning a uvidíte proč. Prostě undef+undef je 0+0 a undef.undef je ''.''. Stejně jako 'text'+0 je 0 a 'text'.0 je 'text0'.

[zde]

Jasně, já jen čekal že Perl při počítání s undef-em buď hodí výjimku (ala Python), nebo aspoň garantuje že výsledek bude zase undef (ala SQL). Ale on to vesele zkonvertuje na nulu a směje se... Mimochodem aritmetika je v perlu fakt podivná, jsou tam věci jako 1 << 32 == 1, -1 | 1 == 4294967295 a podobné vypečenosti..

[MJ]

Jenže takhle podivnou aritmetiku má i Céčko

Operátor << není definován pro posun větší nebo rovný šířce slova (na i386 posouvá modulo šířka slova), operátor | je z definice unsigned.

[Michal Vyskočil]

Jenže takhle podivnou aritmetiku má i Céčko

To ano, ale u skriptovacích jazyků nebývá argument "takto se chová i céčko" moc dobrý . Tvůrce Pythonu například bezmyšlenkovitě okopíroval sémantiku dělení, kdy int / int --> int, kdežto Perl na 5/2 vrací 2.5.

[zde]

Ne tak docela..

http://www.python.org/doc/2.2.3/whatsnew/node7.html

[Michal Vyskočil]

Aha, o from __future__ import division jsem nevěděl.

[MJ]

To ano, ale u skriptovacích jazyků nebývá argument "takto se chová i céčko" moc dobrý .

Ne, ale říká, že jsou dobré důvody k tomu, aby takovéhle výrazy neměly definovanou hodnotu.

Tvůrce Pythonu například bezmyšlenkovitě okopíroval sémantiku dělení, kdy int / int --> int, kdežto Perl na 5/2 vrací 2.5.

Perl vrací buďto 2 nebo 2.5 podle toho, jestli jste si zapnul integerový nebo floatový mód (use integer).

[zde]

Perl je multiplatformní, vlastnosti x86 architektury jsou irelevantní. Perl se navíc občas TVÁŘÍ jako že umí počítat s čísly nad 2**32, viz:

$ perl -le 'print 2**32'
4294967296
$ perl -le 'print (2**32) + 1'
4294967297
$ perl -le 'print 2**31'
2147483648
$ perl -le 'print (2**31)*2'
2147483648 (ehhh?)
$ perl -le 'print 1 << 31'
2147483648
$ perl -le 'print (1 << 31) << 1'
2147483648 (ehhh?)

[Hynek (Pichi) Vychodil]

Ehh, musím uznat, že to není moc dobré

$ perl -le 'print 2*(2**31)'
4294967296
$ perl -le 'print ((2**31)*2)'
4294967296

[happy barney]

 perl -w -le 'print (2**31)*2'
print (...) interpreted as function at -e line 1.
Useless use of multiplication (*) in void context at -e line 1.
2147483648

 perl -w -le 'print (1 << 31) << 1'
print (...) interpreted as function at -e line 1.
Useless use of left bitshift (<<) in void context at -e line 1.
2147483648

perl imho predpokladá, že ho používa rozmýšľajúce stvorenie

[zde]

Rozmýšlející stvoření předpokládá, že když je někdo tak pitomej že v návrhu jazyka udělá () pro volání funkcí nepovinné, dá těm implicitním závorkám aspoň rozumnou prioritu vzhledem k ostatním operátorům.. Nebo ať aspoň print není funkce, ale statement, jak bývá (nepříliš dobrým, uznávám) zvykem.

[Hynek (Pichi) Vychodil]

Perl je velmi přátelský jazyk, ale své přátele si vybírá.

[Hynek (Pichi) Vychodil]

Jasně, já jen čekal že Perl při počítání s undef-em buď hodí výjimku (ala Python), nebo aspoň garantuje že výsledek bude zase undef (ala SQL). Ale on to vesele zkonvertuje na nulu a směje se....

Je to součástí specifikace. Co by jste chtěl, když je tvůrcem jazykovědec a ne matematik? Prostě si na to musíte zvyknnout a nebo používat něco jiného.

[Marián Kyral]

???

Perl neumím, ale když vidím ten podivný kód a výraz materializovat, tak mě taky napadlo něco podobného.

[zde]

ale funkce scalar vyhodnotí pouze výsledek poslední funkce.

Vyhodnotí se OBĚ funkce (jako skaláry), ale vrátí se jen výsledek té druhé. Zřejmě se tak Perl snaží napodobovat chování operátoru "," z C. To že tím vznikne sémantický rozdíl mezi vyhodnocováním listu (ala C) a vyhodnocováním proměnné obsahující ten identický list (ala length), je FAKT zábavné. No, ono ostatně používání scalar pro zjišťování délky listu bylo braindamaged samo o sobě, tímhle se to jen vylepšilo :)

Je nutné to pole materializovat a potom se to chová správně.

Aneb přístup když ti tvůj program v Perlu nefunguje, napiš identický algoritmus znovu, ale na víc řádků, s více dočasnými proměnnými, a s méně závorkami. :) :) :)

[Hynek (Pichi) Vychodil]

ale funkce scalar vyhodnotí pouze výsledek poslední funkce.

Vyhodnotí se OBĚ funkce (jako skaláry), ale vrátí se jen výsledek té druhé. Zřejmě se tak Perl snaží napodobovat chování operátoru "," z C. To že tím vznikne sémantický rozdíl mezi vyhodnocováním listu (ala C) a vyhodnocováním proměnné obsahující ten identický list (ala length), je FAKT zábavné.

O vašich informacích se dá z úspěchem pochybovat. (Zkráceně: kecáte.) Perl nic takového jako operátor "," z C nezná a nikdy se tak nechová. Ba právě naopak:

perl -le '$,=", "; @a = 1,2; print @a'

Je nutné to pole materializovat a potom se to chová správně.

Aneb přístup když ti tvůj program v Perlu nefunguje, napiš identický algoritmus znovu, ale na víc řádků, s více dočasnými proměnnými, a s méně závorkami. :) :) :)

Originál:

sub b {
   a($_[0]), a($_[1])
}

Řešení:

sub b {
   @{[a($_[0]), a($_[1])]}
}

Alternativní řešení:

sub b {
   my @res = (a($_[0]), a($_[1]))
}

Ani v jednom případě se počet závorek nezmenšil a jen jedna alternativa potřebuje víc proměnných. Fakt je mi vás líto, jestli programovat v Perlu opravdu musíte. Já bych s takovým trvalým rozčarováním pracovat nemohl.

[zde]

ad 1) Zkráceně: nekecám.

$ perl -le 'sub a {print shift;} print scalar (a(1), a(2), 5)'
1
2
5

ad 2) Ano, máte pravdu. Opravu lze provést i přidáním závorek, aniž by se zvyšoval počet řádků nebo pomocných proměnných.

[Hynek (Pichi) Vychodil]

ad 1) Zkráceně: nekecám.

$ perl -le 'sub a {print shift;} print scalar (a(1), a(2), 5)'
1
2
5

Beru zpět, nekecáte. Teď jsem se na to díval a fakt ten operátor má a chová se stejně jako v C, ale jen v skalárním kontextu. To jeho podivné chování se jak na potvoru projeví tak zřítka, že jsem ho dodnes úspěšně ignoroval. Jak na potvoru právě scalar to skalární chování operátoru čárky vynutí.