Re: circumflex/caret

   From: Ger Hobbelt <[email protected]>

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

So the default is to create with local scope.  OK.  I can get behind
that as a design principle.

What about the system-generated :_ variables, like :_dw:?  How are those
scoped?

   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.

So, "alter" does not change scope.  But this still leaves the
question of whether match-binding gets unwound or not.  IE:

   isolate (:alphabet:) /abcdefghijklmnopqrstuvwxyz/
   match (:: :foo:) [:alphabet:] /...(...)../
   call /:uh-oh:/
   output /:*:foo:/   ******WHAT IS THE OUTPUT VALUE HERE?

   :uh-oh:
   match (:: :foo:) [:alphabet:] /..........(.)../
   return 

Or, I could interpret "writing to a variable does NOT change it's 
scope" to mean that this does not unwind.

However, that would mean that if I had in toplevel a variable :foo:
then if in a subroutine I used :foo: without an isolate I'd get the
outside one; if I used it _with_ an isolate first, I'd get a new one
which would unwind away on return.

This is bad.  It means that you don't provide downward isolation; the
caller still needs to be careful to NOT use any variable names used by
the callee- which means the callee's code must be known to the author
of the caller, and must still stay inside the caller author LOC limit.

I would feel much more comfortable with scope going both
ways- that is, within a call frame you have only what you 
yourself created; things both above and below you are both
invisible and immutable - AND- their namespaces do not collide.  

Thus, the code above would bomb on [:alphabet:] not being
visible to the :uh-oh: subroutine; if you added <global> to
the creation of :alphabet: then :uh-oh.foo.call-level-2: would
get the value "l", which would immediately be lost on the return.

Note that "static" is different than "global", and different also
from "keep".

  ->  STATIC means that state is retained between calls to this routine
      name.
  ->  GLOBAL means that this variable NAME is visible across call/return
      callframes.

Note that this is _exactly_ what C does so it's not surprising
to anyone adept at C:

 C "static" inside a function == CRM114 "static" as a flag
                              == value retained across return/call again
                              == visible only inside this function

 C "static" outside of any function == CRM114 "global" as a flag
                              == one value shared everywhere
                              == visible to every function in this file.


[[ I always considered the inside/outside of a function thing on
C "static" to be a hack.  They should have added a word in the
same scheme as "extern". ]]


   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. 

Not same call level, but same _subroutine_.  Call level doesn't
matter.  This is the same as a "static" in C - which is _damn_ useful
for things like cached results, counters, generator functions, etc.
It's the whole idea of a stateful object.

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

I have never heard of this.


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

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

Other questions:

Should "static"/"keep" be "sticky" - that is, once declared 
keep/static/global - can you UNkeep them, at least locally?

Or - should global visibility require _active_ agreement to
share the variable - like C "extern" in each of the sharing
modules?  

Should the :_* variables like :_dw: be defaulted to globally
visible, with static durability?  I vote yes.

The C data model is pretty good - good enough to build 10 MLOC
applications.  We should head in that direction too.

	 - Bill Yerazunis

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