Re: [Boston.pm] Perl 6 has become too complex
I would like to take this chance to also mention that Steve posted a similar discussion node on the Perl Monks website, and I mentioned this thread to TheDamian, and he asked that I post the link to that thread. http://www.perlmonks.org/index.pl?node_id=243089 Thomas Stanley aka TStanley on PerlMonks - Original Message - From: Elaine -HFB- Ashton Sent: Saturday, March 15, 2003 2:23 AM To: Tolkin, Steve Cc: [EMAIL PROTECTED] Subject: Re: [Boston.pm] Perl 6 has become too complex Tolkin, Steve [EMAIL PROTECTED] quoth:*>I think I am in the same camp as Chris Nandor and John Tobey.*>They, and I, have just given up on Perl 6.*>*>But there is a problem in staying with Perl 5.*>Due to Perl 6 the Perl 5 community is deprived of the *>resources of several key people, e.g. Larry, and also "Good Damian".My problem with perl6 is several more years of having to endure hearingpeople grump about that which does not exist. I feel badly for thoseseveral key people, as you call them, as it seems like freaks just can'tresist the urge to voice discontent. You are all like children who cry atchristmastime because santa brought something you didn't ask for. *>The original design of perl was simple. *>I learned Perl 4 from its man page -- yes there*>was one long man page that completely described the entire language. *>Apocalyse 6 included almost 30 pages discussing the new ==>*>and <== operators! This is not a good sign.I don't think perl5 is going anywhere Steve, so get your pants out of atwist. I have it on very good authority that p6 was the best thing thatever happened to p5p as it drew the whiners and the talkers all over tothe p6 lists leaving the doers to get down to business. P6 may never cometo fruition but for that one particular benefit I am particularlygrateful as it made Jarkko's job much much easier.I will suggest you read "The Power of Babel" as it's an excellent story onthe development of language which you may or may not appreciate in thiscontext.e.___Boston-pm mailing list[EMAIL PROTECTED]http://mail.pm.org/mailman/listinfo/boston-pmGet more from the Web. FREE MSN Explorer download : http://explorer.msn.com
Re: [Boston.pm] Perl 6 has become too complex
On Sat, Mar 15, 2003 at 10:53:53AM -0500, Andrew Pimlott wrote:
> On Fri, Mar 14, 2003 at 09:59:42PM -0500, Uri Guttman wrote:
> > well, this is what will be supported which is named nested subs.
> > it looks to be compiled but callable only from within the outer sub and
> > it has access to the outer subs vars.
> >
> > my $c;
> > sub foo() {
> > my $a;
> > my $b;
> >
> > my sub bar() {
> > $b = $a + $c;
> > }
> >
> > bar();
> > }
> >
> > is that close enough?
>
> I think it's absolutely fine, assuming that &bar is a real closure
> that can be returned or passed to other functions. I think nested
> subs should default to "my", since there's no other point in using
> them, but if Larry likes the "my", it can stay.
I agree with your preference, but I wish it worked without the "my".
See Apache::Registry. (I hope that's the one I mean.) It packages a
whole CGI script in a sub by textually inserting it in "sub {" "}".
This trick would be quite useful if not for the "will not stay shared"
issue, aka the "all named subs are global" problem.
See Scheme do it right:
http://www.schemers.org/Documents/Standards/R5RS/HTML/r5rs-Z-H-8.html#%_sec_5.2.2
Personally, I would never intentionally write a nested sub in current
versions of Perl. Apart from having global subs pasted into an outer
block by something like Apache::Registry, what good does the current
nested sub feature do? Of course, some code somewhere relies on them
being global, but not Apache::Registry, which I believe also pastes a
generated package declaration around its scripts in order to defeat
the global-ness.
Share and share alike! :~)
--
John Tobey <[EMAIL PROTECTED]>
\^-^
/\ /\
___
Boston-pm mailing list
[EMAIL PROTECTED]
http://mail.pm.org/mailman/listinfo/boston-pm
Re: [Boston.pm] Perl 6 has become too complex
On Sat, Mar 15, 2003 at 12:19:18PM -0500, Uri Guttman wrote:
> > "AP" == Andrew Pimlott <[EMAIL PROTECTED]> writes:
>
> AP> On Fri, Mar 14, 2003 at 09:59:42PM -0500, Uri Guttman wrote:
> >>
> >> my $c;
> >> sub foo() {
> >> my $a;
> >> my $b;
> >>
> >> my sub bar() {
> >> $b = $a + $c;
> >> }
> >>
> >> bar();
> >> }
> >>
> >> is that close enough?
>
> AP> I think it's absolutely fine, assuming that &bar is a real closure
> AP> that can be returned or passed to other functions. I think nested
> AP> subs should default to "my", since there's no other point in using
> AP> them, but if Larry likes the "my", it can stay.
>
> i don't see why you would want to return a named closure when you can
> return an anon one.
Well, why not? What if I want to call it and return/pass it? I
guess that's not all that common, though.
> the implication (to me) of a named one is that it
> can be called inside foo() directly and it has access to foo() variables
> on the stack. those vars are not copied to a private pad for bar() like
> a anon closure would do. they are different animals IMO.
Suppose I do return/pass it, what will it do? It has to have some
behavior, and the only alternatives I see to closure are utterly
confusing and error-prone. If perl6diag contains the text "will not
stay shared", I will be quite sad.
The very idea of "two kinds of closure" seems confusing.
If you are worried about efficiency, there is a simple optimization:
If no reference is ever taken to the named lexical sub, it doesn't
need it's own copy of the pad.
> AP> ... well, just to be sure, here are a couple test cases:
>
> AP> my foo() {
> AP> my sub helper1() { ... helper2() ... $a ...}
> AP> my sub helper2() { ... helper1() ... $a ...}
> AP> my $a;
> AP> helper1();
> AP> }
>
> AP> helper1 and helper2 should be mutually recursive and enclose $a, ie
> AP> when compiling helper1 it shouldn't bind helper2() and $a to
> AP> whatever's in the outer/global scope.
>
> you don't return a sub there rather you made a call to it. so it is not
> the same as p5 closures. that should work fine but it doesn't need pads
> and local copies of $a in helper1/2().
ok.
> also that can be done with a plain block surrounding two subs. no need for
> nesting subs there. show me a case where you need named nesting subs and
> you return one of them to the outside.
>
> AP> my foo() {
> AP> ... helper() ...
> AP> my $a;
> AP> my sub helper { ... $a ... }
> AP> }
>
> AP> The call to helper() should work and $a should be enclosed (of
> AP> course, it will be undef when helper() is called, but helper can set
> AP> it). It's often nice to put the helpers at the end--and note that
> AP> this cannot be achieved with the Perl 5 glob trick.
>
> this is a compiler issue as to whether it can handle foward
> references. if you declared helper with a signature first (of course
> inside foo()), it would work for sure. i am not sure otherwise.
Right. I just think that since Perl can normally handle forward
references, it should be able to do so in this case.
> my point is that nested named subs are supported but they are not the
> same as anon closures returned from an outer sub. but who knows what
> larry would want there. i will ask on p6l.
Thanks.
Andrew
___
Boston-pm mailing list
[EMAIL PROTECTED]
http://mail.pm.org/mailman/listinfo/boston-pm
Re: [Boston.pm] Perl 6 has become too complex
> "AP" == Andrew Pimlott <[EMAIL PROTECTED]> writes:
AP> On Fri, Mar 14, 2003 at 09:59:42PM -0500, Uri Guttman wrote:
>>
>> my $c;
>> sub foo() {
>> my $a;
>> my $b;
>>
>> my sub bar() {
>> $b = $a + $c;
>> }
>>
>> bar();
>> }
>>
>> is that close enough?
AP> I think it's absolutely fine, assuming that &bar is a real closure
AP> that can be returned or passed to other functions. I think nested
AP> subs should default to "my", since there's no other point in using
AP> them, but if Larry likes the "my", it can stay.
i don't see why you would want to return a named closure when you can
return an anon one. the implication (to me) of a named one is that it
can be called inside foo() directly and it has access to foo() variables
on the stack. those vars are not copied to a private pad for bar() like
a anon closure would do. they are different animals IMO.
AP> ... well, just to be sure, here are a couple test cases:
AP> my foo() {
AP> my sub helper1() { ... helper2() ... $a ...}
AP> my sub helper2() { ... helper1() ... $a ...}
AP> my $a;
AP> helper1();
AP> }
AP> helper1 and helper2 should be mutually recursive and enclose $a, ie
AP> when compiling helper1 it shouldn't bind helper2() and $a to
AP> whatever's in the outer/global scope.
you don't return a sub there rather you made a call to it. so it is not
the same as p5 closures. that should work fine but it doesn't need pads
and local copies of $a in helper1/2().
also that can be done with a plain block surrounding two subs. no need for
nesting subs there. show me a case where you need named nesting subs and
you return one of them to the outside.
AP> my foo() {
AP> ... helper() ...
AP> my $a;
AP> my sub helper { ... $a ... }
AP> }
AP> The call to helper() should work and $a should be enclosed (of
AP> course, it will be undef when helper() is called, but helper can set
AP> it). It's often nice to put the helpers at the end--and note that
AP> this cannot be achieved with the Perl 5 glob trick.
this is a compiler issue as to whether it can handle foward
references. if you declared helper with a signature first (of course
inside foo()), it would work for sure. i am not sure otherwise.
my point is that nested named subs are supported but they are not the
same as anon closures returned from an outer sub. but who knows what
larry would want there. i will ask on p6l.
uri
--
Uri Guttman -- [EMAIL PROTECTED] http://www.stemsystems.com
- Stem and Perl Development, Systems Architecture, Design and Coding
Search or Offer Perl Jobs http://jobs.perl.org
Damian Conway Perl Classes - January 2003 -- http://www.stemsystems.com/class
___
Boston-pm mailing list
[EMAIL PROTECTED]
http://mail.pm.org/mailman/listinfo/boston-pm
RE: [Boston.pm] Perl 6 has become too complex
At 11:53 -0500 2003.03.15, Wizard wrote: >I don't view it as a problem, and I didn't mean to imply that I thought >Perl5 would be any sort of second-string language, only that it may very >well become relegated to tasks other than a production language. OK, you and I must have very different definitions of "second-string language," because you appear to have defined it as exactly that. Either way, its adherents will not see it as you describe, and asserting views like this will only serve to damage the community. Keep it up if you will. -- Chris Nandor [EMAIL PROTECTED]http://pudge.net/ Open Source Development Network[EMAIL PROTECTED] http://osdn.com/ ___ Boston-pm mailing list [EMAIL PROTECTED] http://mail.pm.org/mailman/listinfo/boston-pm
RE: [Boston.pm] Perl 6 has become too complex
> This somewhat misses my point. The lack of migration of many users should > not be viewed as a problem, necessarily, but as a difference of opinion, a > choice. The widespread view that people who stick with Perl 5 will be > sticking with an old, crufty, slow, backward, legacy language is the very > sort of thing that will help to ruin the Perl community. I don't view it as a problem, and I didn't mean to imply that I thought Perl5 would be any sort of second-string language, only that it may very well become relegated to tasks other than a production language. This might be along the same lines as C in comparison to C++. I still use C and suspect that I will still use Perl5. I also use much of the supported C 'subset' when using C++, and suspect that the same will hold true of the Perl5 'subset' (Yes, I know that neither is truly a subset, but for lack of a better term). Grant M. ___ Boston-pm mailing list [EMAIL PROTECTED] http://mail.pm.org/mailman/listinfo/boston-pm
Re: [Boston.pm] Perl 6 has become too complex
On Fri, Mar 14, 2003 at 09:59:42PM -0500, Uri Guttman wrote:
> well, this is what will be supported which is named nested subs.
> it looks to be compiled but callable only from within the outer sub and
> it has access to the outer subs vars.
>
> my $c;
> sub foo() {
> my $a;
> my $b;
>
> my sub bar() {
> $b = $a + $c;
> }
>
> bar();
> }
>
> is that close enough?
I think it's absolutely fine, assuming that &bar is a real closure
that can be returned or passed to other functions. I think nested
subs should default to "my", since there's no other point in using
them, but if Larry likes the "my", it can stay.
A6 implied to me that this would not be the case, because it only
used the word "closure" in connection with anonymous subs. But if
you can assure me that the above will work, I can sleep peacefully.
... well, just to be sure, here are a couple test cases:
my foo() {
my sub helper1() { ... helper2() ... $a ...}
my sub helper2() { ... helper1() ... $a ...}
my $a;
helper1();
}
helper1 and helper2 should be mutually recursive and enclose $a, ie
when compiling helper1 it shouldn't bind helper2() and $a to
whatever's in the outer/global scope.
my foo() {
... helper() ...
my $a;
my sub helper { ... $a ... }
}
The call to helper() should work and $a should be enclosed (of
course, it will be undef when helper() is called, but helper can set
it). It's often nice to put the helpers at the end--and note that
this cannot be achieved with the Perl 5 glob trick.
Andrew
___
Boston-pm mailing list
[EMAIL PROTECTED]
http://mail.pm.org/mailman/listinfo/boston-pm
RE: [Boston.pm] Perl 6 has become too complex
At 08:35 -0500 2003.03.15, Wizard wrote: >This is a similar problem to what Apache2 has had. Apache2 is definitely a >superior product, but is so different from 1 that the adoption rate has been >somewhat slow. What the Perl6 developers need to do is to make sure that the >migration is as simple as possible, with tools, tutorials and hand-holding. >Like any other new product, it has to be sold. Just remember, there are >still large numbers of entities still happily using Cobol (a legacy language >when I was a lad in the early 80s ;-). This somewhat misses my point. The lack of migration of many users should not be viewed as a problem, necessarily, but as a difference of opinion, a choice. The widespread view that people who stick with Perl 5 will be sticking with an old, crufty, slow, backward, legacy language is the very sort of thing that will help to ruin the Perl community. -- Chris Nandor [EMAIL PROTECTED]http://pudge.net/ Open Source Development Network[EMAIL PROTECTED] http://osdn.com/ ___ Boston-pm mailing list [EMAIL PROTECTED] http://mail.pm.org/mailman/listinfo/boston-pm
Re: [Boston.pm] Perl 6 has become too complex
On Saturday, March 15, 2003, at 10:11 AM, Mikey Smelto wrote: You forgot to mention that we will all have to deal with suggesting perl5 to project managers/decision makers(read: people who don't understand anything) as a language of choice for projects of the future, and explain to them why we don't want to use the newest version of the language, and having the perl5 solution rejected because the company doesn't want to use old||legacy||non-cutting-edge software going forward. Hm. I think this can't be generalized upon. Where I work, they are still using Perl 5.005 on the production servers (for our internal site) Erik -- Erik Price email: [EMAIL PROTECTED] jabber: [EMAIL PROTECTED] ___ Boston-pm mailing list [EMAIL PROTECTED] http://mail.pm.org/mailman/listinfo/boston-pm
Re: [Boston.pm] Perl 6 has become too complex
You forgot to mention that we will all have to deal with suggesting perl5 to project managers/decision makers(read: people who don't understand anything) as a language of choice for projects of the future, and explain to them why we don't want to use the newest version of the language, and having the perl5 solution rejected because the company doesn't want to use old||legacy||non-cutting-edge software going forward. My only real concern is that when Perl 6 comes out, the community will be fractured, and we -- you, me, Larry, Damian -- will need to work to minimize the damage, for the benefit of Perl 5 and Perl 6 users. We will need to deal with CPAN/PAUSE/RT/search, we will need to deal with IRC and PerlMonks and use Perl; we will need to deal with Usenet; we will need to deal with TPJ and TPR and YAPC and TPC and Perl Mongers. I see the users of both -- and make no mistake, Perl 5 will retain a large user base for a long time, composed of people who have no intention of using Perl 6 -- only being harmed by significant fracturing of the "Perl community." _ The new MSN 8: advanced junk mail protection and 2 months FREE* http://join.msn.com/?page=features/junkmail ___ Boston-pm mailing list [EMAIL PROTECTED] http://mail.pm.org/mailman/listinfo/boston-pm
RE: [Boston.pm] Perl 6 has become too complex
> My only real concern is that when Perl 6 comes out, the community will be > fractured, and we -- you, me, Larry, Damian -- will need to work to > minimize the damage, for the benefit of Perl 5 and Perl 6 users. We will > need to deal with CPAN/PAUSE/RT/search, we will need to deal with IRC and > PerlMonks and use Perl; we will need to deal with Usenet; we will need to > deal with TPJ and TPR and YAPC and TPC and Perl Mongers. I see the users > of both -- and make no mistake, Perl 5 will retain a large user base for a > long time, composed of people who have no intention of using Perl > 6 -- only > being harmed by significant fracturing of the "Perl community." This is a similar problem to what Apache2 has had. Apache2 is definitely a superior product, but is so different from 1 that the adoption rate has been somewhat slow. What the Perl6 developers need to do is to make sure that the migration is as simple as possible, with tools, tutorials and hand-holding. Like any other new product, it has to be sold. Just remember, there are still large numbers of entities still happily using Cobol (a legacy language when I was a lad in the early 80s ;-). Grant M. ___ Boston-pm mailing list [EMAIL PROTECTED] http://mail.pm.org/mailman/listinfo/boston-pm
Re: [Boston.pm] Perl 6 has become too complex
At 18:36 -0500 2003.03.14, Andrew Pimlott wrote: >On Fri, Mar 14, 2003 at 06:00:59PM -0500, Tolkin, Steve wrote: >> I think I am in the same camp as Chris Nandor and John Tobey. >> They, and I, have just given up on Perl 6. > >I would say don't give up. Unless you need it within the next >couple years, in which case, ok, give up. But if you're thinking >long term, have some faith in Larry, Damian, and the other guys who >are smart, creative, and apparently working together really well >together (unusual in Perl's history!). I would agree in that I would not say I have given up; I have merely stopped caring. I reserve the right to care again some day, but I lack optimism. And since I hate being pessimistic, rather than optimistic, I choose to note care, instead. :) Also, despite my distaste for much of what is being said about what Perl 6 will be, I do not wish to discourage anyone else, including and especially the people designing it, and those who wish to help them. I only say I have distaste for it to encourage those who feel similarly, to let them know it is OK to not like it. But really, Elaine is right IMO: dislike it if you wish -- Larry is certainly mature and smart enough to know that people have preferences and that all the Perl users won't like Perl 6 by default! -- but don't gripe. At the very least, realize that if you love Perl 5, it isn't going away. It might lose Larry and Damian, but honestly, Larry has not not done a lot for the design or maintenance of the Perl 5 language in years, and Damian -- while making cool stuff -- contributed more in his ideas than in any other way, and those ideas will still be coming, I guarantee, only to be implemented in Perl 5 for those who want it. That is to say, I am influenced more by Damian's ideas than I use his actual code. Yes, Perl 5 has and will lose people. But it also has a lot of good people that it won't likely lose, and it will probably gain more "key" people as others step up to the plate. I am not trying to dismiss all the other "key" people like Larry and Damian have done, but just trying to keep things in perspective. My only real concern is that when Perl 6 comes out, the community will be fractured, and we -- you, me, Larry, Damian -- will need to work to minimize the damage, for the benefit of Perl 5 and Perl 6 users. We will need to deal with CPAN/PAUSE/RT/search, we will need to deal with IRC and PerlMonks and use Perl; we will need to deal with Usenet; we will need to deal with TPJ and TPR and YAPC and TPC and Perl Mongers. I see the users of both -- and make no mistake, Perl 5 will retain a large user base for a long time, composed of people who have no intention of using Perl 6 -- only being harmed by significant fracturing of the "Perl community." But, that is some time off, so I won't dwell on it; I just like to point this problem out so people can think about it a bit now, to try to lessen the problem later. Prophecy is not meant to make people panic, but to help them see the future signs that they might respond more appropriately, with a greater sense of understanding, when the time comes. ;-) -- Chris Nandor [EMAIL PROTECTED]http://pudge.net/ Open Source Development Network[EMAIL PROTECTED] http://osdn.com/ ___ Boston-pm mailing list [EMAIL PROTECTED] http://mail.pm.org/mailman/listinfo/boston-pm
