> a language that has no support for namespaces, awkward scoping rules, > a problematic implementation of name references, and so on.
I could at least attempt to address those issues. Namespacing could be as simple as prepending the module name to the symbols that are being created. Bash seems to have no issues with symbol names such as path.add. It would be crude but effective. A true implementation would consist of completely separate evaluation environments with symbols linked in-between them. However, I imagine that this will not be possible because it would fundamentally change how bash works so thoroughly that it would just become another language. Please elaborate on the scoping and name reference issues. I'll address them if possible. I'd like to propose two additional semantics for source --library: - Load once The library `x` is loaded and evaluated only once in each context, no matter how many times `source -l x` is executed. There could be an additional `-f|--force` flag to override this. - Automatic symbolic namespacing The library name and a dot are automatically prepended to all symbols defined when a file is sourced via `source -l`. So if `x` contains `location=/etc/config`, then `source -l x` introduces the `x.location` variable into the current environment. Valid library file names would be restricted to the same set of characters that bash allows in variable names, excluding the dot. Otherwise the prefix cannot be derived automatically. There could be additional flags to override this: an `-n NAME` option which specifies a custom prefix and an `-N` option which disables namespacing. > provided that the behaviour of the posix mode > were to be left unchanged in all respects. I'll refactor it so that in POSIX mode the builtin behaves exactly as before. Matheus
