Glenn Linderman wrote:
On approximately 2/8/2006 1:06 PM, came the following characters from
the keyboard of Lyle Kopnicky:
Thanks for the explanation. As far as I am concerned, then, perl's
closure model is unintuitive and broken. It doesn't work like
closures in any other language I have seen, including Pascal,
Smalltalk, Common Lisp, Scheme, ML, or Haskell. Don't know about
Python or Ruby, but I suspect they don't make this mistake. It
should always create a new closure for gettoken() each time parse()
is run. The workaround, as mentioned, is to write $gettoken = new
sub {...}, instead, but that workaround shouldn't be required.
Hopefully this will be fixed in Perl 6.
Well, I'm not really all that familiar with closures in other
languages; if Pascal had them back in the late 70s when I used it, I
never happened across them.... I haven't used the other languages you
mention enough to comment.
Yes, I believe it did.
However, given that Perl allows two techniques for closures.. the
"anonymous sub closure" (which seems to be what you expect), and the
"named sub" closure (which was used in this example), with different
behaviours, doesn't that give it more flexibility than the other
languages you mention? In Perl, you can have two different types of
scoping for closures--can you in those other languages?
OK, to be fair, most of the languages I mentioned only allow the
"anonymous sub" type closure, although you can assign it to a variable,
as in Perl. Pascal definitely supports the "named sub" type, and
handles just like other languages handle the "anonymous function" type.
Incidentally, C# also handles "anonymous methods" the same way, as
proper closures, as does Java with its "anonymous inner classes". Dunno
how Java treats named inner classes. Can you define one inside a
method? Anyone?
It seems like it would be nice that you can do to different things in
Perl. But that would be true only if there was an advantage for the
distinct behavior of each, under different circumstances. I see no
advantage to the way Perl treats nested named subroutines. As far as
I'm concerned, it is counterintuitive, as evidenced by John's problem.
Would you think it was advantageous, say, if addition and subtraction
worked differently inside subs than they did in the main script? I
personally think consistency is better.
I guess the Perl philosophy is to add on a hodgepodge of conflicting
features, and figure the programmer can probably sort it all out.
Although in Perl 6 that sort of concept seems to be going by the wayside.
--
Lyle Kopnicky
Software Project Engineer
Veicon Technology, Inc.
_______________________________________________
Perl-Win32-Users mailing list
Perl-Win32-Users@listserv.ActiveState.com
To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs
