PERL Miscellaneous - $| (undocumented) magic?

Author

$| (undocumented) magic?

Michele Dondi

2004-09-09, 8:56 pm

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"

Ala Qumsieh

2004-09-09, 8:56 pm

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

Jeff 'japhy' Pinyan

2004-09-10, 3:58 am

[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

Michele Dondi

2004-09-10, 4:00 pm

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"

Michele Dondi

2004-09-10, 4:00 pm

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"

Michele Dondi

2004-09-10, 8:56 pm

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,

Jeff 'japhy' Pinyan

2004-09-11, 3:56 pm

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

Michele Dondi

2004-09-11, 8:56 pm

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,

krakle

2004-09-14, 3:56 am

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

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

J. Romano

2004-09-14, 3:58 pm

> 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:<un74k0t9g74s1askdo1meu4uad0eucmr6q@4ax.com>...[color=darkred]
>
> (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

Ron Parker

2004-09-14, 3:58 pm

On 14 Sep 2004 07:40:16 -0700, J. Romano wrote:
> Unfortunately, in order to use '==' for boolean comparisons you have
> to know which variables behave like booleans and which don't.

if (!$a == !$b) {...}

--
#local R=<7084844682857967,0787982,826975826580>;#macro L(P)concat(#while(P)chr(
mod(P,100)),#local P=P/100;#end"")#end background{rgb 1}text{ttf L(R.x)L(R.y)0,0
translate<-.8,0,-1>}text{ttf L(R.x)L(R.z)0,0translate<-1.6,-.75,-1>}sphere{z/9e3
4/26/2001finish{reflection 1}}//ron.parker@povray.org My opinions, nobody else's

Anno Siegel

2004-09-14, 3:58 pm

J. Romano <jl_post@hotmail.com> wrote in comp.lang.perl.misc:
>
> Michele Dondi <bik.mido@tiscalinet.it> wrote in message
> news:<un74k0t9g74s1askdo1meu4uad0eucmr6q@4ax.com>...
>
>
> 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.

Well, it *is* a boolean variable. The state of a filehandle is either
auto-flushing or not, so it wouldn't make much sense to have $| return
values other that 0 and 1.

> 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.

Comparison of boolean variables is rare. The only case that comes up
with some regularity is the newbie mistake of writing "if ( $x == 1 )"
for "if ( $x )" and "if ( $x == 0 )" for "if ( not $x )". It is a
mistake because it brings in all the difficulties of boolean comparison
that you have correctly analyzed.

Otherwise, it just doesn't happen all that often that you want to do
one thing if both $a and $b are true, and the same thing when they
are both false, but something else if one is true and the other isn't.
If it happens, I'll try to bring in negation at one point, which
normalizes the value of booleans, so comparison with "==" is valid.

Anno

Michele Dondi

2004-09-14, 8:57 pm

On 13 Sep 2004 21:16:37 -0700, krakle@visto.com (krakle) wrote:

>
>Why why and why?

Fun?!? Fun, Fun and more Fun?

>Do something productive...useful...

You may think what you want, but IMHO spending some time on JAPHs,
golf et similia is an aid to improve one's programming skills also in
"productive" code.

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

2004-09-14, 8:57 pm

On 14 Sep 2004 07:40:16 -0700, jl_post@hotmail.com (J. Romano) wrote:

> 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:

Forgive me for this answer that most likely won't satisfy you,
Jean-Luc. I've been thinking about this, and it seems to me that $|
may have been implemented that way to help me finding the final form
for my most recent JAPH: in the original one I used $| for a
completely different purpose[1] and I had C<($"=~$")>[2] in place of
C<--$|>. This was because I was convinced that I necessarily had to
use a string =~ /^[\0\xFF]+$/ for a certain purpose, whereas I later
realized /^[01]+$/ would have been just good.

[1] That included as a nice side effect to leave $|==1 at print()
time, unlike now. And _I_M_H_O_ that is the current JAPH's *only*
defect in that it clobbers the "\r" effect at least, say, in Linux
console which is definitely too fast for it to be evident (but xterm &
C. and M$-DOS console under Win all seem to work just fine...)

[2] Along with either C<$"|=$"> or C<$"&=$">, according to some
condition I won't mention here, somewhere near the beginning of the
script.

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,

