Re: Autoloading of compctl from dbm database file.

[Zefram <zefram@dcs.warwick.ac.uk>]

>Seems to me that this idea has "module" written on it, in large flashing
>purple neon letters.

That it does.  But autoloading will require some changes to the base
code anyway.

>Compctls aren't very expensive to store either, are they?  The slow
>part of loading compctls and functions is parsing.  If we're going
>to introduce a database, we might as well also introduce a binary
>storage format and put pre-"compiled" functions, compctls, etc. in
>there.  Using a database just to store text that zsh then has to parse
>and execute anyway doesn't seem very helpful.

True.  Interpretation of byte-compiled compctls could be done entirely
in a module.  And if we're going to abandon autoloading, there's no
real point in using a database.  How about an interface like

% compctl -L exec
compctl -l '' exec
% bcompctl -L exec
bcompctl '35!^Az^@^@^@' exec
% bcompctl '35!^Az^@^@^@' command
% compctl -L command
compctl -l '' command

That is, bcompctl does the same job as compctl, but using a byte-
compiled form instead of the normal options.  "bcompctl -L > file"
could be used to save byte-compiled compctls in a form that can be
sourced quickly later.  The challenge is to come up with a binary form
of compctls that is architecture- and version-independent, and can be
turned into the internal form rapidly without risking a crash.

This is getting pretty far from the original idea of a database.

-zefram