* (sort of) structure of LUA Program

[Ron Melby]

been perusing a lot of LUA lately, and I see lines like this
local ted = 0
red = 0
local med = 9

local function ( whatever )
return 0
end

local fred = 0
local dred = 0

function (who cares)
return 0
end

in other words, i see declarations scattered about in the code (to me) and its no big deal right? (probably some of these are declared near point of first use.

These are just FILE global definitions like any other even if I were to gather them all at the top of the file. Like any other, and out of scope of other files, and not function scopes.

[Jane]

If you want to understand Lua fully you might want to read the "Programming In Lua" book.

Local declarations are cleaned up at the end of the program block they are declared in, this is the same for Local Functions.
Variables declared or used for the first time without local are global, but if they are declared with local in the same block or a parent block they will continue to be used as Local until the parent block ends.

The debugger will show the scope of any variables when stopped at a breakpoint.

So in the following example

Code: Select all

a = 1
do
   local a = 6
   a = a + 6
   print(a)
end
print(a)

You will get

Code: Select all

12
1

[tatewise]

Ron, in plugins:getting_started|> Family Historian Plugins > Getting Started Writing Plugins under Lua Language References checkout the two free online guides:
http://www.lua.org/manual/5.1/ Lua 5.1 Reference Manual
http://www.lua.org/pil/contents.html Programming in Lua (first edition)
They both have details about the scope of locally declared variables in code blocks.

Just like most structured languages Lua supports locally scoped variables and functions.
They only exist within the code block in which they are declared, otherwise variables have global scope.
As Jane says, at break points in the Lua debug window, the scope of variables is show in the bottom right pane.

[Ron Melby]

So,

function
end

local fred

function
end

is the same as putting fred at say the top of the file?

the reference manuals for LUA are a work of horror. They may occasionally get a very simple idea across in 20 pages, but nothing advanced in there, nearly completely unintelligible.

[Jane]

I actually found the "Programming in Lua" guide very concise and easy to read, especially compared to most IBM and Microsoft language guides.

In your example almost, as you have not declared a scoping area for the local variable, so it will exist for the running of the plugin from the point that the definition is processed in the running of the plugin. It will not exist from the start of the plugin.

[tatewise]

I thought http://www.lua.org/pil/contents.html Programming in Lua (first edition) was OK.

No, it is NOT the same as putting fred at say the top of the file.
local variables are only in scope from the declaration down to the end of the enclosing block.

function one()
print(fred) -- Local fred is not in scope here, so it is a Global and prints as nil
end

local fred = 99

function two()
print(fred) -- Local fred is in scope here so it prints as 99
local fred = 11
print(fred) -- This new fred is in scope here so it prints as 11
end

one()
two()


Global variables are in scope everywhere in the script wherever they are used.

function one()
print(fred) -- Global fred is in scope here so it prints as 99
end

function two()
print(fred) -- Global fred is in scope here so it prints as 99
local fred = 11
print(fred) -- This new fred is in scope here so it prints as 11
end

fred = 99 -- Global is in scope even for the functions above, because it is executed before the functions are called.

one()
two()

[Ron Melby]

what I have learned this weekend after another all day and night weekend of debugging, normalizing code, putting it in functions (since I cannot find a /copy sort of text(code) into the program *here* thing) and not ready to figure load and . : yet, I now have a great deal of functions that change common things I report on in different flavors globally. like names, I either get them in 1, (or sometimes if female in 5 (my max at the moment) and call the function and wrtNAMES. Since they are global, I am always returning some transformation like this:

function inzVAR()
Name = ''
sex = ''

relation = ''
clc = ''
pre = ''
pst = ''
rpl = ''
tho = ''
age = 0
sort = 0

Dates = ''
eyb = 'f'
fBirth = BLANKS
Birth = BLANKS
cBirth = BLANKS
eBirth = BLANKS
mBirth = BLANKS
lBirth = BLANKS

eyd = 'f'
fDeath = BLANKS
Death = BLANKS
cDeath = BLANKS
eDeath = BLANKS
mDeath = BLANKS
lDeath = BLANKS
end -- fn inzVAR

this just cleans up the fields from the last record so that it is easier to debug. simple

However, if you are doing many function calls, as a matter of course over many records, even an I3 will get very slow if you dont include a naked
return
end -- fn inzVAR
.
I have went through my global functions and done that and my programs have perked up considerably. I thought I was going to have to start doing a processing window, but they come back now, almost immediately.