[Nickle] Artificial distinction between import and autoimport

[Bart Massey]

In message <87bq6top6y.wl%cworth at cworth.org> you wrote:
> > New: import <name>
> >   Becomes an alias for autoimport <name>?
> 
> > It appears to me that this change is a dangerous one.
> 
> I don't follow what about the change introduces danger. There are no
> new semantics being introduced, but simply new names for existing
> semantics.
> 
> Or are you just saying that the semantics of the current "autoimport"
> are dangerous and that people would be wise not to use it? If so, then
> whatever the imagined security problem is there, it should be fixed.

Right now, you can use "import" when you think the namespace
whose contents you're trying to bring into scope is itself
already in scope.  You'll get an error if you were wrong.
For example, I sometimes write code like

   namespace Weird {
       public void f() {}
   }
   import Wierd

If "import" were replaced by "autoimport", this would have
the surprising behavior that my code would look for a file
called "wierd.5c" and load its contents.  In any situation I
can think of, this would be caught the first time the
program was tested, which is all "import" would do anyway.
It still makes me quite nervous.

> For example, does nickle search the current working directory by
> default for things to autoload? I could definitely see that being a
> problem, (as opposed to searching the directory in which the script
> lives, or the system directory, or directories explicitly listed on
> some search path).

Nickle searches only its compiled-in library directory, with
two exceptions.  If the environment variable "NICKLEPATH" or
the Nickle variable "nickle_path" has been set it searches
that path.  If it is lexing standard input, it adds "." to
the current path and also autoloads any ".nicklerc" it
finds.  A mess, admittedly, but seems to work well in
practice.

    Bart