[32894] in Perl-Users-Digest
Perl-Users Digest, Issue: 4172 Volume: 11
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Fri Mar 14 14:09:28 2014
Date: Fri, 14 Mar 2014 11:09:03 -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, 14 Mar 2014 Volume: 11 Number: 4172
Today's topics:
Re: How did PHP and Python take over such a huge market <tzz@lifelogs.com>
Re: How did PHP and Python take over such a huge market <tzz@lifelogs.com>
Re: How did PHP and Python take over such a huge market <rweikusat@mobileactivedefense.com>
Re: How did PHP and Python take over such a huge market <john@castleamber.com>
Re: How did PHP and Python take over such a huge market <kaz@kylheku.com>
Re: How did PHP and Python take over such a huge market <hjp-usenet3@hjp.at>
Re: How did PHP and Python take over such a huge market <kaz@kylheku.com>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Thu, 13 Mar 2014 12:06:16 -0400
From: Ted Zlatanov <tzz@lifelogs.com>
Subject: Re: How did PHP and Python take over such a huge market-share of Perl?
Message-Id: <8738im84nb.fsf@lifelogs.com>
On Wed, 12 Mar 2014 19:35:23 +0000 Rainer Weikusat <rweikusat@mobileactivedefense.com> wrote:
RW> George Mpouras <gravitalsun@hotmail.foo> writes:
RW> [...]
>> Also about AI , from my point of view the "eval" function and the
>> ability of subroutines to return code brings Perl very close to lisp
RW> One major drawback of Perl compared to Lisp is that there's no
RW> structured representation of Perl code: The only way to generate new
RW> code at run time is to build 'Perl source code strings' and run them
RW> through eval. For the same reason, Perl doesn't have a powerful macro
RW> factility like Lisp.
The term is "homoiconic." Perl has a structured representation, but
you can't turn it back into Perl, that's the missing piece.
Ted
------------------------------
Date: Thu, 13 Mar 2014 13:38:56 -0400
From: Ted Zlatanov <tzz@lifelogs.com>
Subject: Re: How did PHP and Python take over such a huge market-share of Perl?
Message-Id: <87r4666lsf.fsf@lifelogs.com>
On Thu, 13 Mar 2014 16:59:53 +0000 (UTC) Kaz Kylheku <kaz@kylheku.com> wrote:
KK> Anyway, a macro facility for Perl would be somewhat pointless because macros
KK> are geared toward compiling.
KK> Since Perl is basically uncompilable, you might as well go with what mainstream
KK> Lisp discarded decades ago: "fexprs".
I agree, as far as is needed to stop the hypothesizing about Perl macros.
My main purpose was to specify the technical term so Rainer can Google
it and write a long argument in response.
Ted
------------------------------
Date: Thu, 13 Mar 2014 21:37:05 +0000
From: Rainer Weikusat <rweikusat@mobileactivedefense.com>
Subject: Re: How did PHP and Python take over such a huge market-share of Perl?
Message-Id: <87pplppypq.fsf@sable.mobileactivedefense.com>
Ted Zlatanov <tzz@lifelogs.com> writes:
> On Wed, 12 Mar 2014 19:35:23 +0000 Rainer Weikusat <rweikusat@mobileactivedefense.com> wrote:
>
> RW> George Mpouras <gravitalsun@hotmail.foo> writes:
> RW> [...]
>
>>> Also about AI , from my point of view the "eval" function and the
>>> ability of subroutines to return code brings Perl very close to lisp
>
> RW> One major drawback of Perl compared to Lisp is that there's no
> RW> structured representation of Perl code: The only way to generate new
> RW> code at run time is to build 'Perl source code strings' and run them
> RW> through eval. For the same reason, Perl doesn't have a powerful macro
> RW> factility like Lisp.
>
> The term is "homoiconic." Perl has a structured representation, but
> you can't turn it back into Perl, that's the missing piece.
There's an internal representation of a Perl program which is used for
executing it but Perl code cannot easily access that (according to the
documentation, some sort of read-only access is available via B), let
alone manipulate it or create something like it (this would require
interpreting/ generating 'C pointers' valid for the current Perl
process).
Being able to turn the optree back into Perl wouldn't be terribly useful
for this as this would require an artifical perl-ness in order to make
sense of it.
Sideline joke: http://www.perlprojects.org (found via Google).
I knew there was more to it than just getting stuff done.
------------------------------
Date: Thu, 13 Mar 2014 17:19:48 -0600
From: John Bokma <john@castleamber.com>
Subject: Re: How did PHP and Python take over such a huge market-share of Perl?
Message-Id: <871ty5wusr.fsf@castleamber.com>
Rainer Weikusat <rweikusat@mobileactivedefense.com> writes:
> Sideline joke: http://www.perlprojects.org (found via Google).
Wouldn't it be funny if a few people actually showed up at the
PERL Collective Workgroup Meeting in Sligo, Ireland expecting to hack
some Perl :-D.
--
John Bokma j3b
Blog: http://johnbokma.com/ Perl Consultancy: http://castleamber.com/
Perl for books: http://johnbokma.com/perl/help-in-exchange-for-books.html
------------------------------
Date: Thu, 13 Mar 2014 16:59:53 +0000 (UTC)
From: Kaz Kylheku <kaz@kylheku.com>
Subject: Re: How did PHP and Python take over such a huge market-share of Perl?
Message-Id: <20140313094828.850@kylheku.com>
On 2014-03-13, Ted Zlatanov <tzz@lifelogs.com> wrote:
> On Wed, 12 Mar 2014 19:35:23 +0000 Rainer Weikusat <rweikusat@mobileactivedefense.com> wrote:
>
> RW> George Mpouras <gravitalsun@hotmail.foo> writes:
> RW> [...]
>
>>> Also about AI , from my point of view the "eval" function and the
>>> ability of subroutines to return code brings Perl very close to lisp
>
> RW> One major drawback of Perl compared to Lisp is that there's no
> RW> structured representation of Perl code: The only way to generate new
> RW> code at run time is to build 'Perl source code strings' and run them
> RW> through eval. For the same reason, Perl doesn't have a powerful macro
> RW> factility like Lisp.
>
> The term is "homoiconic." Perl has a structured representation, but
> you can't turn it back into Perl, that's the missing piece.
There are so many missing pieces, none of them is "the".
Anyway, a macro facility for Perl would be somewhat pointless because macros
are geared toward compiling.
Since Perl is basically uncompilable, you might as well go with what mainstream
Lisp discarded decades ago: "fexprs".
If macros are considered to be compilers, fexprs are their interpretive
counterpart: user-defined operator functions that, at run time (not
macro-expansion time) receive the unevaluated versions of their arguments,
along with the caller's environment. They do whatever is necessary to make
their construct happen, each time they are called.
For example, a fexpr version of the let operator would grok the variable
bindings, extend the handed-down environment with them, and then call eval
over the forms enclosed by let, with the extended environment.
Tcl implements a version of this obsolete approach.
With fexprs you need some reasonable API to be able to peer into the pieces of
program you have been handed down and parse out things, but you don't a way to
re-assemble a syntactically correct piece of code that can be visualized in the
original source language.
------------------------------
Date: Thu, 13 Mar 2014 20:53:45 +0100
From: "Peter J. Holzer" <hjp-usenet3@hjp.at>
Subject: Re: How did PHP and Python take over such a huge market-share of Perl?
Message-Id: <slrnli4369.8lc.hjp-usenet3@hrunkner.hjp.at>
On 2014-03-13 16:59, Kaz Kylheku <kaz@kylheku.com> wrote:
> Anyway, a macro facility for Perl would be somewhat pointless because macros
> are geared toward compiling.
>
> Since Perl is basically uncompilable,
Perl is compiled.
hp
--
_ | Peter J. Holzer | Fluch der elektronischen Textverarbeitung:
|_|_) | | Man feilt solange an seinen Text um, bis
| | | hjp@hjp.at | die Satzbestandteile des Satzes nicht mehr
__/ | http://www.hjp.at/ | zusammenpaßt. -- Ralph Babel
------------------------------
Date: Thu, 13 Mar 2014 20:43:58 +0000 (UTC)
From: Kaz Kylheku <kaz@kylheku.com>
Subject: Re: How did PHP and Python take over such a huge market-share of Perl?
Message-Id: <20140313133553.534@kylheku.com>
On 2014-03-13, Peter J. Holzer <hjp-usenet3@hjp.at> wrote:
> On 2014-03-13 16:59, Kaz Kylheku <kaz@kylheku.com> wrote:
>> Anyway, a macro facility for Perl would be somewhat pointless because macros
>> are geared toward compiling.
>>
>> Since Perl is basically uncompilable,
>
> Perl is compiled.
Perl5 is "compiled".
------------------------------
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 4172
***************************************
