In wondering about how to do user modules, I figured that $ could access them
without actually storing them in memory. But they wouldn't be accessible on
$-less lookup, so there were be the following hierarchy: 

 * In-memory user variables (access with null or $)
 * In-memory language variables (access with null or @)
 * Filesystem user variables (access with $)

Two obvious interesting points: a) you could do the same thing for filesystem
language variables, instead of using "%" as at the moment, and b) you could
bring in filesystem variables to in-memory by doing such as: 

   $myvar = $myvar

Which is kinda silly if it's just so you don't have to use the prefix, but it
changes the scoping from dynamic to static.

This is especially good since the "%" prefix does conflate a bit with
docstrings, and it frees it up as a prefix. Perhaps I should reserve some
prefixen now, so that people don't have the urge to ram % (modulo) and ! (not)
etc. up to their following variables.

So with these changes, it'd mean that the main difference between a module
function and a builtin function is that the scoping is static with the latter
and it can be accessed without a variable prefix sigil. So the design tip that
language functions should be in modules wherever possible and only promoted to
being builtins when they have proven their worth still stands.

So $ and @ are both disambiguation and mini-import operators, in a way.

Hmm, setting an item: 

thing:key = value

It's interesting that I felt compelled to have . return an item if it couldn't
find any variables on an object. Blurring the line between getattr and getitem,
really. I wonder if that's a good idea. The use case was: 

   grep {args.filenames} {args.pattern}

instead of

   grep {args:filenames} {args:pattern}

I guess that . is prettier in general.

One worry about prototypes is that Tables don't seem to copy all that
consistently sometimes. I guess that's just an implementation detail though.

Two of the most important conditions for variables will be "has X as a proto",
and "isinstance of X" if it's a Python object.

-- 
Sean B. Palmer, inamidst.com