1.1 --- a/docs/concepts.txt	Tue Jun 19 00:29:57 2012 +0200
     1.2 +++ b/docs/concepts.txt	Wed Jun 20 00:44:03 2012 +0200
     1.3 @@ -45,6 +45,58 @@
     1.4  See rejected.txt for complicating mechanisms which could be applied to
     1.5  mitigate the effects of these restrictions on optimisations.
     1.6  
     1.7 +Attribute Usage Observations
     1.8 +============================
     1.9 +
    1.10 +Within a scope, a name may be used in conjunction with attribute names in
    1.11 +order to access attributes on objects referenced by the name. However, such
    1.12 +observations can only be regarded as reliable if the object referenced is not
    1.13 +changed independently by some other mechanism or activity.
    1.14 +
    1.15 +With conventional functions and methods, any locally defined names can be
    1.16 +considered private to that scope and thus immune to independent modification,
    1.17 +at least within reasonable features of the language. Although stack
    1.18 +modification may be possible, it seems appropriate to reject such features,
    1.19 +especially since they lend themselves to unmaintainable programs.
    1.20 +
    1.21 +For names defined during the initialisation of a class, since the class itself
    1.22 +cannot be referenced by name until its declaration has been completely
    1.23 +evaluated, no independent modification can occur from outside the class scope.
    1.24 +
    1.25 +For names defined during the initialisation of a module, global declarations
    1.26 +in functions permit the rebinding of global variables and since functions may
    1.27 +be invoked during module initialisation, independent modification can
    1.28 +potentially occur if any functions are called.
    1.29 +
    1.30 +Module globals can be accessed from other modules that can refer to a module
    1.31 +by its name. Initially, an import is required to make a module available for
    1.32 +modification, but there is no restriction on whether a module has been
    1.33 +completely imported (and thus defined) before an import statement can make it
    1.34 +available to other modules. Consider the following package root definition:
    1.35 +
    1.36 +    # Module test:
    1.37 +    def f():
    1.38 +        import test.modifier
    1.39 +    x = 123
    1.40 +    f()
    1.41 +
    1.42 +    # Module test.modifier:
    1.43 +    import test
    1.44 +    test.x = 456
    1.45 +
    1.46 +Here, an import of test will initially set x to 123, but then the function f
    1.47 +will be invoked and cause the test.modifier module to be imported. Since the
    1.48 +test module is already being imported, the import statement will not try to
    1.49 +perform the import operation again, but it will make the partially defined
    1.50 +module available for access. Thus, the test.modifier module will then set x to
    1.51 +456, and independent modification of the test namespace will have been
    1.52 +performed.
    1.53 +
    1.54 +In conclusion, module globals cannot therefore be regarded as immune to
    1.55 +operations that would disrupt usage observations. Consequently, only locals
    1.56 +and class definition "locals" can be reliably employed in attribute usage
    1.57 +observations. 
    1.58 +
    1.59  Contexts and Values
    1.60  ===================
    1.61