Abigail

2004-09-14, 8:57 pm

Anno Siegel (anno4000@lublin.zrz.tu-berlin.de) wrote on MMMMXXXII
September MCMXCIII in <URL:news:ci73es$b63$1@mamenchi.zrz.TU-Berlin.DE>:
... J. Romano <jl_post@hotmail.com> wrote in comp.lang.perl.misc:
... >
... > 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.
...
... Well, it *is* a boolean variable. The state of a filehandle is either
... auto-flushing or not, so it wouldn't make much sense to have $| return
... values other that 0 and 1.

Well, $* is also a boolean variable - but you can assign (almost) anything
to it. $^W acts more like $| though.

Abigail
--
perl -MLWP::UserAgent -MHTML::TreeBuilder -MHTML::FormatText -wle'print +(
HTML::FormatText -> new -> format (HTML::TreeBuilder -> new -> parse (
LWP::UserAgent -> new -> request (HTTP::Request -> new ("GET",
"http://work.ucsd.edu:5141/cgi-bin/http_webster?isindex=perl")) -> content))
=~ /(.*\))[-\s]+Addition/s) [0]'

Sherm Pendley

2004-09-14, 8:57 pm

Michele Dondi wrote:

> You may think what you want, but IMHO spending some time on JAPHs,
> golf et similia is an aid to improve one's programming skills also in
> "productive" code.

Yeah, but what you practice is what you do by habit later. Do you
*really* want JAPH-style code to appear in production scripts?

Also, JAPHs as sigs tend to give a bad impression of the language to
those who've never seen any other Perl. They promote the idea of an
insular community that delights in writing obscure code that's difficult
for newbies and outsiders to grok.

sherm--

--
Cocoa programming in Perl: http://camelbones.sourceforge.net
Hire me! My resume: http://www.dot-app.org

Anno Siegel

2004-09-14, 8:57 pm

Abigail <abigail@abigail.nl> wrote in comp.lang.perl.misc:
> Anno Siegel (anno4000@lublin.zrz.tu-berlin.de) wrote on MMMMXXXII
> September MCMXCIII in <URL:news:ci73es$b63$1@mamenchi.zrz.TU-Berlin.DE>:
> .. J. Romano <jl_post@hotmail.com> wrote in comp.lang.perl.misc:
> .. >
> .. > 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.
> ..
> .. Well, it *is* a boolean variable. The state of a filehandle is either
> .. auto-flushing or not, so it wouldn't make much sense to have $| return
> .. values other that 0 and 1.
>
>
> Well, $* is also a boolean variable - but you can assign (almost) anything
> to it. $^W acts more like $| though.

Yikes, I had blissfully forgotten about $*. It even respects an overloaded
boolean -- not something I'd expect $| or $^W to do. That's one more
inconsistency in Perl, though rarely noticed.

Anno

Michael Slass

2004-09-14, 8:57 pm

Sherm Pendley <spamtrap@dot-app.org> writes:

>Also, JAPHs as sigs tend to give a bad impression of the language to those
>who've never seen any other Perl. They promote the idea of an insular
>community that delights in writing obscure code that's difficult for
>newbies and outsiders to grok.
>

Isn't that the whole point of a JAPH --- to show how clever the owner
is at writing obscure perl --- and for the puzzle-solving amusement
of the rest of us, figuring out how/why a particular JAPH works?
--
Mike Slass

Anno Siegel

2004-09-15, 8:59 am

Michael Slass <miknrene@drizzle.com> wrote in comp.lang.perl.misc:
> Sherm Pendley <spamtrap@dot-app.org> writes:
>
>
> Isn't that the whole point of a JAPH --- to show how clever the owner
> is at writing obscure perl --- and for the puzzle-solving amusement
> of the rest of us, figuring out how/why a particular JAPH works?

A japh doesn't *have* to be obfuscated. It is _just another_ way
to print that particular string from four lines of sig.

Anno

Michele Dondi

2004-09-15, 3:59 pm

On Tue, 14 Sep 2004 18:43:03 -0400, Sherm Pendley
<spamtrap@dot-app.org> wrote:

>
>Yeah, but what you practice is what you do by habit later. Do you
>*really* want JAPH-style code to appear in production scripts?

