Visibility and upvalues (and macros)

classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

Visibility and upvalues (and macros)

Dave Bollinger
   Oops, I left something out:

 >> How is it different from this (which does work):

fl = nil
function g(a)
  local gl = fl -- no problem referencing a global, even if nil
  print(gl) -- gl is of course itself still nil
end
g(123)


   (which was just meant to be a sort of global version of the previous
example)

   Cheers,

   Dave

Reply | Threaded
Open this post in threaded view
|

Re: Visibility and upvalues (and macros)

Luiz Henrique de Figueiredo
>From [hidden email] Wed Jul 28 23:16:17 1999
>From: Dave Bollinger <[hidden email]>

>I wonder why can't a local function access an
>enclosing function's local variables?
>I understand the explanation that the
>variable might no longer exist - and I *assume* that this is because Lua
>needs to be able to make a compile-time decision on this issue, yes? 

No. The whole point is that the "enclosing" scope might no longer exist
when the function is executed. Remember that functions are first-class values
and may be returned from functions:

 function f()
	 local a=1
	 return function (x) print(x+a) end	-- ERROR: cannot access 'a'
 end

 g=f()
 g(2)

If you expect g(2) to print 3, then that's exactly what upvalues are for:
you should write

 function f()
	 local a=1
	 return function (x) print(x+%a) end	-- ok now
 end

Otherwise, what would x+a mean inside g?
The whole point of the '%' notation is to signal that the *value* of 'a'
is being used, not the variable itself.

> How is it different from this (which does work):

 fl = nil
 function g(a)
   local gl = fl -- no problem referencing a global, even if nil
   print(gl) -- gl is of course itself still nil
 end
 g(123)

This does work because g gets the value of the global fl when it runs.
If you do fl=12 after defining g but before calling it, 'g' will use 12,
not nil. To use nil, you should 'freeze' the value of 'fl', by using an upvalue.
So, upvalues have less to do with scope and visibility than with freezing
values.

Upvalues take some getting used to, but they are powerful.
--lhf

Reply | Threaded
Open this post in threaded view
|

Re: Visibility and upvalues (and macros)

Dave Bollinger
In reply to this post by Dave Bollinger
 >> the "enclosing" scope might no longer exist when the function is
executed.

   Aha!  It might be executed outside the scope where it was defined.  Duh!

   Thanks, I think that helped.  :-)

   I've become real comfortable with upvalues as backwards references to
overridden functions, but have stopped at about that point.   It seems
then, if I'm on the right track now, that one of the neat "tricks" with
upvalues is using a function to return a newly created function which uses
upvalues - and since it's newly created, the upvalues are "current".  So
each time you call the "creator" function it could return a different
function based on the current value of the thing referenced by the upvalue.

   I need to revisit the factorial.lua test code.  I remember going around
in circles trying to figure that one out!  <grin>  Is this type of "trick"
what you were intending to demonstrate there?

   Cheers,

   Dave

Reply | Threaded
Open this post in threaded view
|

Re: Visibility and upvalues (and macros)

Luiz Henrique de Figueiredo
>From [hidden email] Thu Jul 29 01:58:27 1999
>From: Dave Bollinger <[hidden email]>

>It seems
>then, if I'm on the right track now, that one of the neat "tricks" with
>upvalues is using a function to return a newly created function which uses
>upvalues - and since it's newly created, the upvalues are "current".  So
>each time you call the "creator" function it could return a different
>function based on the current value of the thing referenced by the upvalue.

Exactly!
Something like this:

 function add(a) retunr function (x) return x+%a end end

 a=add(1)
 b=add(2)
 print(a(10)+a(30))

this prints (10+1)+(30+20)

>   I need to revisit the factorial.lua test code.  I remember going around
>in circles trying to figure that one out!  <grin>  Is this type of "trick"
>what you were intending to demonstrate there?

factorial.lua shows that the standard "functional programming" Y function
is definable in lua. It *is* pretty hard to understand.
I guess there should be a better example in the test directory that uses
upvalues.
--lhf

Reply | Threaded
Open this post in threaded view
|

Re: Visibility and upvalues (and macros)

Michael T. Richter-2
In reply to this post by Dave Bollinger
At 12:43 AM 7/29/99 , you wrote:
>I've become real comfortable with upvalues as backwards references to
>overridden functions, but have stopped at about that point.   It seems
>then, if I'm on the right track now, that one of the neat "tricks" with
>upvalues is using a function to return a newly created function which uses
>upvalues - and since it's newly created, the upvalues are "current".  So
>each time you call the "creator" function it could return a different
>function based on the current value of the thing referenced by the upvalue.

If I'm understanding what you're describing here, I think you've just found
out about closures.

--
Michael T. Richter    <[hidden email]>    http://www.igs.net/~mtr/
          PGP Key: http://www.igs.net/~mtr/pgp-key.html
PGP Fingerprint: 40D1 33E0 F70B 6BB5 8353 4669 B4CC DD09 04ED 4FE8 
--
Michael T. Richter    <[hidden email]>    http://www.igs.net/~mtr/
          PGP Key: http://www.igs.net/~mtr/pgp-key.html
PGP Fingerprint: 40D1 33E0 F70B 6BB5 8353 4669 B4CC DD09 04ED 4FE8

Reply | Threaded
Open this post in threaded view
|

Re: Visibility and upvalues (and macros)

Dave Bollinger
In reply to this post by Dave Bollinger
 >> I think you've just found out about closures.

   Or at least I think I might now recognize their practical application. 
:-)

   I'm comfortable with the notion of a function carrying around it's own
environment, but I don't have a lot of practical experience with how to
exploit that concept to get real work done.  I suspect that if I'd been at
a school where LISP (for example) was in fashion that it might be a
different story.

   Cheers,

   Dave

Reply | Threaded
Open this post in threaded view
|

Re: Visibility and upvalues (and macros)

Dave Bollinger
In reply to this post by Dave Bollinger
 >> I guess there should be a better example in the test directory that
uses upvalues.

   That reminds me:  I think a few more examples in general would be a good
thing.   What kind?

   I like the little snippets that can be found in (for example) K&R's C
book.  I think they show how the authors themselves intended the language
to be used.  For instance, although there are a probably a million ways to
write a "bit counter" routine, it is instructive for beginners to see
specificially how the authors did it.  Helps get into the "mind-set" of the
language.

   The snippets are usually trivial and short, focusing on a very
well-defined and limited problem -- but one that can be solved in a unique
way with the particular language.  Anything that is classic "first
semester" homework in an algorithms class might be a good candidate.  For
instance E's sieve, recently posted for benchmarking was a good example,
how might you yourself code that routine to take best advantage of Lua's
architecture?  (rhetorical question) 

   Take, for instance, the fibonacci function, which is self-described as
"inefficient".  OK then, is there a BETTER way to do it with Lua?  (again
rhetorical)  In order to illustrate why a given technique is preferred.

   Cheers,

   Dave