# Visibility and upvalues (and macros)

7 messages
Open this post in threaded view
|

## Visibility and upvalues (and macros)

 ``` 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 ```
Open this post in threaded view
|

## Re: Visibility and upvalues (and macros)

 ```>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 ```
Open this post in threaded view
|

## Re: Visibility and upvalues (and macros)

 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! Is this type of "trick" what you were intending to demonstrate there? Cheers, Dave ```
Open this post in threaded view
|

## Re: Visibility and upvalues (and macros)

 ```>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! 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 ```
Open this post in threaded view
|

## Re: Visibility and upvalues (and macros)

 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 ```
 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 ```
 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 ```