Not at all, and I don't think I do that. Nor do I think others,
including well known JAPH writers/golfers, do.

>Also, JAPHs as sigs tend to give a bad impression of the language to
>those who've never seen any other Perl. They promote the idea of an
>insular community that delights in writing obscure code that's difficult
>for newbies and outsiders to grok.

This is true, though. I must admit it! But it won't stop me from
writing some, every now and again, I guess...

BTW: I've never ever sit down thinking to myself: well, now I'm making
a JAPH. It's always come out of something different. Well, sort of...

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

2004-09-15, 3:59 pm

On Tue, 14 Sep 2004 16:32:12 -0700, Michael Slass
<miknrene@drizzle.com> wrote:

>Isn't that the whole point of a JAPH --- to show how clever the owner
>is at writing obscure perl --- and for the puzzle-solving amusement
>of the rest of us, figuring out how/why a particular JAPH works?

Not at all: it's not necessarily an obfuscation thing. Not necessarily
in the sense of *code* obfuscation: some times it has to do with
*data* obfuscation. And some times it's not about obfuscation at all,
but it's focused on some witty/

/whatever way to print that
particular string. Think of Abigail's magnificent ones, for example:
often you *do* understand where the data are stored and you can even
grasp more or less what the code does. But you're amazed at *how* it
does it. And in some cases you wonder why the program compiles at all!

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,

J. Romano

2004-09-15, 3:59 pm

> On 14 Sep 2004 07:40:16 -0700, jl_post@hotmail.com (J. Romano) wrote:
>

Michele Dondi <bik.mido@tiscalinet.it> replied in message
news:<jckek09ghen8j4r7e76aeevs0rpcohtq9r@4ax.com>...[color=darkred]
>
> Forgive me for this answer that most likely won't
> satisfy you, Jean-Luc. I've been thinking about this,
> and it seems to me that $| may have been implemented
> that way to help me finding the final form for my most
> recent JAPH

I'm not sure if your reply was meant to be taken as sarcasm, but
either way... good for you! It's always good to learn something new
when creating new JAPHs!

-- Jean-Luc

Ala Qumsieh

2004-09-15, 3:59 pm

Sherm Pendley wrote:

> Michele Dondi wrote:
>
>
>
> Yeah, but what you practice is what you do by habit later. Do you
> *really* want JAPH-style code to appear in production scripts?

No, but that doesn't mean that JAPHs and golf promote "bad" habits
(whatever the definition of "bad" might be). I have never spent too much
time on JAPHs, but have done so on perlgolf (over at perlgolf.org during
its earlier days). And, I must admit, I learnt lots of useful techniques
and discovered a lot of interesting properties of Perl's built-in vars
in the process of squeezing just one more character out of my code. As a
matter of fact, I learnt about $|--'s magic when one person used it in
his golf code to alternate between two elements, while everyone else
used some variation of ++$i%2. It was exciting and very insightful to
figure those things out.

I take all of this as a form of edutainment and don't allow it into
production code. Afterall, watching a violent movie doesn't make a
(normal ;) person want to go out on a rampage.

> Also, JAPHs as sigs tend to give a bad impression of the language to
> those who've never seen any other Perl. They promote the idea of an
> insular community that delights in writing obscure code that's difficult
> for newbies and outsiders to grok.

They're just jealous because they can't write any valid Python program
in just four lines (/me ducks and runs for cover).

--Ala

Joe Smith

2004-09-16, 5:01 am

Michele Dondi wrote:

>
>
> 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...

linux% perl -MDevel::P

-e '$a=2;Dump $a'
SV = IV(0x8139674) at 0x8139b80
REFCNT = 1
FLAGS = (IOK,pIOK)
IV = 2

linux% perl -MDevel::P

-e '$|=2;Dump $|'
SV = PVMG(0x8154fc8) at 0x8139b80
REFCNT = 1
FLAGS = (GMG,SMG,pIOK)
IV = 2
NV = 0
PV = 0
MAGIC = 0x813b028
MG_VIRTUAL = &PL_vtbl_sv
MG_TYPE = PERL_MAGIC_sv(\0)
MG_OBJ = 0x8139bd4
MG_LEN = 1
MG_PTR = 0x813bc68 "|"

linux% perldoc perlguts | grep -i magic

