Re: [MLUG] guess what

[Jonathan King <EMAIL:PROTECTED>]

On Thu, 1 Apr 2004, Mark Rages wrote:

> On Thu, Apr 01, 2004 at 02:20:54PM -0600, Jonathan King wrote:

> > Or actually, why that wouldn't be done in Python as
> > 
> > i=1
> >     def counter()
> >         i = i+1
> > 
> > # more stuff
> > 
> > > Of course you need to define i as global to see outside the
> > > function scope.
> > 
> > Except that *makes* i global.  In a true closure, i is *local*.  And 
> > you're not seeing outside the function scope, you're seeing your 
> > own lexical scope.  
> >  
> 
> In Python, you would do this:
> 
> i=1
> def f():
>    global i
>    print "i=",i
>    i = i + 1
> 
> Is this what you thought I meant?

But that just means that f() alters the globally visible i, right?
In other words, if you print i outside of f(), you see the side 
effect.  That's NOT what happens with a closed-over variable.

> Can you explain what you mean by a "true closure"? Assume you're talking 
> to a known idiot.  (I have no computer science training beyond one 
> miserable CECS203 class.  And Fortran of course.)

In a language with true lexical scoping, a function that is defined
within the lexical scope of a variable (i.e., you can see it in the
program text in the block that contains the function) can use that
variable.  More strikingly, that variable persists between function
calls (since it was defined in a scope that still exists and is
reacable via the function), and no other function that wasn't
defined in the same scope can see or use it. So what I wrote was:

> > {
> >     $i = 1;
> > 
> >     sub counter {
> > 	$i++;
> >     }
> > }

this makes counter() into a function that increments (and returns) 
the value of i.  If I'd done (for example) this:

> #!/usr/bin/perl -n 
>
> {
>     my $i=1;
>         sub count {
>              $i++
>         }
> }
>
> print count();

...then I'd have a counter that incremented each time I hit carriage
return (yeah, useless here and not brilliant code, but...).  
There's much fancier things you can do with these than simulate
non-global static variables (it makes callbacks are much nicer), but
this is the idea.

> > Block structuring delimeters {} are (wait for it...) what give you
> > blocks.  Blocks are good.
> 
> Python has blocks; they're just denoted by whitespace.  Like English.

And it's a great thing that English never has any ambiguities caused 
by this, right? :-)  Blocks are good, and good enough to be visible.  
I stand by that statement.
  
> > Statement delimiters are (wait for it again...) what give you
> > statements.  Python would be just as good (actually, much BETTER if
> > it made these things explicit.  It's been awhile, but when I found
> > that you often had to use line continuation devices in Python, I
> > thought "How quaint."  It turns out that Python (at least then) 
> > wasn't expression oriented but *statement* oriented.  I guess you 
> > could say "to each his own" but there were reasons why he hashed 
> > this stuff out in the 70s and decided that expressions and blocks 
> > were Good Things.  This is NOT leading edge kind of stuff.
> 
> If you break the lines in places like after a , or + then you don't need 
> explicit line continuation.  (You can use ; to separate expressions if 
> you so desire)

And that is...a hack.  If Python were expression-based, you'd never
have that special rule.  And you're not separating expressions;  
you're separating statements, I believe.  In Perl, "$foo = 7" is an
expression which returns the new value of $foo.  Put a semi-colon
after it, and you've made it a statement that can be followed by
other statements in the block.
 
> > (Snip rest; I never used PHP once I saw it's dorkiness.)
> 
> Would that I had followed your example.

I had some freedom of choice. :-)

jking

_______________________________________________
members mailing list
EMAIL:PROTECTED
http://mlug.missouri.edu/mailman/listinfo/members