[32411] in Perl-Users-Digest
Perl-Users Digest, Issue: 3678 Volume: 11
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Fri Apr 27 14:09:27 2012
Date: Fri, 27 Apr 2012 11:09:08 -0700 (PDT)
From: Perl-Users Digest <Perl-Users-Request@ruby.OCE.ORST.EDU>
To: Perl-Users@ruby.OCE.ORST.EDU (Perl-Users Digest)
Perl-Users Digest Fri, 27 Apr 2012 Volume: 11 Number: 3678
Today's topics:
Re: A Design Pattern Question for Functional Programers (Greg Bacon)
Re: A Design Pattern Question for Functional Programers <xahlee@gmail.com>
Re: A Design Pattern Question for Functional Programers <tzz@lifelogs.com>
Re: delete object (Tim McDaniel)
Re: delete object <ben@morrow.me.uk>
Re: delete object <ben@morrow.me.uk>
Re: delete object <nospam.gravitalsun.antispam@hotmail.com.nospam>
Re: delete object <nospam.gravitalsun.antispam@hotmail.com.nospam>
Re: delete object <rweikusat@mssgmbh.com>
Re: delete object (Randal L. Schwartz)
Re: delete object <oneingray@gmail.com>
Re: delete object <rweikusat@mssgmbh.com>
Re: delete object <xhoster@gmail.com>
Re: delete object <ben@morrow.me.uk>
Re: delete object <rweikusat@mssgmbh.com>
John Carmack glorifying functional programing in 3k wor <xahlee@gmail.com>
Re: Why does this code works without cat ? <whynot@pozharski.name>
Re: Why does this code works without cat ? <rweikusat@mssgmbh.com>
Re: Why does this code works without cat ? <ben@morrow.me.uk>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Thu, 26 Apr 2012 15:39:44 -0500
From: gbacon@hiwaay.net (Greg Bacon)
Subject: Re: A Design Pattern Question for Functional Programers
Message-Id: <1cydncDkUcYNLwTSnZ2dnUVZ_rWdnZ2d@posted.hiwaay2>
Ted Zlatanov wrote:
: Never mind Python, even Java claims it has closures. Compared to them,
: Perl is a FP jewel.
w00t!
: IMO, the main non-FP trait in Perl is that it's an imperative language
: by design and lots of its built-in functions have side effects,
: especially on $_. That's not a bad thing, just not what you'd expect in
: an FP environment.
The claim wasn't that Perl is a functional language but that
functional idioms are comfortable in Perl.
: Also, I think proper FP languages require good
: language support for passing, manipulating, and introspecting functions.
: Perl doesn't really have that at the top level IMHO.
Please provide specific examples that demonstrate the deficiencies
you have in mind. Perl isn't Haskell, but it gets along in passing,
manipulating, and introspecting functions.
Have you seen Higher Order Perl by Mark Dominus?
http://hop.perl.plover.com/
: Beyond what's in perlfaq7 on closures... Perl has closure support, but
: not enough to make it pleasant. The way $_ is handled (you have to say
: "my $_"), for instance, is weird because $_ is the most stateful
: variable in Perl and should IMO be automatically closed over. But that
: would break a lot of code :) Also you can't be specific about which
: variables you want to include in the closure, it's all lexicals, period.
When is this distinction meaningful? With
sub generate {
my($foo,$bar,$baz) = qw/ quux potrzebie w00t /;
# ...
return sub { $foo . $_[0] . $bar };
}
the runtime closes over $foo and $bar but not $baz.
Greg
--
The one pervading evil of democracy is the tyranny of the majority, or
rather of that party, not always the majority, that succeeds, by force or
fraud, in carrying elections.
-- Lord Acton
------------------------------
Date: Thu, 26 Apr 2012 19:23:57 -0700 (PDT)
From: Xah Lee <xahlee@gmail.com>
Subject: Re: A Design Pattern Question for Functional Programers
Message-Id: <b22a91bc-17db-4071-a9f1-ab6db3e2ec08@w6g2000pbp.googlegroups.com>
On Apr 26, 1:39=A0pm, gba...@hiwaay.net (Greg Bacon) wrote:
> Ted Zlatanov wrote:
>
> : Never mind Python, even Java claims it has closures. =A0Compared to the=
m,
> : Perl is a FP jewel.
>
> w00t!
>
> : IMO, the main non-FP trait in Perl is that it's an imperative language
> : by design and lots of its built-in functions have side effects,
> : especially on $_. =A0That's not a bad thing, just not what you'd expect=
in
> : an FP environment.
>
> The claim wasn't that Perl is a functional language but that
> functional idioms are comfortable in Perl.
>
> : =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Also, I think proper FP languag=
es require good
> : language support for passing, manipulating, and introspecting functions=
.
> : Perl doesn't really have that at the top level IMHO.
>
> Please provide specific examples that demonstrate the deficiencies
> you have in mind. Perl isn't Haskell, but it gets along in passing,
> manipulating, and introspecting functions.
>
> Have you seen Higher Order Perl by Mark Dominus?
>
> http://hop.perl.plover.com/
>
> : Beyond what's in perlfaq7 on closures... =A0Perl has closure support, b=
ut
> : not enough to make it pleasant. =A0The way $_ is handled (you have to s=
ay
> : "my $_"), for instance, is weird because $_ is the most stateful
> : variable in Perl and should IMO be automatically closed over. =A0But th=
at
> : would break a lot of code :) =A0Also you can't be specific about which
> : variables you want to include in the closure, it's all lexicals, period=
.
>
> When is this distinction meaningful? With
>
> =A0 sub generate {
> =A0 =A0 my($foo,$bar,$baz) =3D qw/ quux potrzebie w00t /;
>
> =A0 =A0 # ...
>
> =A0 =A0 return sub { $foo . $_[0] . $bar };
> =A0 }
>
> the runtime closes over $foo and $bar but not $baz.
>
> Greg
functional programing in perl is like using chopsticks at McDonalds:
Best done at home.
Xah
------------------------------
Date: Fri, 27 Apr 2012 14:03:50 -0400
From: Ted Zlatanov <tzz@lifelogs.com>
Subject: Re: A Design Pattern Question for Functional Programers
Message-Id: <m2lilhvypl.fsf@lifelogs.com>
On Thu, 26 Apr 2012 15:39:44 -0500 gbacon@hiwaay.net (Greg Bacon) wrote:
GB> Ted Zlatanov wrote:
GB> : IMO, the main non-FP trait in Perl is that it's an imperative language
GB> : by design and lots of its built-in functions have side effects,
GB> : especially on $_. That's not a bad thing, just not what you'd expect in
GB> : an FP environment.
GB> The claim wasn't that Perl is a functional language but that
GB> functional idioms are comfortable in Perl.
OK. They are not, because *applying a function* was not a priority when
the language was designed, and because you must work around syntactic
inconsistencies.
GB> : Also, I think proper FP languages require good
GB> : language support for passing, manipulating, and introspecting functions.
GB> : Perl doesn't really have that at the top level IMHO.
GB> Please provide specific examples that demonstrate the deficiencies
GB> you have in mind. Perl isn't Haskell, but it gets along in passing,
GB> manipulating, and introspecting functions.
For instance, currying or partial application are not easy with an
anonymous subroutine. Function parameters are not named (it's just a
list, you do whatever you want with it). You can accomplish these
yourself or with modules, sure, but it's a stretch to call it a
comfortable situation.
GB> Have you seen Higher Order Perl by Mark Dominus?
GB> http://hop.perl.plover.com/
I wrote a review of it and recommend it highly every chance I get.
Ted
------------------------------
Date: Wed, 25 Apr 2012 20:39:49 +0000 (UTC)
From: tmcd@panix.com (Tim McDaniel)
Subject: Re: delete object
Message-Id: <jn9nel$4kj$1@reader1.panix.com>
In article <jn9j89$1v7s$1@news.ntua.gr>,
George Mpouras <nospam.gravitalsun.antispam@hotmail.com.nospam> wrote:
>Yes undef $obj is enough after all. but I would like also to free
>some memory !
I think that you did not understand the previous messages on garbage
collection. After you remove the last reference to some data, Perl
will free that memory automatically at some time. Also, unless there
is MUCH MUCH memory in an object, you should not bother to free it
yourself.
--
Tim McDaniel, tmcd@panix.com
------------------------------
Date: Wed, 25 Apr 2012 22:02:00 +0100
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: delete object
Message-Id: <8b5m69-64n1.ln1@anubis.morrow.me.uk>
Quoth Rainer Weikusat <rweikusat@mssgmbh.com>:
> Ben Morrow <ben@morrow.me.uk> writes:
> >
> > You also need DESTROY when the object has internal circular references,
> > since they won't be collected until the cycle is explicitly broken.
>
> Provided that 'an object' has the only reference to some self-referential
> structure, the DESTROY method can be used to 'break the circle' so
> that the affected objects are destroyed, too. But that's rare enough
> to be considerde coincedence.
It's not at all rare: for instance, XML::Twig has circular refs, and a
->dispose method to break them.
> > Nowadays you can often avoid this by using weakrefs, though it's not
> > always easy to pick the right ref to weaken. (This is a consequence of
> > Perl using reference counts rather than a proper garbage collector.)
>
> As a consequence of the Perl using proper garbage collection, instead
> of something designed in an academic ivory tower in order to design
> academic ivory tower problems which rarely occur in practice,
When implementing large systems, Perl's refcounting causes problems in
practice. Internally, they cause *huge* problems: a large number of bugs
in perl turn out to be caused by a refcount which got too high or too
low somewhere.
Ben
------------------------------
Date: Wed, 25 Apr 2012 21:51:12 +0100
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: delete object
Message-Id: <0n4m69-64n1.ln1@anubis.morrow.me.uk>
Quoth tmcd@panix.com:
> In article <jn9j89$1v7s$1@news.ntua.gr>,
> George Mpouras <nospam.gravitalsun.antispam@hotmail.com.nospam> wrote:
> >Yes undef $obj is enough after all. but I would like also to free
> >some memory !
>
> I think that you did not understand the previous messages on garbage
> collection. After you remove the last reference to some data, Perl
> will free that memory automatically at some time.
Perl will free it *immediately*, including calling ->DESTROY if it is
defined.
Ben
------------------------------
Date: Thu, 26 Apr 2012 00:07:43 +0300
From: "George Mpouras" <nospam.gravitalsun.antispam@hotmail.com.nospam>
Subject: Re: delete object
Message-Id: <jn9p31$2l8a$1@news.ntua.gr>
I understand about garbage collector, theory is good but practice is
different.
try this command to check memory usage by perl
watch "ps -e -orss=,args= | sort -b -k1,1n | pr -TW$COLUMNS | grep -i perl"
my @array;
push @array, $_ foreach 1 .. 20_000_000;
# if do nothing 816136 perl mem.pl
#undef @array; # with this 553996 perl mem.pl
#@array = (); # with this 816140 perl mem.pl
print "press any key to continue"; getc;
------------------------------
Date: Thu, 26 Apr 2012 00:09:09 +0300
From: "George Mpouras" <nospam.gravitalsun.antispam@hotmail.com.nospam>
Subject: Re: delete object
Message-Id: <jn9p5m$2ld7$1@news.ntua.gr>
Perl will free it *immediately*, including calling ->DESTROY if it is
defined.
while your program is running it will not free a bit
------------------------------
Date: Wed, 25 Apr 2012 22:33:20 +0100
From: Rainer Weikusat <rweikusat@mssgmbh.com>
Subject: Re: delete object
Message-Id: <87ipgnmr8f.fsf@sapphire.mobileactivedefense.com>
Ben Morrow <ben@morrow.me.uk> writes:
> Quoth Rainer Weikusat <rweikusat@mssgmbh.com>:
>> Ben Morrow <ben@morrow.me.uk> writes:
>> >
>> > You also need DESTROY when the object has internal circular references,
>> > since they won't be collected until the cycle is explicitly broken.
>>
>> Provided that 'an object' has the only reference to some self-referential
>> structure, the DESTROY method can be used to 'break the circle' so
>> that the affected objects are destroyed, too. But that's rare enough
>> to be considerde coincedence.
>
> It's not at all rare: for instance, XML::Twig has circular refs, and a
> ->dispose method to break them.
I'm writing about using Perl for real-world problems, specifically,
the real-world problems I used it for during the last 15 years or so,
and there, circular references where a rare occurence. For obvious
reasons, I can't comment on what people designed which
self-referential datastructures for what reasons when implenting 1
bazillion of 'generally useful' (aka 'generally useless') code
libraries available for download from server a.b.c.d.
>>> Nowadays you can often avoid this by using weakrefs, though it's not
>>> always easy to pick the right ref to weaken. (This is a consequence of
>>> Perl using reference counts rather than a proper garbage collector.)
>>
>> As a consequence of the Perl using proper garbage collection, instead
>> of something designed in an academic ivory tower in order to design
>> academic ivory tower problems which rarely occur in practice,
>
> When implementing large systems, Perl's refcounting causes problems in
> practice.
Problems which occur in 'large systems' are more often than not
problems occuring because of 'the large system' which should usually
rather be structured into independent components interacting with each
other. Also, the interesting question is 'what precisely is a large
system'? Eg, it is a safe assumption that a monolithic OS kernel is
necessarily a larger 'integrated system' than most sensibly designed
applications. Yet, reference counting is (and - AFAIK - has always
been) the memory management strategy of choice for kernels (BTW, the
'large system' is another classic ivory-tower fad -- if people think
they need to implement 'large systems' then they have to find a way to
solve the problems related to that. And that they *believe* to need
something in order to solve some problem they encountered [or believe
they will encounter] doesn't turn that something into a categorical
imperative).
But this is more or less an aside: I two useful properties of
referencing: It is deterministic and it can be used for all kinds of
resources, not just memory. The first one is a conditio sine qua non
for the more complicated problems I have to deal with because of the
necessity to conform to 'some kind of protocol' wrt dealing with
'external entities' such as database servers. And the second makes my
(or anyone's) life much easier because there's generally no need to
worry about explicit resource management -- an object dies as soon as
it isn't used anymore and code tearing down whatever needs to be torn
down, insofar not already included in Perl, will run automatically
whenever this happens. A third one would be that it is possible to
have live Perl objects which are temporarily not reachable from
within the program, eg, send a pointer to some object through a kernel
IPC channel to another part of the program, for instance, some
top-level event loop, and ensure that it isn't deallocated by
increasing its reference count. This can also be very convenient.
> Internally, they cause *huge* problems: a large number of bugs
> in perl turn out to be caused by a refcount which got too high or too
> low somewhere.
100% of all bugs in the perl implementation come from buggy code which
happens to be part of it. That's not exactly surprising ...
------------------------------
Date: Wed, 25 Apr 2012 15:17:06 -0700
From: merlyn@stonehenge.com (Randal L. Schwartz)
Subject: Re: delete object
Message-Id: <86aa1zwj6l.fsf@red.stonehenge.com>
>>>>> "Ben" == Ben Morrow <ben@morrow.me.uk> writes:
Ben> When implementing large systems, Perl's refcounting causes problems in
Ben> practice. Internally, they cause *huge* problems: a large number of bugs
Ben> in perl turn out to be caused by a refcount which got too high or too
Ben> low somewhere.
This is FUD. The only time you need to worry about refcounts is when
you write circular-reference data structures. And when you're doing
that, you know you are doing that.
Just keep your data as a DAG, not a willy-nilly criss-cross, and it'll
be easier to test *and* maintain.
--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<merlyn@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
Smalltalk/Perl/Unix consulting, Technical writing, Comedy, etc. etc.
See http://methodsandmessages.posterous.com/ for Smalltalk discussion
------------------------------
Date: Thu, 26 Apr 2012 16:05:20 +0700
From: Ivan Shmakov <oneingray@gmail.com>
Subject: Re: delete object
Message-Id: <86pqaueucv.fsf@gray.siamics.net>
>>>>> George Mpouras <nospam.gravitalsun.antispam@hotmail.com.nospam> writes:
> I understand about garbage collector, theory is good but practice is
> different.
> try this command to check memory usage by perl
> watch "ps -e -orss=,args= | sort -b -k1,1n | pr -TW$COLUMNS | grep -i perl"
Indeed, Perl doesn't seem to free all the space immediately.
#!/usr/bin/perl
# 1652 perl ...
BEGIN { getc; }
my @array = (1 .. (1 << 22));
# 331360 perl ...
# huh? 80 bytes per an integer?
getc;
print $#array, "\n"; # prints: 4194303
undef @array;
# 298640 perl ...
getc;
[...]
--
FSF associate member #7257
------------------------------
Date: Thu, 26 Apr 2012 17:47:16 +0100
From: Rainer Weikusat <rweikusat@mssgmbh.com>
Subject: Re: delete object
Message-Id: <87mx5ysanf.fsf@sapphire.mobileactivedefense.com>
"George Mpouras" <nospam.gravitalsun.antispam@hotmail.com.nospam>
> I understand about garbage collector, theory is good but practice is
> different.
> try this command to check memory usage by perl
> watch "ps -e -orss=,args= | sort -b -k1,1n | pr -TW$COLUMNS | grep -i perl"
In the given context, this is a nonsense-test: The resident segment
size is the amount of physical memory the kernel has presently
allocated to this process. This number is going to be smaller than or
equal the amount of virtual memory allocated to this process (code +
stack + statically allocated data + 'dynamically allocated memory',
VSZ). The latter may change if the process choses to 'shrink' the
used portion of its virtual address space, eg, by munmapping some
area/ file which was mmapped before or by lowering the 'break' (=>
brk(2), sbrk(2)). Usually, this doesn't happen because userspace
memory allocators will keep 'free' virtual memory they have already
allocated in order to reuse it for future userspace memory allocation
requests (there's no good reason for doing otherwise because, except
on pathologically configured systems ["I wanted to kill the swap
because it was there!!"], the kernel will redistribute physical memory
among itself and other processes as it sees fit/ as the need arises).
In addition to this, perl will also usually keep memory that was
already allocated for some variable attached to that variable in case
it might again be needed in future, cf
----------
use Devel::Peek;
@a = 0 .. 1000000;
@a = ();
Dump(\@a);
$s = join('', 0 .. 100000);
$s = '';
Dump(\$s);
----------
------------------------------
Date: Wed, 25 Apr 2012 21:04:29 -0700
From: Xho Jingleheimerschmidt <xhoster@gmail.com>
Subject: Re: delete object
Message-Id: <4f9a0618$0$20205$ed362ca5@nr5-q3a.newsreader.com>
On 04/25/2012 02:02 PM, Ben Morrow wrote:
>
>
> When implementing large systems, Perl's refcounting causes problems in
> practice.
While I don't doubt that that is true, I've run into more problems with
Java's garbage collector than I have with Perl's, and I've used Perl far
far more.
> Internally, they cause *huge* problems: a large number of bugs
> in perl turn out to be caused by a refcount which got too high or too
> low somewhere.
Well, I'm sure mistakes can be made in the implementation of any technique.
Xho
------------------------------
Date: Fri, 27 Apr 2012 14:51:08 +0100
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: delete object
Message-Id: <crkq69-k1p2.ln1@anubis.morrow.me.uk>
Quoth Xho Jingleheimerschmidt <xhoster@gmail.com>:
> On 04/25/2012 02:02 PM, Ben Morrow wrote:
> >
> > When implementing large systems, Perl's refcounting causes problems in
> > practice.
>
> While I don't doubt that that is true, I've run into more problems with
> Java's garbage collector than I have with Perl's, and I've used Perl far
> far more.
I wasn't comparing perl with any other specific system; in particular, I
don't have any serious experience with using Java.
> > Internally, they cause *huge* problems: a large number of bugs
> > in perl turn out to be caused by a refcount which got too high or too
> > low somewhere.
>
> Well, I'm sure mistakes can be made in the implementation of any technique.
I'm not just talking about mistakes: if that was the only issue, they'd
have been found and fixed. The problem is that perl's internal data
structures consists of a rather complicated graph of objects (well,
structs), with necessary cross-references all over the place, and with
enormously varying lifetimes. The perl core is, in fact, a good example
of a system where Randal's suggestion to just keep your data in a DAG is
not practical.
For example, a bug which was fixed in 5.14 but before that will segfault
perl, probably back as far as 5.000:
perl -MDevel::Peek -e'my $x = sub { 1 };
delete $main::{__ANON__};
Dump $x;
'
This segfaults because the sub holds a pointer to its glob, in this case
*__ANON__; but this pointer isn't refcounted, because (at least in the
named sub case) the glob also holds a pointer to the sub, so there would
be a cycle. So when the glob is removed from the symbol table, its
refcount goes to zero and it's freed, and the sub now has a pointer
pointing into freed memory. (Devel::Peek is just a convenient way to get
it to segfault straight away, rather than doing something random later.)
This has been fixed in 5.14: the fix was nontrivial, and involved
sometimes adding weakref magic to the glob (and weak refs are much
nastier to deal with in C than they are in Perl), and sometimes making
the pointer from the sub to the glob a strong ref (with an incremented
refcount). This means a flag on the sub to indicate whether it holds a
ref on the glob or not, which means all the code dealing with creating
and destroying subs needs to be checked, and all the code dealing with
moving subs in and out of the CODE slot in a glob, and...
Ben
------------------------------
Date: Fri, 27 Apr 2012 16:21:19 +0100
From: Rainer Weikusat <rweikusat@mssgmbh.com>
Subject: Re: delete object
Message-Id: <871un9fbf4.fsf@sapphire.mobileactivedefense.com>
Ben Morrow <ben@morrow.me.uk> writes:
> Quoth Xho Jingleheimerschmidt <xhoster@gmail.com>:
>> On 04/25/2012 02:02 PM, Ben Morrow wrote:
[...]
>> > Internally, they cause *huge* problems: a large number of bugs
>> > in perl turn out to be caused by a refcount which got too high or too
>> > low somewhere.
>>
>> Well, I'm sure mistakes can be made in the implementation of any technique.
>
> I'm not just talking about mistakes: if that was the only issue, they'd
> have been found and fixed. The problem is that perl's internal data
> structures consists of a rather complicated graph of objects (well,
> structs), with necessary cross-references all over the place, and with
> enormously varying lifetimes. The perl core is, in fact, a good example
> of a system where Randal's suggestion to just keep your data in a DAG is
> not practical.
Naively counting lines of code, perl 5.10.1 figures as 574,000 and the
core of Linux 2.6.36.4 (without architecture specific code and device
drivers) has 2,132,318 which is about 3.72 times the size of the
former (and the count is biased in favor of perl because it didn't
cherry-pick anything there). So, how come that something which causes
so 'huge problems' in a relatively small 'system' that some people
consider it unworkable apparently works for a much larger system which
is additionally forced to 'survive' in a signficantly less friendly
environment? Could this perhaps be an instance of some (few) people
confusing "we can't do it" with "it can't be done" (or, not entirely
unlikely "they surely won't be able to do it" with "it is impossible"?)
> For example, a bug which was fixed in 5.14 but before that will segfault
> perl, probably back as far as 5.000:
>
> perl -MDevel::Peek -e'my $x = sub { 1 };
> delete $main::{__ANON__};
> Dump $x;
> '
>
> This segfaults because the sub holds a pointer to its glob, in this case
> *__ANON__; but this pointer isn't refcounted, because (at least in the
> named sub case) the glob also holds a pointer to the sub, so there would
> be a cycle.
Nope. This isn't refcounted because this would be pointless in case of
a named sub since the glob already holds a refcounted pointer to the
sub. For obvious reasons, a mechanism designed based on the assumption
that there will always an 1:1 mapping between different kinds of
objects can't just be 'extended' to the 1:n case without changes. Why
does an anonymous sub have to have a pointer to a glob with a name in
the symbol table to begin with? Minus "this happened to be the fastest
way to tack it onto the existing code" of course? If this is a magic
glob, why is it possible to delete from Perl code? Or why isn't this
simply documented as 'the glob .... is used internally by perl and
Perl code must not delete it'? Lastly, which actually useful
functionally is provided by this example that is supposed to justify
dumping other useful functionality?
------------------------------
Date: Thu, 26 Apr 2012 19:11:06 -0700 (PDT)
From: Xah Lee <xahlee@gmail.com>
Subject: John Carmack glorifying functional programing in 3k words
Message-Id: <effa5456-4874-425f-8141-56fe82cee6d2@k10g2000pbk.googlegroups.com>
John Carmack glorifying functional programing in 3k words
http://www.altdevblogaday.com/2012/04/26/functional-programming-in-c/
where was he ten years ago?
O, and btw, i heard that Common Lispers don't do functional
programing, is that right?
Fuck Common Lispers. Yeah, fuck them. One bunch of Fuckfaces. (and
Fuck Pythoners. Python fucking idiots.)
O, don't forget,
=E3=80=88Programing: What are OOP's Jargons and Complexities (Object Orient=
ed
Program as Functional Program)=E3=80=89
http://xahlee.org/Periodic_dosage_dir/t2/oop.html
please you peruse of it.
your servant, humbly
Xah
------------------------------
Date: Thu, 26 Apr 2012 13:23:07 +0300
From: Eric Pozharski <whynot@pozharski.name>
Subject: Re: Why does this code works without cat ?
Message-Id: <slrnjpi8gb.ujg.whynot@orphan.zombinet>
with <1qal69-cbj1.ln1@anubis.morrow.me.uk> Ben Morrow wrote:
> Quoth Eric Pozharski <whynot@pozharski.name>:
*SKIP*
>> The only reason for this could be POSIX. Any reference, please?
> Well, if you insist:
*SKIP*
I have to read it around. In order to lay hands on this I have to
register, what will take some time. Maybe some kind soul would point to
some pirated copy, but I guess not.
*SKIP* [[ no reason to quote unparsable ]]
> I can't parse either of those paragraphs. In any case, this has nothing
> whatever to do with bash: this is the way shish shells have behaved
> since the Bourne shell.
Right. There's no need to implement a feature that noone uses. Noone
uses a feature because it's not implemented. zsh still wins.
--
Torvalds' goal for Linux is very simple: World Domination
Stallman's goal for GNU is even simpler: Freedom
------------------------------
Date: Thu, 26 Apr 2012 18:42:31 +0100
From: Rainer Weikusat <rweikusat@mssgmbh.com>
Subject: Re: Why does this code works without cat ?
Message-Id: <87ipgms83c.fsf@sapphire.mobileactivedefense.com>
Eric Pozharski <whynot@pozharski.name> writes:
> with <1qal69-cbj1.ln1@anubis.morrow.me.uk> Ben Morrow wrote:
>> Quoth Eric Pozharski <whynot@pozharski.name>:
> *SKIP*
>>> The only reason for this could be POSIX. Any reference, please?
>> Well, if you insist:
> *SKIP*
>
> I have to read it around. In order to lay hands on this I have to
> register, what will take some time. Maybe some kind soul would point to
> some pirated copy, but I guess not.
Since the UNIX(*) standard is available for free (except that you
have to register), I doubt that someone would want to 'pirate' it ...
------------------------------
Date: Thu, 26 Apr 2012 20:35:24 +0100
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: Why does this code works without cat ?
Message-Id: <skko69-fpe2.ln1@anubis.morrow.me.uk>
Quoth Eric Pozharski <whynot@pozharski.name>:
[ zsh's foo <bar <baz => cat bar baz | foo ]
> > I can't parse either of those paragraphs. In any case, this has nothing
> > whatever to do with bash: this is the way shish shells have behaved
> > since the Bourne shell.
>
> Right. There's no need to implement a feature that noone uses. Noone
> uses a feature because it's not implemented. zsh still wins.
It's not that it's a feature noone uses. That would be a perfectly
sensible extension. The problem is that a '</etc/group' redirection is
supposed to leave fd 0 attached to /etc/group, so the command can fstat
it, or rewind the filehandle, or whatever. Silently converting it into a
pipe, with which the command can do none of those things, is confusing.
More generally, if the extension had used syntax which was previously
invalid, like the similar N<(cmd args) extension implemented by both zsh
and bash (but not ksh), there would have been no problem. In this case,
though, the syntax chosen *was* previously valid sh syntax, so zsh's
designers should have realised someone somewhere was probably using it
with its sh meaning, and chosen something else.
Ben
------------------------------
Date: 6 Apr 2001 21:33:47 GMT (Last modified)
From: Perl-Users-Request@ruby.oce.orst.edu (Perl-Users-Digest Admin)
Subject: Digest Administrivia (Last modified: 6 Apr 01)
Message-Id: <null>
Administrivia:
To submit articles to comp.lang.perl.announce, send your article to
clpa@perl.com.
Back issues are available via anonymous ftp from
ftp://cil-www.oce.orst.edu/pub/perl/old-digests.
#For other requests pertaining to the digest, send mail to
#perl-users-request@ruby.oce.orst.edu. Do not waste your time or mine
#sending perl questions to the -request address, I don't have time to
#answer them even if I did know the answer.
------------------------------
End of Perl-Users Digest V11 Issue 3678
***************************************
