Portál AbcLinuxu, 30. dubna 2025 16:30
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]}}->()'
Tiskni
Sdílej:
@{} kamkoliv se dá.
Posledně mě vypeklo něco jako
$a = undef; $a += undef; print defined($a);
Mě v tom nutí dělat taky, jsme na stejné lodi.Myslím že ne Time
. Afaik je Perl jeho oblíbeným jazykem.
undef+undef je 0+0 a undef.undef je ''.''. Stejně jako 'text'+0 je 0 a 'text'.0 je 'text0'.
1 << 32 == 1, -1 | 1 == 4294967295 a podobné vypečenosti..
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.
Jenže takhle podivnou aritmetiku má i CéčkoTo 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.
from __future__ import division jsem nevěděl.
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).
$ 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?)
$ perl -le 'print 2*(2**31)' 4294967296 $ perl -le 'print ((2**31)*2)' 4294967296
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. 2147483648perl imho predpokladá, že ho používa rozmýšľajúce stvorenie
() 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.
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.
2.2.2007 15:21
Marián Kyral | skóre: 29
| blog: Sem_Tam
| Frýdek-Místek
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.
$ 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.
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í.
ISSN 1214-1267, (c) 1999-2007 Stickfish s.r.o.