Re: Match operator giving unexpected output

Hello ysreenu, and welcome to the Monastery!

First, when scalar is applied to an array, it returns the number of elements in the array. But when scalar is applied to a list, it returns the last element in that list:

16:12 >perl -wE "say scalar('a', 'e', 'i', 'o', 'u');"
Useless use of a constant ("a") in void context at -e line 1.
Useless use of a constant ("e") in void context at -e line 1.
Useless use of a constant ("i") in void context at -e line 1.
Useless use of a constant ("o") in void context at -e line 1.
u
16:13 >
[download]

Second, calling m/.../g in scalar context finds one match only, and advances the pointer to the next position in the string following the last match. So your two calls in Phase-2 eat up the first two occurrences of “ink” in the string. Then in Phase-3, since the pointer has not been reset, the call to m/.../g in list context finds only the remaining matches, which is why you get 4 and not 6.

Update: See “Global matching” in Using regular expressions in Perl.

Hope that helps,

Athanasius <°(((>< contra mundum Iustus alius egestas vitae, eros Piratica,

Comment on Re: Match operator giving unexpected output Select or Download Code

Replies are listed 'Best First'.
Re^2: Match operator giving unexpected output by LanX (Saint) on Jan 13, 2015 at 11:22 UTC
> when scalar is applied to a list, Here "list" is to be read as comma separated (literal) list. (see scalar comma separator) Sorry for nitpicking but there is too much confusion. .. Cheers Rolf PS: Je suis Charlie!	[reply]
Re^3: Match operator giving unexpected output by Anonymous Monk on Jan 13, 2015 at 11:53 UTC
LanX> when scalar is applied to a list, Here "list" is to be read as comma separated (literal) list. (see scalar comma separator) Sorry for nitpicking but there is too much confusion. . What confusion where (where is the confusion)? And how is this distinction important? In this case? Read more... (1062 Bytes) I think its unimportant , esp in this case, a distinction without a difference ... list literal or literal list is not even in perlglossary A different demo of the "null list" ## a literal list in list context $ perl -le " print( qw/ a b c d / )" abcd ## a literal list in scalar context $ perl -le " print( scalar qw/ a b c d / )" d ## a literal list in lvalue list context ## a literal list in list context ( the left hand side list also hap +pens to be an lvalue) ## a literal list in list assignment (list context ) $ perl -le " print( ( $q ) = qw/ a b c d / )" a ## null list in scalar context counts, counting a list literal $ perl -le " print( $q = () = qw/ a b c d / )" 4 ## null list in scalar context counts, counting a "list" $ perl -le " @f = qw/ a b c d /; print( $q = () = @f )" 4 ## null list in scalar context counts $ perl -le " print( scalar( () = qw/ a b c d / ) )" 4 ## null list in list context discards (using literal list) $ perl -le " print( () = qw/ a b c d / )" ## null list in list context discards (the array kind of list ) $ perl -le " @f = qw/ a b c d /; print( () = @f )" [download]	[reply] [d/l] [select]
Re^4: Match operator giving unexpected output by LanX (Saint) on Jan 13, 2015 at 12:02 UTC
> What confusion where (where is the confusion)? in the following you (could) see a flattened "list", but scalar doesn't return the last element, which should be 5. `DB<118> @a=(4,5) => (4, 5) DB<119> scalar (1,2,3,@a) => 2` [download] in reality there is only the scalar comma operator returning the scalar of the last expression, which is here the size of @a. Cheers Rolf PS: Je suis Charlie!	[reply] [d/l]
Re^5: Match operator giving unexpected output by Anonymous Monk on Jan 13, 2015 at 23:29 UTC
Re^6: Match operator giving unexpected output by Anonymous Monk on Jan 13, 2015 at 23:32 UTC
Some notes below your chosen depth have not been shown here
Re^2: Match operator giving unexpected output by ysreenu (Initiate) on Jan 13, 2015 at 09:28 UTC
Hi Athanasius, Thanks for the clarification. My doubt arises from this statement from phase-3 of the quoted program @cnt_arr = $string =~ /ink/g; I though the content of left operand ($string) is not changed, so on which pointer =~ operator is working on? I got the answer for resetting pointer from the link suggested by you. pos($string)=0; just before phase-3 would do the job. On another note, this behavior looks to C strtok() standard library function which updates an internal pointer that is not exposed but called should keep track of it!	[reply]