$| (undocumented) magic?

While trying my hand at a new japh[*], I've found that $| can only
hold either 0 or 1 (I guess):

# perl -le 'print $|=10'

Though I can't seem to find any mention of this fact in 'perldoc
perlvar'. BTW: is this behaviour supposed to be supported in the
future too? And is it always been?


[*] FWIW, basically I had a piece of code like s/./1&ord$&/ge; but
then I also needed to have $|=1, and since I didn't want yet another
statement (it revealed to be more of a golfing exercise than a japhing
one) I changed it to s/./++$|&ord$&/ge; which *does* work fine, only
that, thinking of it better I realized that had $| been a "normal"
variable, it shouldn't have!


Michele
--
you'll see that it shouldn't be so. AND, the writting as usuall is
fantastic incompetent. To illustrate, i quote:
- Xah Lee trolling on clpmisc,
"perl bug File::Basename and Perl's nature"

Michele Dondi wrote:

> While trying my hand at a new japh[*], I've found that $| can only
> hold either 0 or 1 (I guess):
>
>   # perl -le 'print $|=10'

What's more interesting is the magic associated with decrementing $|:

perl -le 'print --$| for 1 .. 10'

--Ala

[posted & mailed]

On Thu, 9 Sep 2004, Michele Dondi wrote:

>While trying my hand at a new japh[*], I've found that $| can only
>hold either 0 or 1 (I guess):
>
>  # perl -le 'print $|=10'
>
>Though I can't seem to find any mention of this fact in 'perldoc
>perlvar'. BTW: is this behaviour supposed to be supported in the
>future too? And is it always been?

The C code implementing $| basically says "if the value assigned to $| is
true, have $| return 1, otherwise have it return 0".  This leads to the
ness that is

print +("this", "that")[--$|] for 1 .. 10;

--
Jeff "japhy" Pinyan         %  How can we ever be the sold short or
RPI Acacia Brother #734     %  the cheated, we who for every service
Senior Dean, Fall 2004    %  have long ago been overpaid?
RPI Corporation Secretary   %
http://japhy.perlmonk.org/  %    -- Meister Eckhart

On Thu, 09 Sep 2004 22:12:59 GMT, Ala Qumsieh <notvalid@email.com>
wrote:
 
>
>What's more interesting is the magic associated with decrementing $|:
>
>	perl -le 'print --$| for 1 .. 10'

I know, I've done some experiments myself, "obviously"! ;-) As Jeff
"japhy" Pinyan pointed out, it's really magic associated with the
underlying code implementing $|.


Michele
--
you'll see that it shouldn't be so. AND, the writting as usuall is
fantastic incompetent. To illustrate, i quote:
- Xah Lee trolling on clpmisc,
"perl bug File::Basename and Perl's nature"

On Fri, 10 Sep 2004 00:57:20 -0400, Jeff 'japhy' Pinyan
<pinyaj@rpi.edu> wrote:

>[posted & mailed]

Don't!


Michele
--
you'll see that it shouldn't be so. AND, the writting as usuall is
fantastic incompetent. To illustrate, i quote:
- Xah Lee trolling on clpmisc,
"perl bug File::Basename and Perl's nature"

On Fri, 10 Sep 2004 00:57:20 -0400, Jeff 'japhy' Pinyan
<pinyaj@rpi.edu> wrote:

>The C code implementing $| basically says "if the value assigned to $| is
>true, have $| return 1, otherwise have it return 0".  This leads to the

(Having not seen the actual code, and not being to) I *think* that
basically it should say "if the result of an assignment is true then
actually store 1 in it, otherwise store 0 in it". Isn't this closer?
Thank you for the kind explanation, anyway...


Michele
--
 {$_=pack'B8'x25,unpack'A8'x32,$a^=sub{po
p^pop}->(map substr
(($a||=join'',map--$|x$_,(unpack'w',unpack'u','G^<R<Y]*YB='
.'KYU;*EVH[.FHF2W+#"\Z*5TI/ER<Z`S(G.DZZ9OX0Z')=~/./g)x2,$_,
256),7,249);s/[^\w,]/ /g;$ \=/^J/?$/:"\r";print,redo}#JAPH,

On Fri, 10 Sep 2004, Michele Dondi wrote:

