proj-jasper-jasperModuleThoughts

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)