Re: circumflex/caret

<rant> !@#$%^&* FF + Gmail - stopped a script so I lost a response I
wrote to this, including language spec 'n all, 'just' because I've got
a couple machines, including this one, here which are now at 100% CPU
load (some heavy DB lifting and dataprocessing going on while a
distributed Monte Carlo simulation is running full out :-(((((((((((
</rant>


So I'll answer this tomorrow once I get over this defeat and finish my
other work. When this doesn't make it out...


In short: <keep> is used as a flag for isolate / match / eval / union
/ intersect / call, i.e. all operations which can *instantiate*
variables, to instruct them to allocate that variable in global scope.
Where 'global scope' === the topmost 'outer scope' (later more on this).


The whole concept is rather simple, takes maybe ~ 16 bytes per
variable - and I could have done it in less, just didn't feel like
doing that - so not much memory cost and speed is comparable to
regular/previous vanilla / gerH builds.


rules:

1) Any operation which seeks to *use* a variable (either as a source
of destination), will search for the variable in local scope, and when
not found there, will try to find it in the next outer scope,
ascending scopes until we run out (=== we hit 'global scope').

2) vars are instantiated by default in local scope.

3) writing to a variable does NOT CHANGE its scope. Only instantiates
determines the scope of the variable.

4) when <keep> is specified, that particular operation will, when the
target variable cannot be found following rule #1, IGNORE rule #2 ONLY
and instead instantiate the variable in the topmost outer scope ===
global scope.


What constitutes a 'scope level'?

'call' increments the scope level, i.e. descends into a subscope.

'return' decrements the scope level by one, i.e. pops one scope level
off the scope stack. Any variables which have now become invisible,
due to existing in a now-discarded subscope, are gone: they are not
accessible. Nor are they 'static': they do NOT persist until their
scope level is reached again by a subsequent 'call' invocation
sequence: such behaviour is strongly discouraged as no other commonly
used programming language use that paradigm, so can only cause
confusion. And crm114 script is confusing enough as it is. Besides,.
such behaviour is regarded as yet another way of using 'globals',
which is one of the worst possible software engineering practices
available to mankind. Who doesn't agree, should maybe wonder why a
plethora of coding standards outright forbid the use of global
variables in professional software development. (Not that I always
agree with coding standards, but this time I concur.)


Which operations (script opcodes) can instantiate variables (using
<keep> rule #4 or default #2 selectively)?

isolate
match
eval
union
intersect
call  (the return variable!)


The new code passed preliminary muster about an hour ago and will be
part of the next GerH release.


With that comes, of course, an augmented test set and adjusted
mail*.crm scripts: maillib's load_cfg is one prime example where
globals are magicked into existence from inside several call layers.
This won't work anymore, unless you pick the 'act-like-Bill'
simulation command line option.
(Note, BTW, that mailfilter.cf already supports both // AND [] for
field value delimiters for quite a while now - which vanilla still
isn't doing, as it only supports this for 'isolate', which is a
language construct, not a config file. Nevertheless, the same
cross-platform issues exist for mailfilter.cf (Windows \/ escaping,
anyone? :-( ) and the mail scripts.)


To answer: the scope is local vs. outer, i.e. 'dynamic' in Bill's terms.
The idea to have match (or any other opcode) behave different from the
others variable instantiation-method wise is, errr, /not/ /wise/.
How many exceptions to the syntax and semantic rules of a programming
language do you want the crm114 script programmer to learn? I prefer:
zero. Lacking that ideal, the bare minimum. And right there, you've
yet another exception to the general pattern. DON'T.

In conclusion: twas rather easy. I came from the other side to this:
as I have been trying to get rid of the highly system-dependent
syscall opcode in the mail* scripts, the solution for that (which also
improves speed as syscall is rather slow on both UNIX and Windows) is
'call'ing mailreaver, etc. as subroutines. Much prep work for this has
been done in the GerH builds up to now; introducing scope to variable
instantiation is the last big chunk requires to keep mail* code
manageable.

Getting frustrated about magickelly appearing vars while tracing the
large mail* scripts does that for ye.

Be aware that mail*.crm already has passed the 5KLOC barrier, at least
collectively. (Also in vanilla, though there it's quite a bit thanks
to loads of the copy&pasta method of software   engineering. These are
not kiddie scripts anymore, so it requires a mature language. Scoping
is the bare minimum when you want to make structured programming
feasible in crm114 script.


I dread the moment someone announces he's got crm114 script which
crosses the 100KLOC barrier. Then crm114 script will surely have
become another JavaScript language gone totally bursar and no dried
frog pills to fix 'im right.


Release-wise, this is going out in a few days; if it doesn't make it
to beta/production status, I'll push at least a source-only interim
release so yall can have a gander.





And blast that other language, JavaScript. And interpreters which have
to deal with it and stop due short halfway because a machine is simply
loaded. Lucky for the FF folks we don't have the right to bear around
here in Cheese 'n Weed County. ;-)

G'night, all.


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

------------------------------------------------------------------------------
Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
-OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
-Strategies to boost innovation and cut costs with open source participation
-Receive a $600 discount off the registration fee with the source code: SFAD
http://p.sf.net/sfu/XcvMzF8H