>On Fri, 10 Sep 2004 00:57:20 -0400, Jeff 'japhy' Pinyan
><pinyaj@rpi.edu> wrote:
> 
>
>(Having not seen the actual code, and not being to) I *think* that
>basically it should say "if the result of an assignment is true then
>actually store 1 in it, otherwise store 0 in it". Isn't this closer?
>Thank you for the kind explanation, anyway...

Nothing is ever "stored" in $|, just like nothing is ever "stored" in a
tied variable.  $| is like a tied variable, but on an internal level.
When you set $| to a true value, the internals turn off buffering for the
currently selected filehandle, and when you read $|'s value, Perl checks
to see if the currently selected filehandle has buffering on or off.  $|
is just a placeholder.

--
Jeff "japhy" Pinyan         %  How can we ever be the sold short or
RPI Acacia Brother #734     %  the cheated, we who for every service
Senior Dean, Fall 2004    %  have long ago been overpaid?
RPI Corporation Secretary   %
http://japhy.perlmonk.org/  %    -- Meister Eckhart

On Sat, 11 Sep 2004 09:53:04 -0400, Jeff 'japhy' Pinyan
<pinyaj@rpi.edu> wrote:
 
>
>Nothing is ever "stored" in $|, just like nothing is ever "stored" in a
>tied variable.  $| is like a tied variable, but on an internal level.
>When you set $| to a true value, the internals turn off buffering for the
>currently selected filehandle, and when you read $|'s value, Perl checks
>to see if the currently selected filehandle has buffering on or off.  $|
>is just a placeholder.

I don't want to argue on this particular topic, especially since I
guess we both know what we're talking about, and I'm still thanking
you for your knowledgeable explanation. However it's obvious that even
if technically "nothing is ever stored" in $|, it maintains a
knowledge of its current status, which is what I meant...


Respectfully thanking you once again,
Michele
--
 {$_=pack'B8'x25,unpack'A8'x32,$a^=sub{po
p^pop}->(map substr
(($a||=join'',map--$|x$_,(unpack'w',unpack'u','G^<R<Y]*YB='
.'KYU;*EVH[.FHF2W+#"\Z*5TI/ER<Z`S(G.DZZ9OX0Z')=~/./g)x2,$_,
256),7,249);s/[^\w,]/ /g;$ \=/^J/?$/:"\r";print,redo}#JAPH,

Michele Dondi <bik.mido@tiscalinet.it> wrote in message news:<udb1k01b574opq7l9pv82501se3m0
ef308@4ax.com>...
> While trying my hand at a new japh[*],

Why why and why?
Do something productive...useful...

> On Fri, 10 Sep 2004 00:57:20 -0400, Jeff 'japhy' Pinyan
> <pinyaj@rpi.edu> wrote:
> 

Michele Dondi <bik.mido@tiscalinet.it> wrote in message news:<un74k0t9g74s1askdo1meu4uad0eu
cmr6q@4ax.com>...
>
> (Having not seen the actual code, and not being to) I
> *think* that basically it should say "if the result of
> an assignment is true then actually store 1 in it,
> otherwise store 0 in it". Isn't this closer?


Forgive me for bringing this up one more time, Michele.  I've been
thinking about this, and it seems to me that $| may have been
implemented to return 1 (if true) in order to behave like a boolean
variable.  This would be an advantage when comparing to boolean
variables, like in this example:

Say that both $| and $a are booleans.  $| was set to 5, and $a was
set to 1.  If you compare them with the == operator, should it
evaluate to true or false?  In other words, should the following code
print "True"?:

$| = 5;
$a = 1;
print "True"  if $| == $a;

If you're comparing their boolean states (whether they are both
true or both false), then yes, it should print true.  But if you're
comparing actual numerical values, then they should print false.  In
this case, it prints "True" because of that quirk you found with $|,
which may have been deliberately put in to make $| behave as if it
only had true/false states.  If it weren't for this feature, you could
compare $| and $a's boolean states another way with "not" and "xor,"
like this:

print "True"  if not ($| xor $a);

I happen to think that the '==' operator is more readable.
Unfortunately, in order to use '==' for boolean comparisons you have
to know which variables behave like booleans and which don't.

-- Jean-Luc