keywords for file-local/module-local/exported classes/functions?
----------------------------------------------------------------

- local / (none) / export
- (none) / visible / export
- (none) / module / global
- file identifiers only make sense as either module-local or exported.

Or it could be module-export/file-export sections of each file?
(similar to `interface` in Pascal)
    contents
    moduleexport
        SomeClass since 0.1
        OtherClass since 0.2
    fileexport
        ModuleInternal
    end
Or, when prototyping:
    contents auto
    contents
    fileexport
        all
    end
Or, shorter:
    module_export
        SomeClass
    end
    file_export
        AnotherClass
    end
    (although it's still not trivially greppable)

Alternative keywords:
    exports
        SomeClass
    end
    provides
        AnotherClass
    end
Or, with a keyword per line:
    provides SomeClass
    provides AnotherClass
Or, use a per-project text file:
    file things.slul
        SomeClass
        AnotherClass
But there needs to be a clear distinction between `moduleexport`
and `fileexport`. Module exports shouldn't be done accidentally!

BUT most things will be "provided"/"file_exported" in lowercase files.
So it might make more sense to just have local for local things.
At least for types. And a `calledfrom` for functions?

Regarding module interfaces:
- Should the module interface be generated with a command?
    (e.g. with `slul make-interface 1.2.0 1.1.34`)
- Should the module interface be manually created but checked by
  the compiler?


Class-local calls vs typeident calls (or enum values)
-----------------------------------------------------

(this is only a problem in e.g. `y = b x`, where `b` could be
 either a class-local call (`this.b`) or it could be a constructor
 in the typescope of the type of `y`).

solutions:
- `calls` section in function decl, analaguous to `modifies`.
   (slul2 would really become a "safetynaut" language :D )
    - and actually, `modifies` is kind of of limited use if
      doesn't track access from nested function calls.
        - on the other hand, adding a `modifies` line to some deeply
          nested "helper" function could cause a time-consuming "ripple"
          effect, where all (nested!) callers would have to be updated too
    - as a pragmatic solution, perhaps have `calls` and `modifies` apply
      only to the function at hand, and not nested calls.
- have different naming conventions for typeidents
  (e.g. uppercase, prefix with `new`/`create`/`make`, ...)
    - but it would have to work for enum values, too.
    - related: maybe the `own` qualifier/keyword could be used
      for making ownership transfer clear.
      (ownership and generics is a bit tricky, though...
       converting between "List of own T" to "List of T" is not safe)
- or just defer bindings until the whole class/file has been parsed.
    - could accumulate all unprefixed (no dot) identifiers in a tree.
    - at the end of the class/file, the tree could be traversed, and
      the identifiers could be searched in this order:
        1. the class
        2. the type (but this isn't known, so this step
           would need to be deferred)