Re: variables and scope

On Wed, Apr 15, 2009 at 2:01 PM, Thomas Michael Hagen
<[email protected]> wrote:
> in gerH builds, variables have scope. this means you can't use a
> variable you have defined where you want it; you have to send it
> there.
>
> thus, you need one of two things; either a keyword that labels the
> variable as global, or the ability to send more than one variable to a
> function call.
>
> are any of these two things possible in gerH?
>
> and a more general question: where do i find comprehensive (and
> up-to-date) documentation for gerH builds?

Had some serious health issues, hence only back on-line since today.

Anyway, in reverse order:

documentation is comparable to vanilla. That is: QUICKREF.txt is your
best bet/take on things. It's like a UNIX manpage, alas. (First you
discover, then you read again and go 'a-ha, that's what the bloody
(bleepard) meant') Mea culpa. Sought: one documentalist (m/f) with
time on his/her hands.


The 'scope' thing is 'documented' <blush> in the mailing list. Read:
it's extremely lacking in that department for anyone who isn't savvy
regarding language design and language processing tools.

To make 'scoped' crm114 behave akin to 'unscoped' crm114, all you have
to do is this: 'instantiate the variables you wish to use globally at
the start of your scripts, i.e. at outermost scope.'
That bla is only telling half the story. Two examples:

#1:
say you have a variable, e.g. /myvar/ which you want to use throughout
your script and hang the scope levels for all you care.

The easy way out is, in close-to-laymen terms, to 'make sure crm114
knows about the variable in any scope you wish to use it', i.e. the
'quick fix' is to create the variable symbol by writing a

  isolate (:myvar:)

line right smack at the start of your script.
crm114 will see that line, take note of a /myvar/ now existing in your
environment and any subsequent use of said /myvar/ will refer to this
instance. Doesn't matter if you read or write to it; it's all about
'exists yet or not' here.


#2:
say you like the scope thing and wish to pass multiple 'bits of data'
(note I stay away from the term 'arguments' here!) to a subroutine.

Same principle applies: where the variable is first created, there the
scope level will be for that variable.

So an outer function can create _local_ variables using

  isolate (:mylocal1:) /a/
  isolate (:mylocal2:) /b/

or other crm114 statements which create variables (match, ...) and
then just, as usual:

  call /inner_subroutine/

Here /inner_subroutine/ can access those /mylocal1/ and /mylocal2/
variables which are sitting in the 'outer scope', read their contents
and even change their content and then, after the 'return' statement,
returning to the outer routine, will not destroy that work: the
variables /mylocal1/ and /mylocal2/ are, after all, still 'alive'
within this scope level, so you can look at the results written there
by the inner subroutine.




In short: the quick fix is to drop a preliminary isolate() or other
statement at the start of the section where you want crm114 to start
to 'know about these variables here and within subroutines we call
from here'.

The even quicker brute force 'I don't give a hoot about scope' fix is
to put an isolate() line for each variable used at the very start of
the script. This is blunt, brute force, and it makes all those
variables global, as we had before the advent of scoped vars.
Definitely not advised for big scripts, where scope is meant to help
keep script code things manageable. (Without scope, you can't really
do the 'function libraries' thing in crm114 script.)



Does that explain scope and how to use it a bit better?



-- 
Met vriendelijke groeten / Best regards,

Ger Hobbelt

--------------------------------------------------
web:    http://www.hobbelt.com/
        http://www.hebbut.net/
mail:   [email protected]
mobile: +31-6-11 120 978
--------------------------------------------------

------------------------------------------------------------------------------
The NEW KODAK i700 Series Scanners deliver under ANY circumstances! Your
production scanning environment may not be a perfect world - but thanks to
Kodak, there's a perfect scanner to get the job done! With the NEW KODAK i700
Series Scanner you'll get full speed at 300 dpi even with all image 
processing features enabled. http://p.sf.net/sfu/kodak-com