Thu Jun 5 11:33:34 CEST 2008

Name spaces: load vs. require

This post fits in the toplevel namespace vs. modules idea.

Tree-structured modules are a great way to manage namespaces in large
software projects, but there is something to say for the 'one big
namespace' approach when single instances are the rule and not the

For example:

   * Generic interpreter code is parameterized by the words 'receive'
     and 'transmit'.

   * Specific toplevel code links generic code together by simply
     inlining into its namespace the interpreter code and a particular
     definition of these words.

The benefit of this pattern is that it doesn't need much red tape:
there is basicly no namespace management, which can be a down side
when code gets big, and needs to be more generic.  However, for deeply
embedded programming more often than not there is usually only one
static instance of a certain object, in the case of the example it's
the debugging serial port.  Moreover, the ratio of glue code necessary
to implement the binding and the code that does something useful can
be high.

So why not use the simple mechanism until more abstraction is needed?
For example, generic interpreter code can be defined in a file that's
simply included.  Whenever multiple instances or late binding is
necessary, this file is wrapped in a module to shield namespaces.
This is how it is solved right now: you're free to use load (include)
or require (proper module namespace management).  The monitor kernel
is implemented with load.

On top of this, macros can be redefined, but compilation generates a
notification of this.  This is basically hierarchical modules +
parameters, but without specifying in advance which behaviour can be