-Joe

T. Ogawa

2004-09-16, 5:01 am

Ala Qumsieh <notvalid@email.com> wrote in message news:<B1_1d.21323$7W3.102@newssvr29.news.prodigy.com>...
> Sherm Pendley wrote:
>
> They're just jealous because they can't write any valid Python program
> in just four lines (/me ducks and runs for cover).
Well we can't write _any_ valid program in four lines, but we can
manage a JAPy or 30. Some of them are even unreadable.

http://www.python.org/cgi-bin/moinm...notherPythoneer

-T.

krakle

2004-09-16, 8:38 pm

Michele Dondi <bik.mido@tiscalinet.it> wrote in message news:<f8kek09p6h3v9j3v069dra66t8qj66dkuh@4ax.com>...
> On 13 Sep 2004 21:16:37 -0700, krakle@visto.com (krakle) wrote:
>
>
> Fun?!? Fun, Fun and more Fun?
>

If that's your idea of a fun time I feel bad for your
wife/husband/girlfriend/children/friends/co-workers...

krakle

2004-09-16, 8:38 pm

hydroxide@inorbit.com (T. Ogawa) wrote in message news:<da01153a.0409160033.79797da0@posting.google.com>...
> Ala Qumsieh <notvalid@email.com> wrote in message news:<B1_1d.21323$7W3.102@newssvr29.news.prodigy.com>...
> Well we can't write _any_ valid program in four lines

#!/usr/bin/perl -w
print "What's your name?";
my $name = <STDIN>;
print "Hi $name I just wanted to show you a valid Perl program in 4
lines. Isnt this valid?\n";

Michele Dondi

2004-09-16, 8:38 pm

On 15 Sep 2004 08:08:47 -0700, jl_post@hotmail.com (J. Romano) wrote:

> I'm not sure if your reply was meant to be taken as sarcasm, but
>either way... good for you! It's always good to learn something new

Wasn't it clear enough? ;-)
No offence intended, of course!

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

2004-09-16, 8:38 pm

On Wed, 15 Sep 2004 16:25:05 GMT, Ala Qumsieh <notvalid@email.com>
wrote:

>No, but that doesn't mean that JAPHs and golf promote "bad" habits
>(whatever the definition of "bad" might be). I have never spent too much
>time on JAPHs, but have done so on perlgolf (over at perlgolf.org during
>its earlier days). And, I must admit, I learnt lots of useful techniques
>and discovered a lot of interesting properties of Perl's built-in vars
>in the process of squeezing just one more character out of my code. As a

Indeed! Personally I'm only a mediocre golfer, but I have an IMHO
enlightening example: in a contest at terje the goal was a program
that given any input string would output the *smallest* palindrome
obtained extending that string either on the left or on the right.

(I must say that I have tried my own hand at that contest, when
closed, and taking much time: had I actually took part to it I would
have classified at 4th place IIRC. The point is, anyway, that I chose
an approach similar to that of most other ones.)

The actual winner instead had taken a completely different path, and
as a result he did win not for a hole or two, but for something like
30 or more! Basically he was |'ing the given string with a reverse()d
copy of it "shifted left or right" an increasing amount of chars until
it matched the original string.

I remember I was amazed when I saw *that* solution: the algorithm was
conceptually the most simple of all. Then he did other "awful" things
in order to squeeze the very last byte off his script, like using
symrefs (and in a possibly obscure way!) et similia. Of course one
shouldn't/wouldn't do such things in "production code", but if for any
reason he had to realize that particular task, then an excellent
technique could be the one described above.

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

2004-09-16, 8:38 pm

On 16 Sep 2004 09:16:49 -0700, krakle@visto.com (krakle) wrote:

^^^^^^
^^^^^^
[color=darkred]
>
>#!/usr/bin/perl -w
>print "What's your name?";
>my $name = <STDIN>;
>print "Hi $name I just wanted to show you a valid Perl program in 4
>lines. Isnt this valid?\n";

It seems you don't waste your time with JAPHs, because you only spend
your efforts in "productive code", but just at the same time this must
have caused you some comprehension problems e.g. with understanding
what the OP was talking about, i.e. *Python* programs, not *Perl*.

