proj-oot-ootModuleThoughts

if a later import statement would overwrite an existing symbol, the later statement must say whether or not to do so explicitly for each symbol (but it can use All or None though if u rly want a catchall): this makes monkeypatching buildins painful without making it impossible you cannot dynamically override a symbol without such an import; this allows the compiler to nondynamically call known functions, esp. builtins, in almost all cases furthermore, by default a module only exports things statically defined in it; there must be an 'export all' statement in the module to export dynamically generated functions, too; again, this allows the compiler to, by default, statically know which symbols are exported by a module, but to have a dynamic escape hatch for special cases similarly, the advice (pre- and post- wrappers) system is event-based (e.g. when any function is called, an event is fired, and when it returns, an event is fired), but you must statically declare, in the importing module (and the exporting one, if the choice of which symbols the advice attaches to is dynamically generated), which function symbols are affected, altho again All is allowed (ie, for these purposes, advising a fn is likee overwriting it)

---

so what are modules possibly for again?

building on http://users.rcn.com/david-moon/PLOT/page-3.html . From there:

units of source code (files, folders) units of compilation units of loading executable code namespace (units of name scoping) units of data classification (a dichotomy that classifies every object as either a member of the type or not a member of the type) types classes units of behavior (functions) units of language definition (macros)

other stuff:

units of type inference state domains scope of application of macros (and other metaprogramming) unit of constant table, stuff like that unit of dependency management and versioning (a grouping of things that all share/declare the same dependencies (with the same dependency version requirements), and which themselves are a unit of dependency management and versioning (that is, the module is the thing that receives a version and that is depended-upon by others)) units between which you must declare exceptions thrown (possibly except for a few panic-style 'error' exceptions)

---

ml-style? modules to specify which algorithms/implementations are actually chosen for each given interface/algspec. Could allow the caller to swapout LINPACK for a GPU-based LINPACK, for example, or to swap out one GUI or plotting package for another. Could be static (as i presume ML is) or dynamic; if dynamic, based on semiglobals

---