lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]


On Sun, Sep 9, 2012 at 9:27 AM, David Given <dg@cowlark.com> wrote:
> On 09/09/12 16:59, marbux wrote:
> [...]
>> strToLoad = "goto strLabelText"
>>   load(strToLoad)
> [...]
>
> This won't work. Labels are lexical objects, and lexical scope isn't
> imported into a load() function --- the goto you're trying to compile
> here can't see the scope in which the label is defined.

x--snip--x


> (Looking at your code, you seem to be calling load() but then not doing
> anything with the result. load() doesn't *run* code, it merely compiles
> it --- it returns a function which you then have to call.

First, a caveat that I am not much beyond a novice  programmer so have
little more than ignorance to display.  But I deeply value
constructive criticism and accordingly thank you for the feedback. At
the same time, I'll not hold back my perception of reality because if
I'm wrong I want to be told why I am wrong.l

I believe I understand what you meant, but I've got at least a couple
of dozen scripts that use "load" to inject a string defined in various
parent scripts into generic functions where the strings are executed.

NoteCase Pro has an API that that is a functional equivalent of Lua's
"dofile" that executes the code stored in a given different node

That translates into capability for highly modular scripts (and lots
of them) embedded in the same document.  E.g., my largest embedded
script document by source language node property count currently has
332 scripts mostly built atop 67 core generic functions and other
chunks, with all of the above each in its own node. (Hence my keen
interest in developing new methods to launch scripts.)

So for example, I have generic functions that process different
arbitrary groups of nodes, e.g., all nodes in the current branch, all
ancestors of the current node, all nodes that have a specific node
property, all notes in the current list mode view, etc.

But these generic node group functions do not define what processing
is applied to each individual node processed. Instead, that is defined
in the individual parent scripts (that invoke a given generic
function) as global property strProcessNote. The various generic node
processing functions have in common  a single code line to apply the
processing defined in the parent script's global property to each node
in the given node group:

       assert(load(strProcessNote))()

LIkewise, in the particular script I posted earlier, if I change the
value in the line ...

     strLabelText = 'clone node'

... to 'insert date' or 'insert date' the script branches accordingly
to the correct label.  In other words, the script does what I intended
it to do.

I do not know enough about Lua's innards to distinguish between "load"
executing the string itself or "load" merely presenting the string to
one or more other lua methods to process. With no informed knowledge,
I describe the *result* as "using load to inject a string into the
function and execute the string." That is how my lame brain perceives
the result.

Or put more simply, I don't know *why* it works but I know that it does work.

>  I suspect
> you're being misled by this, as you're discarding the error which tells
> you the compilation has failed, and so the result is a noop.)

I'm not wise enough to argue the suspicion, but the construct works.
Last night I became well acquainted with the error message you
mention:

   [string "goto label"]:1: no visible label 'label' for <goto> at line 1

But that was while I was still banging my head against the wall,
trying to persuade goto to accept a string variable as the label's
identifier. Then I remembered that I could inject and execute a string
using "load," tried it, the error message went away, and the script
has consistently branched as desired for all three test case labels. I
intend to add further test cases.

I am very interested in gaining a better understanding of why "load"
does what I want it to do or why my method is untrustworthy. But at
least so far, the method has achieve the results I want.

I will appreciate any further light you might cast on the subject.

Best regards,

Paul