Oh, and BTW, since you only spend your time on "productive code", then
you surely know that (i) -w is somewhat obsolete since C<use warnings>
provides the same functionality in a better and more controlled way,
(ii) it is a bad habit to include literal newlines in strings unless
when writing a japh or when golfing, which is not your case, since you
don't do those things. Also (iii) it may be a deliberate choice, but
wouldn't it be better to chomp($name)?

I'd just write:

#!/usr/bin/perl -l

use strict;
use warnings;

print "What's your name?";
chomp(my $name = <> );
print <<"EOT";
Hi $name I just wanted to show you a valid Perl program in 4
lines. Isn't this valid?
EOT

__END__

Oh, but I was forgetting... you wanted to exhibit a valid program in 4
lines! I'm an idiot!! But then not only there are many *valid*
programs even in one line (and useful too!), but there is even *one*
(and there couldn't be more!) *valid* program in zero lines:

# perl -e ''

And you know what? It' even warnings- and strict-safe:

# perl -wMstrict -e ''

HTH,
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

2004-09-16, 8:38 pm

On 16 Sep 2004 09:10:40 -0700, krakle@visto.com (krakle) wrote:

>
>If that's your idea of a fun time I feel bad for your
>wife/husband/girlfriend/children/friends/co-workers...

Well, I know it's hard to believe, but surprising as it may be, you'll
find that I do *not* spend all my time writing JAPHs, let alone most
of it or even a considerable part of it. And I don't think I've said
so, but if I have...

Michele

Eric Schwartz

2004-09-16, 8:38 pm

Michele Dondi <bik.mido@tiscalinet.it> writes:
> It seems you don't waste your time with JAPHs, because you only spend
> your efforts in "productive code", but just at the same time this must
> have caused you some comprehension problems e.g. with understanding
> what the OP was talking about, i.e. *Python* programs, not *Perl*.

I believe the OP was simply pointing out that you can only write
*some* programs in four lines; you can't write *any* program in 4
lines, because some won't fit.

Of course, Perl and Ruby (and I think Python, though I'm not sure) let
you put multiple statements on a line, so I suppose technically you
could just join(';', split(/\n/, <FILE> )) and call that a 'line'. :)

-=Eric
--
Come to think of it, there are already a million monkeys on a million
typewriters, and Usenet is NOTHING like Shakespeare.
-- Blair Houghton.

krakle

2004-09-17, 4:02 am

Michele Dondi <bik.mido@tiscalinet.it> wrote in message news:<ecvjk09um3jll6gi82pmnug1qegeuo2q23@4ax.com>...
> On 16 Sep 2004 09:16:49 -0700, krakle@visto.com (krakle) wrote:
>
> ^^^^^^
> ^^^^^^
>
>
> It seems you don't waste your time with JAPHs, because you only spend
> your efforts in "productive code"

My point: Programs can be written in 4 lines of code. The rest of your
post was ignored.

Michele Dondi

2004-09-17, 8:58 pm

On Thu, 16 Sep 2004 15:47:54 -0600, Eric Schwartz <emschwar@pobox.com>
wrote:

>
>I believe the OP was simply pointing out that you can only write
>*some* programs in four lines; you can't write *any* program in 4
>lines, because some won't fit.

I *do* know what the OP was talking about. And I don't think I've
written anything your last cmt could possibly apply to. But maybe I
didn't express myself clearly, since I'm not a native English speaker.

I think you don't have clear the context of what's going on. To
summarize things up:

On Wed, 15 Sep 2004 16:25:05 GMT, Ala Qumsieh <notvalid@email.com>
*jokingly* wrote:

>
>They're just jealous because they can't write any valid Python program
^^^^^^
>in just four lines (/me ducks and runs for cover).

To which

On 16 Sep 2004 01:33:05 -0700, hydroxide@inorbit.com (T. Ogawa) wrote
(still jokingly):

>Well we can't write _any_ valid program in four lines, but we can
^^
>manage a JAPy or 30. Some of them are even unreadable.
^^^^
>http://www.python.org/cgi-bin/moinm...notherPythoneer
^^^^^^

From which it is clear that *we* refers implicitly to "us Python
programmers". Doesn't it?

And then in reply

On 16 Sep 2004 09:16:49 -0700, krakle@visto.com (krakle) wrote
(*intendedly* jokingly):

>#!/usr/bin/perl -w
>print "What's your name?";
>my $name = <STDIN>;
>print "Hi $name I just wanted to show you a valid Perl program in 4
>lines. Isnt this valid?\n";

And I'm contending that his wannabe-joke is misplaced for we *all*
know here that we can write valid *Perl* programs in 0..4 and more
lines, including Ala Qumsieh and T. Ogawa. It was a joke about
*Python*, because...

>Of course, Perl and Ruby (and I think Python, though I'm not sure) let
>you put multiple statements on a line, so I suppose technically you

....(even if I don't know Python in detail myself, it is well known
that) Python, differently from Perl and many other languages is not a
"free form language", i.e. whitespace is mostly significant in it and
a correct indentation is enforced as part of the syntax of the
language.

Said this, I may have seamlessly skipped over this "mistake". Instead
I've deliberately made an ad hominem attack on "krakle" because it
made me upset to read what I judge to be an idiot's cmt from him, and
in the form of a badly written perl program, whereas from what he
wrote previously I got the idea that he must think he's such a smart
guy. It was not fair of me, I must admit it!

I just couldn't resist the temptation for I can't stand arrogant
superficial people...

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

2004-09-17, 8:58 pm

On 16 Sep 2004 21:48:53 -0700, krakle@visto.com (krakle) wrote:

>
>My point: Programs can be written in 4 lines of code. The rest of your
>post was ignored.

I bet it was! Thank you so much for having informed us all that
"programs can be written in 4 lines of code". I can't imagine where we
could be without your contribution!

Said this... *plonk!*

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,

krakle

2004-09-17, 8:58 pm

Michele Dondi <bik.mido@tiscalinet.it> wrote in message news:<60olk0d79evnjqgkb8rcegha97bvfv09iv@4ax.com>...
> On 16 Sep 2004 21:48:53 -0700, krakle@visto.com (krakle) wrote:
>
>
> Thank you so much for having informed us all that
> "programs can be written in 4 lines of code". I can't imagine where we
> could be without your contribution!

Michele, Not sure why you are taking offense to any of my replies.. It
was in response to T. Ogawas "we can't write _any_ valid program in
four lines". Ofcourse you can... So hostile in here...

Jeff 'japhy' Pinyan

2004-09-17, 8:58 pm

On 17 Sep 2004, krakle wrote:

>Michele Dondi <bik.mido@tiscalinet.it> wrote in message news:<60olk0d79evnjqgkb8rcegha97bvfv09iv@4ax.com>...
>
>Michele, Not sure why you are taking offense to any of my replies.. It
>was in response to T. Ogawas "we can't write _any_ valid program in
>four lines". Ofcourse you can... So hostile in here...

I think Ogawas meant "any" as "every", that is: "we can't write _every_
valid program".

--
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

Tad McClellan

2004-09-18, 3:56 am

Michele Dondi <bik.mido@tiscalinet.it> wrote:

> I'm an idiot!!

I think you have misidentified who the idiot is in this thread...

--
Tad McClellan SGML consulting
tadmc@augustmail.com Perl programming
Fort Worth, Texas

krakle

2004-09-19, 3:56 am

Jeff 'japhy' Pinyan <pinyaj@rpi.edu> wrote in message news:<Pine.SGI.3.96.1040917201725.66659A-100000@vcmr-64.server.rpi.edu>...
> On 17 Sep 2004, krakle wrote:
>
>
> I think Ogawas meant "any" as "every", that is: "we can't write _every_
> valid program".

Alrighty then.

? the Platypus {aka David Formosa}

2004-09-30, 8:57 pm

anno4000@lublin.zrz.tu-berlin.de (Anno Siegel) writes:

[...]

> Otherwise, it just doesn't happen all that often that you want to do
> one thing if both $a and $b are true, and the same thing when they
> are both false, but something else if one is true and the other
> isn't. If it happens, I'll try to bring in negation at one point, which
> normalizes the value of booleans, so comparison with "==" is valid.

I would use something like not ($a xor $b) which should have the same effect.

--
Please excuse my spelling as I suffer from agraphia. See
http://dformosa.zeta.org.au/~dformosa/Spelling.html to find out more.
Free the Memes.

Sponsored Links