Re: [Boston.pm] Perl 6 has become too complex
On Monday, March 17, 2003 16:32 -0500 Dan Sugalski <[EMAIL PROTECTED]> wrote: At 4:24 PM -0500 3/17/03, [EMAIL PROTECTED] wrote: Just because they're putting something into perl 6 that doesn't help you get your job done, doesn't mean that they're doing it simply for an ego trip. For the record, redesigning an existing product lots of people both love and hate has been about as good for my ego as, say, swimsuit modelling would be. Unless Larry or Damian are closet masochists, I expect it's been about as much of an ego stroke for them, too. -- Woudl now be a good time for all those of us who think you're doing a great job - or at least don't think you're as unto the barbarians sacking Rome - to gather round and stroke your collective egos? I used to be a naysayer until Damian talked about things at YAPC::E and cleared up a lot of misconceptions I had. OK, so I'm not about to become a perl6 fanboy, but I am at least willing to withhold my criticisms until there's something to criticise! And if, once it's out, I decide that perl6 sucks syphilitic donkey nads, I'll still have perl5. Hell, I'll still have perl4 for some things. And awk. -- David Cantrell ___ Boston-pm mailing list [EMAIL PROTECTED] http://mail.pm.org/mailman/listinfo/boston-pm
Re: [Boston.pm] Perl 6 has become too complex
At 01:29 PM 3/18/2003 -0600, Elaine -HFB- Ashton wrote: And if it's any comfort to you I hear they have a special cousel in an grumpy 80 year-old man :) I feel better already, Thanks. Is it Mel Brooks or Carl Reiner? I think I'll have a nectarine ... Charlie ___ Boston-pm mailing list [EMAIL PROTECTED] http://mail.pm.org/mailman/listinfo/boston-pm
RE: [Boston.pm] Perl 6 has become too complex
OK, I'll bite. Who? > -Original Message- > From: Elaine -HFB- Ashton [mailto:[EMAIL PROTECTED] > Sent: Tuesday, March 18, 2003 2:30 PM ... > And if it's any comfort to you I hear they have a special cousel in an > grumpy 80 year-old man :) Hopefully helpfully yours, Steve -- Steven Tolkin [EMAIL PROTECTED] 617-563-0516 Fidelity Investments 82 Devonshire St. V4D Boston MA 02109 There is nothing so practical as a good theory. Comments are by me, not Fidelity Investments, its subsidiaries or affiliates. ___ Boston-pm mailing list [EMAIL PROTECTED] http://mail.pm.org/mailman/listinfo/boston-pm
Re: [Boston.pm] Perl 6 has become too complex
At 01:03 AM 3/18/2003 -0600, Elaine -HFB- Ashton wrote: Joe Johnston [EMAIL PROTECTED] quoth: *> *>Do you trust Larry and Damain? I wish they'd just stop circulating the Apocs so widely as every time Larry emits one there is a rash of people who think the world has needed to know or cares that it's not what they wanted or needed to use. It's the typical egocentric universe that tends to plague us even now in the dot.bomb. It's less about trust than of wanking. I hope that you are right. But, if the history of C++ is any guide, it is better to holler early and often in favor of simplicity. The C++ committee clearly suffered what I call "rapture of the deep" and foisted many complex and not particularly useful features on an unwitting C++ community. The result: there are almost no conforming compilers available. Sophisticated features are still best avoided due to portability problems. The C++ committee has, in fact, done a lot to deprecate C++ use and bring about a renaissance, of sorts, in C development. I am not making this up. Due to it's single implementation, Perl should be spared the worst. But, for that same reason, the advanced features could well weigh down the language as a whole in both interpretation and execution speed. Reliability is also an important issue. Perl is used in a great many production systems. Perl is already a bit crufty in the sense that there are many "accidental features". If the degrees-of-freedom supported by the language grows significantly, you can bet there will be many new and interesting side effects that will appear in the language. This may be a good thing, depending on your POV. But, to me, it is a source of fragility, both in the language itself and in programs written in it. Complexity is easy. Simplicity is damned difficult. I know and trust that the Perl language designers and developers all know this fact very well. But it doesn't hurt to remind them sometimes. My guess is that the kind of nattering that bothers you so much is exactly why Larry _does_ publish the "Apocalypsos". That, and he probably is sincere in his desire for a transparent process. take it easy, Charlie ___ Boston-pm mailing list [EMAIL PROTECTED] http://mail.pm.org/mailman/listinfo/boston-pm
Re: [Boston.pm] Perl 6 has become too complex
Dan Sugalski wrote: > > At 10:30 AM -0500 3/18/03, [EMAIL PROTECTED] wrote: > >Erik Price wrote: > >> linguistic scholars have noticed that > >> throughout human history, there has > >> always been a trend of languages > >> diverging, rather than converging > > > >awk, sed, and a mish-mash of useful > >functionality converging into Perl > >would be a counter-example. > > While computer and human languages share many traits, > they aren't the same thing by any means. they (computer and human languages) are considered fairly equally in the eyes of the law. both allow expressions that qualify for copyright protection. They are different in that while a human expression can only describe patentable functionality, a computer program can both describe and implement the functionality. Human languages can give purely functional expressions too. Food recipes can't be copyrighted because they're considered purely functional. (You can copyright a cookbook if you put in cutesy little stories that go with the recipes.) But it takes a human to parse, compile, and execute the recipe "program". Generally, the argument used to defend software cracks is that code is protected by freedom of speech, whereas execution of said code to spread a computer virus is illegal. This is the same argument that protects the Anarchist's Cookbook as freedom of speech, separating the difference between expressing knowledge about a topic and using that knowledge to perform illegal acts. Greg ___ Boston-pm mailing list [EMAIL PROTECTED] http://mail.pm.org/mailman/listinfo/boston-pm
Re: [Boston.pm] Perl 6 has become too complex
At 10:30 AM -0500 3/18/03, [EMAIL PROTECTED] wrote: Erik Price wrote: linguistic scholars have noticed that throughout human history, there has always been a trend of languages diverging, rather than converging awk, sed, and a mish-mash of useful functionality converging into Perl would be a counter-example. I don't know that it's safe to make that counter-example. While computer and human languages share many traits, they aren't the same thing by any means. -- Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk ___ Boston-pm mailing list [EMAIL PROTECTED] http://mail.pm.org/mailman/listinfo/boston-pm
Re: [Boston.pm] Perl 6 has become too complex
Erik Price wrote: > linguistic scholars have noticed that > throughout human history, there has > always been a trend of languages > diverging, rather than converging awk, sed, and a mish-mash of useful functionality converging into Perl would be a counter-example. The fear seems to be that Perl 6 will FORK from Perl 5 (diverge). I think that Perl 6 will EXPAND perl 5. Sure, you'll have to learn some new syntactical stuff, but Perl 5 will only have a subset of the functionality that will be in perl 6. Greg I hate war as only a soldier who has lived it can, only as one who has seen its brutality, its futility, its stupidity. -- Dwight D. Eisenhower ___ Boston-pm mailing list [EMAIL PROTECTED] http://mail.pm.org/mailman/listinfo/boston-pm
Re: [Boston.pm] Perl 6 has become too complex
Erik Price [EMAIL PROTECTED] quoth: *> *>I'm not a linguistic scholar, but I read once that linguistic scholars *>have noticed that throughout human history, there has always been a *>trend of languages diverging, rather than converging (as one might *>expect). As the amount of widespread-edness* of a language grows, the *>more likely that subgroups using the language are to evolve with their *>own dialects of that language, separating from the main "trunk" as it *>were. I wonder sometimes about the grammars that people use to write *>software and how closely or not so closely it relates. I'm merely an armchair linguist and enthusiast but my point was as far from the technical as you can get without coming back round the backside. Imagine yourself arriving somewhere your native language and any other language you may speak/read with any efficiency are mostly, if not completely, useless. Convergence, divergence, liguistic highbrow are of little use in this context as your goal is to communicate not to compare. Finnish is radically different than the I-E family of languages so until you know both of them comparison is simply not possible. Neither English nor Finnish were consciously designed by one or more people looking for the most efficient method of communicating meaning which can be seen as a bug or a feature depending on your perspective. Yet in spite of their complexity millions of people use and change the languages daily. People spend far too much angst on comparing perl5 to what is emerging in the perl6 apocalypses as it isn't very productive to find meaning in one language by looking through another especially when the new language has yet to be in use. Finnish has no gender, no future tense, no articles, and a host of locative cases and postpositions which make translation a source of frustration as communicating something in Finnish is quite a different construct than its English equivalent. When you accept rather than compare it becomes far easier to see the logic and get on with it. P6 is circumventing the slower method of natural change in language but, look on the bright side, it's not going to be Finnish :) As far as human and computer language grammars go you should read Larry's natural language bits; http://www.wall.org/~larry/natural.html and http://www.techgnosis.com/wall1.html e. ___ Boston-pm mailing list [EMAIL PROTECTED] http://mail.pm.org/mailman/listinfo/boston-pm
Re: [Boston.pm] Perl 6 has become too complex
On Tuesday, March 18, 2003, at 02:03 AM, Elaine -HFB- Ashton wrote: 400 hundred years ago Agricola codified Finnish yet today there are more than 80 dialects not to mention the huge variation between the written and spoken forms. I'm not a linguistic scholar, but I read once that linguistic scholars have noticed that throughout human history, there has always been a trend of languages diverging, rather than converging (as one might expect). As the amount of widespread-edness* of a language grows, the more likely that subgroups using the language are to evolve with their own dialects of that language, separating from the main "trunk" as it were. I wonder sometimes about the grammars that people use to write software and how closely or not so closely it relates. * case in point 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
Joe Johnston [EMAIL PROTECTED] quoth: *> *>Do you trust Larry and Damain? I wish they'd just stop circulating the Apocs so widely as every time Larry emits one there is a rash of people who think the world has needed to know or cares that it's not what they wanted or needed to use. It's the typical egocentric universe that tends to plague us even now in the dot.bomb. It's less about trust than of wanking. 400 hundred years ago Agricola codified Finnish yet today there are more than 80 dialects not to mention the huge variation between the written and spoken forms. The consonant gradation makes words look unrecognisable from one case to the next and "K" is sublime which, if Finnish ever makes it to redesign, I'm going to suggest the entire language be done using more "K" and be renameed to "lang". I think of Larry often in my Finnish class as it tells me that noone could have possibly designed this language intentionally but it gets a lot of use, much more than English over here, and that tagmemics has a lot less validity when you're sitting in a class trying to learn vocabulary and grammar from a woman waving her arms around and saying a stream of sounds which have utterly no meaning at all, not the slightest. e. ___ Boston-pm mailing list [EMAIL PROTECTED] http://mail.pm.org/mailman/listinfo/boston-pm
Re: [Boston.pm] Perl 6 has become too complex
Dear Dan, Be of good cheer. If you build it, they will come. > been about as good for my ego as, say, swimsuit > modelling would be. Most everyone would agree we'd rather see Dan (or Damian or even Larry) in a swimsuit than Uri (unless there is a bullseye near the bench he's preched on; how much for 3 pitches?). > Unless Larry or Damian are closet masochists, I > expect it's been about as much of an ego stroke for them, too. "They say? What say they? Let them say." -- Olde Scots motto. The ubuiquitous "they" said Perl 5 would fail too. The stream of critiquies of the Apocalypse before the Exegisis is amusing. Folks who have no use for academic featuers are engaging in academic masturbation buy criticising the design documents. The Apocalypsos are the design spec for the implementors, the Exegesexen are the preview of the 6-legged Camel books for the rest of us. Lighten up guys, let's see what Damian makes of it. If Perl 6 will run my Perl5 scripts faster with no change (or a simple conversions), will I switch? In a minute. Will I adopt the new features? Some of them quickly, some more slowly ... same as Perl 5. == Bill [EMAIL PROTECTED] / n1vux ___ Boston-pm mailing list [EMAIL PROTECTED] http://mail.pm.org/mailman/listinfo/boston-pm
Re: [Boston.pm] Perl 6 has become too complex
At 4:24 PM -0500 3/17/03, [EMAIL PROTECTED] wrote: Mikey Smelto wrote: "I use a computer to accomplish tasks, > not to accomplish using the computer." Just because they're putting something into perl 6 that doesn't help you get your job done, doesn't mean that they're doing it simply for an ego trip. For the record, redesigning an existing product lots of people both love and hate has been about as good for my ego as, say, swimsuit modelling would be. Unless Larry or Damian are closet masochists, I expect it's been about as much of an ego stroke for them, too. -- Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk ___ Boston-pm mailing list [EMAIL PROTECTED] http://mail.pm.org/mailman/listinfo/boston-pm
Re: [Boston.pm] Perl 6 has become too complex
* Mikey Smelto <[EMAIL PROTECTED]> [03-03-17 15:59]: > > "I stopped caring about perl 6 because I use a computer to accomplish > tasks, not to accomplish using the computer." Giddy with having just filed my taxes, I'd like to add a little something to this worried discussion about Perl 6 and the Dreaded Second System Sydrome. Do you trust Larry and Damain? There's lots of hard evidence to suggest that these guys 'n' gals (and the rest of the Perl 6 Simpaticos) will Do The Right Thing. I've read the Apocalypses and skimed the Exegeseseseses (or something), but I regard these documents as poetry of a more technical bent. In others, something very close to fiction. The time to worry is when the *code* for Perl 6 ships. If Perl 6 becomes Java with dollar signs, then I suspect it will fail. It won't be the end of the world if Perl 6 becomes tomorrow's Ada, because then we know what *not* to do for Perl 7. As the N.A.N.D.O.R. pointed out, no one is erasing Perl 5 from your non-volitile storage devices. Observe that the Linux Router Project has a package for Perl 4! Morbidly, I want to close by noting that "language-specific" communities grow and shrink like living organisms (not too surprising given their composition). Is this the twilight of Perl? Who can say so with authority? I'm still making money with Perl. Perl still pulls my butt out of the fire every day. However, if the day comes that I can't do what I need to with Perl, there will be other tools available. I rather wish this entire Boston.pm thread had been devoted to the last episdoe of Farscape showing this Friday on SciFi. Farscape's untimely cancellation is indeed worthy of lamentation and tears. Perl 6 will be fine. Just fine. ;-) -- Joe Johnston -- http://taskboy.com Software Consultant: Web - Database - Perl "...our power is in argument and persuasion." --Chinua Achebe ___ Boston-pm mailing list [EMAIL PROTECTED] http://mail.pm.org/mailman/listinfo/boston-pm
Re: [Boston.pm] Perl 6 has become too complex
Mikey Smelto wrote: > "I use a computer to accomplish tasks, > not to accomplish using the computer." I get your point, but you're using perl. USING perl is about getting your job done. DESIGNING perl is about getting everyone's job done. Just because they're putting something into perl 6 that doesn't help you get your job done, doesn't mean that they're doing it simply for an ego trip. Greg ___ Boston-pm mailing list [EMAIL PROTECTED] http://mail.pm.org/mailman/listinfo/boston-pm
Re: [Boston.pm] Perl 6 has become too complex
At 8:54 PM + 3/17/03, Mikey Smelto wrote:
I don't know if I can agree with that statement. As I paraphrase an
anonymous co-worker at an anonymous workplace.
"I stopped caring about perl 6 because I use a computer to
accomplish tasks, not to accomplish using the computer."
Good grief, the amount of handwringing over the impending "Perl 6
Cataclysm" is pretty phenomenal.
For an awful lot of tasks, the only difference between perl 5 and
perl 6 is you write:
@foo[12]
instead of
$foo[12]
and you may throw a
use re qw(perl5);
at the top of your program.
I mean, come *on* people, we're not stupid. Yeah, the wacky modules
that intercept method dispatch to inspect the caller's context and do
delegated multimethod dispatch quantumly across multiple threads
simultaneously may change, but how many people write stuff like that?
I sure don't.
The second biggest difference is you might write:
sub foo ($bar, $baz) { }
instead of
sub foo {
my ($bar, $baz) = @_;
}
But it's not like *that* is a bad thing either.
perl 6 will be more complex than perl 5,
but I think the philosophy is still the same,
"perl is for getting your job done".
I don't think anything's getting added unless
it'll make it easier for someone to get their
job done.
--
Dan
--"it's like this"---
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
___
Boston-pm mailing list
[EMAIL PROTECTED]
http://mail.pm.org/mailman/listinfo/boston-pm
Re: [Boston.pm] Perl 6 has become too complex
I don't know if I can agree with that statement. As I paraphrase an anonymous co-worker at an anonymous workplace. "I stopped caring about perl 6 because I use a computer to accomplish tasks, not to accomplish using the computer." perl 6 will be more complex than perl 5, but I think the philosophy is still the same, "perl is for getting your job done". I don't think anything's getting added unless it'll make it easier for someone to get their job done. _ Help STOP SPAM with the new MSN 8 and get 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
> Apocalyse 6 included almost > 30 pages discussing the new ==> > and <== operators! This is not a good sign. The apocalypses read like the tome of an advanced wizard making notes for himself in preparation for casting some earth-altering spell. And ya know, that's kind of what it is... But I assume that there will be room for apprentice wizards of varying degrees of skill to traffic in the tools of Perl 6 and get stuff done. *>I learned Perl 4 from its man page -- yes there *>was one long man page that completely described the entire language. Great, you read the man page, and you became a level 4 perl apprentice. Have you learned anything since reading that man page? Are you using perl 5? could you put everything you know about perl 5 into an equally sized man page document? perl 6 will be more complex than perl 5, but I think the philosophy is still the same, "perl is for getting your job done". I don't think anything's getting added unless it'll make it easier for someone to get their job done. It's just that some people need threads, types, class contracts, and multimethods to get their job done. Greg ___ Boston-pm mailing list [EMAIL PROTECTED] http://mail.pm.org/mailman/listinfo/boston-pm
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 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 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 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 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
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
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 hearing people grump about that which does not exist. I feel badly for those several key people, as you call them, as it seems like freaks just can't resist the urge to voice discontent. You are all like children who cry at christmastime 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 a twist. I have it on very good authority that p6 was the best thing that ever happened to p5p as it drew the whiners and the talkers all over to the p6 lists leaving the doers to get down to business. P6 may never come to fruition but for that one particular benefit I am particularly grateful as it made Jarkko's job much much easier. I will suggest you read "The Power of Babel" as it's an excellent story on the development of language which you may or may not appreciate in this context. e. ___ Boston-pm mailing list [EMAIL PROTECTED] http://mail.pm.org/mailman/listinfo/boston-pm
Re: [Boston.pm] Perl 6 has become too complex
> "JT" == John Tobey <[EMAIL PROTECTED]> writes:
JT> On Fri, Mar 14, 2003 at 03:49:21PM -0500, Dan Sugalski wrote:
>> At 10:14 AM -0500 3/14/03, Andrew Pimlott wrote:
>> >
>> >A6 says that, as in Perl 5, only anonymous subs are closures. I've
>> >always thought of the fact that Perl 5 named subs are not closures
>> >as a bug kept for compatibility.
>>
>> Well... there's always the issue that closures are done by
>> instantiating the sub at runtime, while named subs are instantiated
>> at compile time, which causes some difficulties. (As the enclosing
>> sub's lexicals instantiate at runtime, thus giving the contained sub
>> nothing to close over)
>>
>> Now, if the named lexically scoped sub actually got re-instantiated
>> every time, *that* would be different.
JT> YES. That's what we want. That is how Scheme and Common Lisp work.
JT> That would make for cleaner code.
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?
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
Since I appear to have contributed to the problem ... :-) 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!). Yes, Perl 6 will be enormous. But the new ideas have come from (at least) dozens of minds and hundreds of man-years' experience with Perl; they have been scrutinized and discussed in public; they are being carefully weighed and assimilated by a proven language designer; and they will be implemented by top-notch hackers like Dan. I'm not guaranteeing that Perl 6 won't be a second-system flop, but I give it good odds. Don't forget, each Apocalypse seems less daunting and more appealing after the accompanying Exigesis, so at least wait for Damian to chime in and balance things out! > I think it is telling that most of the responses to my email > are a technical discussion, e.g. how to make Perl more > like Scheme. But Scheme, while elegant, is still > a "boutique" langue whereas Perl is widely used. Perl has picked up lots of ideas from lots of languages. Where do you think closures came from in the first place? Probably also the general list-orientation. And the fact that this thread has zoned in on Scheme doesn't mean that Larry is focused in this direction. I haven't seen any evidence of that at all. He's incorporating a staggering number of new concepts, but he seems to be getting them from all corners of the universe. > As we know, when Larry designed Perl he took the best parts > of awk, VC, sh, etc., plus added a few excellent new ideas, > and produced a language that was a mixture -- but a mix > based on features that had been proven to be good. > > In contrast Perl 6 is a mixture of a variety of theoretically > desireable features, e.g. multimethods, functional programming, > logic programming, aspect oriented programming, > design by contract, etc. that have not been proven in > widely used languages. I would say that (most of) these ideas are more widely used and proven--in some circle--than you give them credit for. Also, I wasn't around for the early evolution of Perl either, but bet some of Perl's features were similarly "academic" to the Perl community when they were introduced. Frankly, I commend Larry for his effort to pull them into a popular, approachable language. Maybe I have an ax to grind (functional programming not proven!?), so don't listen to me; but Larry doesn't--that's one of his most remarkable features--and I think he may still have a few gems to give us. Andrew ___ 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 04:31:06PM -0500, Andrew Pimlott wrote: > On Fri, Mar 14, 2003 at 04:32:17PM -0500, John Tobey wrote: > > > > YES. That's what we want. That is how Scheme and Common Lisp work. > > That would make for cleaner code. > > Well, Common Lisp and Scheme don't work quite the same. Thanks for the correction. -- 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 Fri, Mar 14, 2003 at 04:17:08PM -0500, Andrew Pimlott wrote:
> > bar() -> undef
> > foo("a")
> > bar() -> "a"
> > foo("b")
> > bar() -> "b"
Um, the last one is -> "a".
Andrew
___
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 04:32:17PM -0500, John Tobey wrote: > On Fri, Mar 14, 2003 at 03:49:21PM -0500, Dan Sugalski wrote: > > At 10:14 AM -0500 3/14/03, Andrew Pimlott wrote: > > > > > >A6 says that, as in Perl 5, only anonymous subs are closures. I've > > >always thought of the fact that Perl 5 named subs are not closures > > >as a bug kept for compatibility. > > > > Well... there's always the issue that closures are done by > > instantiating the sub at runtime, while named subs are instantiated > > at compile time, which causes some difficulties. (As the enclosing > > sub's lexicals instantiate at runtime, thus giving the contained sub > > nothing to close over) > > > > Now, if the named lexically scoped sub actually got re-instantiated > > every time, *that* would be different. > > YES. That's what we want. That is how Scheme and Common Lisp work. > That would make for cleaner code. Well, Common Lisp and Scheme don't work quite the same. (define (f n) (define (g) n)) in Scheme creates a lexically scoped function g. If it is called within the body of f, it uses the current (lexical) value of n. (defun f (n) (defun g () n)) in Common Lisp greates a globally visible function g when f is run, and re-defines it every time f is run. So wherever you run it, you get n from the most recent call to f. If we have (defun f (n) (defun g () n) (if (> n 0) (f (1- n))) (g)) then (f 4) returns 0. To get Scheme behaviour in Lisp, you have to use a different function: (defun f (n) (labels ((g () n)) (if (> n 0) (f (1- n))) (g))) Now (f 4) return 4. I wouldn't recommend the Lisp behavior. I'm sure the Lisp people would get rid of it if they didn't have bigger compatibility issues than Perl. :-) Andrew ___ 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 04:35:07PM -0500, Dan Sugalski wrote: > > > >YES. That's what we want. That is how Scheme and Common Lisp work. > >That would make for cleaner code. > > Well, if that's what you want... :) > > I'm OK with that. Convince Larry and I'll make it happen. Thanks but I'll pass. I've given up on Perl 6 (but not on Parrot). -- 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 Fri, Mar 14, 2003 at 03:49:21PM -0500, Dan Sugalski wrote:
> At 10:14 AM -0500 3/14/03, Andrew Pimlott wrote:
>
> >A6 says that, as in Perl 5, only anonymous subs are closures. I've
> >always thought of the fact that Perl 5 named subs are not closures
> >as a bug kept for compatibility.
>
> Well... there's always the issue that closures are done by
> instantiating the sub at runtime, while named subs are instantiated
> at compile time, which causes some difficulties. (As the enclosing
> sub's lexicals instantiate at runtime, thus giving the contained sub
> nothing to close over)
I don't understand exactly what you mean, because perl's behaviour
is rather strange and I don't know how it's implemented. Currently,
named subs close over _something_, because they get the value of
lexicals from the first time the enclosing code is run.
sub foo {
my ($x) = @_;
sub bar { print ">> $x\n"; }
}
> bar() -> undef
> foo("a")
> bar() -> "a"
> foo("b")
> bar() -> "b"
Which is perfectly useless. :-)
At any rate, you're right that the fact that Perl 5 nested subs are
visible globally means that talking about closure is basically
nonsense. In my view, this is part of the bug. Nested subs should
be visible only within their scope (or at least, there should be a
way to declare them so that they are), in which case they would have
to be instantiated at run-time (right?), and there should be no
problem binding the current lexical variables.
> Now, if the named lexically scoped sub actually got re-instantiated
> every time, *that* would be different.
Am I correct that Perl 6 lexical subs would have to get
re-instantiated every time, or could you implement them such that
they are not?
Andrew
___
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 03:49:21PM -0500, Dan Sugalski wrote: > At 10:14 AM -0500 3/14/03, Andrew Pimlott wrote: > > > >A6 says that, as in Perl 5, only anonymous subs are closures. I've > >always thought of the fact that Perl 5 named subs are not closures > >as a bug kept for compatibility. > > Well... there's always the issue that closures are done by > instantiating the sub at runtime, while named subs are instantiated > at compile time, which causes some difficulties. (As the enclosing > sub's lexicals instantiate at runtime, thus giving the contained sub > nothing to close over) > > Now, if the named lexically scoped sub actually got re-instantiated > every time, *that* would be different. YES. That's what we want. That is how Scheme and Common Lisp work. That would make for cleaner code. -- 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
At 10:14 AM -0500 3/14/03, Andrew Pimlott wrote: On Fri, Mar 14, 2003 at 09:30:06AM -0500, Dan Sugalski wrote: Still... What exactly about A6 did you dislike? It's a bit big, but there's nothing in it that seemed particularly controversial or foolish to me, and I tend to get cranky with the new features. How 'bout this one. (I mean to bring it up on perl6-langage or somewhere, but I haven't done my homework yet, so I'll float it here.) A6 says that, as in Perl 5, only anonymous subs are closures. I've always thought of the fact that Perl 5 named subs are not closures as a bug kept for compatibility. Well... there's always the issue that closures are done by instantiating the sub at runtime, while named subs are instantiated at compile time, which causes some difficulties. (As the enclosing sub's lexicals instantiate at runtime, thus giving the contained sub nothing to close over) Now, if the named lexically scoped sub actually got re-instantiated every time, *that* would be different. -- Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk ___ Boston-pm mailing list [EMAIL PROTECTED] http://mail.pm.org/mailman/listinfo/boston-pm
Re: [Boston.pm] Perl 6 has become too complex
Andrew Pimlott wrote:
> sub foo
> {
> my ($x, $y, $z) = @_;
> sub helper
> {
> ... $x $y $z ...
> }
> ...
> ... helper() ...
> ... helper() ...
> ...
> }
>
> In Perl 5 you can get around this by assigning
> an anon sub to a glob ref (ugh)
hm, well, you can get around glob refs as shown
below. (haven't checked for typos, etc)
#!/user/local/bin/perl
use Symbol::Table;
my $symbol=Symbol::Table->new('CODE');
sub foo
{
my ($x,$y,$z)[EMAIL PROTECTED];
# Look Ma! No typeglobs!
$symbol->{helper}=sub
{
$x++;$y+=2;$z*=2;
}
helper();
helper();
}
Symbol::Table is a module I just released to CPAN
expressly for fiddling with the symbol table
without the user having to do eval() or fiddle
with *type_globs. all that nastyness is hidden
in the module. $symbol is a reference to a tied
hash, the keys are the names of the symbols,
the values are references to the symbols.
make sure you get Symbol-Table-1.01.tar.gz
SymbolTable-* is scheduled for deletion.
Oh, just a warning, read the POD, but dont
look at the code in the module, it's the
work of a madman. ;)
Enjoy,
Greg London
___
Boston-pm mailing list
[EMAIL PROTECTED]
http://mail.pm.org/mailman/listinfo/boston-pm
Re: [Boston.pm] Perl 6 has become too complex
At 09:30 -0500 2003.03.14, Dan Sugalski wrote: >At 9:13 AM -0500 3/14/03, Tolkin, Steve wrote: >>I want "good Damian" to work with Larry el al. to reduce the >>complexity of the language. Or (shudder) a subset of the language to >>be defined. >> >>Please advise me as to how to proceed. > >Ruby and Python seem to be the standard choices. What's wrong with Perl (the one that actually exists)? It's not going away ... Perl 6 won't be here for a long time, and even when it does arrive, many people will continue to use Perl 5. I don't like the Perl 6 language, in many ways. I stopped caring; why should I worry about something I don't like that I can't change, when I have something I do like already? -- 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 Fri, Mar 14, 2003 at 09:30:06AM -0500, Dan Sugalski wrote:
> Still... What exactly about A6 did you dislike? It's a bit big, but
> there's nothing in it that seemed particularly controversial or
> foolish to me, and I tend to get cranky with the new features.
How 'bout this one. (I mean to bring it up on perl6-langage or
somewhere, but I haven't done my homework yet, so I'll float it
here.)
A6 says that, as in Perl 5, only anonymous subs are closures. I've
always thought of the fact that Perl 5 named subs are not closures
as a bug kept for compatibility. It prevents this nice programming
style (example in Perl 5 because I'm sure I would botch Perl 6):
sub foo
{
my ($x, $y, $z) = @_;
sub helper
{
... $x $y $z ...
}
...
... helper() ...
... helper() ...
...
}
In Perl 5 you can get around this by assigning an anon sub to a glob
ref (ugh), and in Perl 6 it appears you will be able to assign it to
a normal lexical variable (better), but neither is as nice as just
declaring a sub. Given that Perl 6 will even have lexically scoped
subs, it's seems perverse that they would not also be closures.
Besides, if such subs aren't closures, what is the semantics of
accessing a lexical variable from the outer scope? It seems that
the only alternatives to closure are Perl 5 "variable will not stay
shared"--which is unspeakably ugly and the source of much
confusion--or error.
So, why aren't all subs, or at least lexical subs, closures?
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 9:13 AM -0500 3/14/03, Tolkin, Steve wrote: In Apocalyse 6 http://www.perl.com/pub/a/2003/03/07/apocalypse6.html Larry Wall explains how subroutines are going to work in Perl 6. I think this is the straw that broke the camel's back. I think this is the worst case of "second system syndrome" I have ever seen (See Jargon file e.g. at http://info.astrian.net/jargon/terms/s/second-system_effect.html ) and I quote: "When one is designing the successor to a relatively small, elegant, and successful system, there is a tendency to become grandiose in one's success and design an elephantine feature-laden monstrosity." I think the language design shows too much influence of "Evil Damian". I want "good Damian" to work with Larry el al. to reduce the complexity of the language. Or (shudder) a subset of the language to be defined. Please advise me as to how to proceed. Ruby and Python seem to be the standard choices. Still... What exactly about A6 did you dislike? It's a bit big, but there's nothing in it that seemed particularly controversial or foolish to me, and I tend to get cranky with the new features. -- Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk ___ Boston-pm mailing list [EMAIL PROTECTED] http://mail.pm.org/mailman/listinfo/boston-pm
Re: [Boston.pm] Perl 6 has become too complex
hi ( 03.03.14 09:13 -0500 ) Tolkin, Steve: > Please advise me as to how to proceed. i think you can email either damian or larry [psuedo-] directly. or post something on perlmonks.org. or you can start your own fork of the perl code- that's one of the benefits of open source. -- .--- ... [ x ] ___ Boston-pm mailing list [EMAIL PROTECTED] http://mail.pm.org/mailman/listinfo/boston-pm
