Re: Parameter module, $functions, and autoloading

[Zefram <zefram@xxxxxxxx>]

Bart Schaefer wrote:
>An interesting solution to both problems occurred to me today:  Create a
>builtin "undefined" that works like the alias above.  That builtin could
>have access to the function name and argv independent of FUNCTION_ARGZERO, 
>and would simply perform the autoload and execute.  It could even take an
>option -U having the same meaning as "autoload -U".

Would be nice.  Autoloaded functions are already internally executed in
a manner pretty close to this; it's tempting to change autoload to just
define the function with a body consisting of a call to this builtin.

The only issue I see is, unfortunately, a biggie.  What happens if you
have a function defined like this, then the user defines "undefined"
as a shell function (taking precedence over the builtin) and then tries
to execute the supposedly-autoloaded function?  Also consider disabling
the builtin.  You'd need some special syntax, rather than just a command
name, to avoid this potential clash.

If you do go with a special syntax, I suggest that the syntax allow
an arbitrary command name, rather than just handling this one case of
autoloaded functions.  There may be other things in the future for which
we want non-overridable builtin command syntax.

>A more complicated solution involves a minor parsing rewrite:  Create a
>new reserved word "undefined".

We can't define any new reserved words and retain sh/ksh compatibility.
That's even worse than a builtin.

Oh, I suggest that the name "autoloaded" is clearer than "undefined",
if we do do any of this.  I never liked that bit of the `functions`
format: if a function is undefined, surely it doesn't exist at all,
and shouldn't be output.

-zefram